# Porter's 2023 Roadmap ## Outline https://github.com/cncf/toc/pull/951/files?short_path=bcaa7ab#diff-bcaa7ab661b159edfd0e192b68681fff7f6d95a07d69360cdff548b9f48d998b * say what we did in 2022 (use the section from the annual review) * maybe we can say how adoption of v1 is going so far using this link: https://hanadigital.github.io/grev/?user=getporter&repo=porter * welcome new contributors and point out our contributing guide * what is the operator, who would be interesting in using the operator, what's it used for. * high level roadmap for the operator * encourage people to try it out and give feedback before we lock in v1 * with a picture * Advanced Dependencies and Workflows * explain high level what type of problem you can solve * say it's coming and the timeline * How we are improving Bundle Security this year * Decomposing bundles into smaller building blocks * Limiting scope of what in a bundle has access to credentials that are given to the bundle * Stretch Goal: * SBOM * Signing/Verification * Put out call for collaborators to vet the design and provide feedback (make sure to loop in Jeremy) ## Draft Now that 2022 is finally over and [Porter v1 is out the door](https://getporter.org/blog/v1-is-here/), I'd like to share our plans for this coming year. You can find a review of 2022 and our high level plans for 2023 in our [Porter Annual Review for 2022](https://github.com/cncf/toc/pull/951/files) but let's go over the highlights for a sneek peak of what's to come. ### Porter Operator Many users, especially adopters with large-scale Porter deployments, are eagerly awaiting managing their installations using a GitOps based workflow with the Porter Operator and Flux. We made great progress on the operator last year year. It works but isn't ready for use in production yet. Our goal is to [release Porter Operator v1](https://github.com/getporter/operator/milestone/1) in Q2 2023. The Porter Operator allows you to: * Automate running bundles by defining your desired installation state in a Kubernetes. * Upgrade to new versions of bundles when they are released * Integrate bundle deployments into your pipelines There are many areas of improvements that we plan to do in the v1 release. Here are some highlights: * Streamline the transferability between Porter CLI and the operator. This allows users to have an easier transiton from using the Porter CLI to manage installations using the operator. * Enhance user experience by allowing for easy access and consumption of Porter generated outputs, without the need for managing backend plugin/configuration complexity. * Efficient resource management for temporary resouces created by the operator to execute bundles. Some improvements like being able to install multiple porter plugins has already been completed. We are excited for you to try it out by following the [quick start guide](https://getporter.org/operator/quickstart/) and and provide valuable feedback that will help us improve the project. ### Advanced Dependencies Porter plans to support advanced workflows and dependency scenarios ([PEP003](https://github.com/getporter/proposals/blob/main/pep/003-dependency-namespaces-and-labels.md)), where users can define bundles that have a complex dependency graph. Dependencies may be an interface such as requiring a MySQL database whether it came from a dedicated server, a Helm chart, or a database as a service from a cloud provider. Dependencies may also be resolved to existing installations of bundles, such as a shared dev database or a redis instance for the staging environment. This allows better reuse of bundles, so that a bundle author can write an bundle for just their software and they don't need to write cloud provider specific bundles, such as "my software on Azure", "my software on Amazon", etc. Instead, they can create a bundle that requires another bundle that matches a specified interface and Porter can satisfy that dependency differently depending on the target environment. A lot of invisible groundwork and refactoring has already been committed to our main branch as I have prototyped the next version of dependencies in Porter. We expect to have experimental builds available so that we can get feedback on the new implementation by Q2. ### Improved Bundle Security Mixins are binary wrappers around common deployment tools, such as Terraform and Helm, that make it easier to use that tool inside a bundle with Porter. Currently they are distributed as binaries, and embedded inside the bundle's image. We want to improve bundle security by distributing and executing **mixins as bundles**, essentially decomposing bundles into smaller bundles that we can more securely distribute and execute ([PEP005](https://github.com/getporter/proposals/blob/main/pep/005-mixins-are-bundles.md)). This has a number of advantages such as: * Secure distribution mechanism of mixins. This allows us to no longer need to "install" mixins, or trust those installed mixins. Bundles can reference mixins from OCI registries and take advantage of existing security tooling and software to distribute, scan, and sign mixins. * Isolate credentials used by a bundle to just the relevant portions of the bundle. For example, only the Azure mixin should have access to your Azure credentials, and only the Helm mixin should have access to your kubeconfig. Credentials applicable to one mixin are not exposed to other unrelated mixins or scripts in the bundle. * Achieve significant performance improvements due to improved reuse of cached image layers. All of this relies upon the Advanced Dependencies feature first, so this will be delivered by the end of 2023. ## Signing and SBOMs There has been huge leaps forward in the world of signing and software bill of materials in the past year that we are ready to jump on and use. New versions of the OCI Distribution spec, alternatives to Notary such as sigstore, and a plethora of SBOM generating libraries are available for us to build into Porter. Our plan is to incrementally add support for: * signing bundles * distributing the signature when the bundle is published * validating a bundle signature * generating a software bill of materials for possibly multiple aspects of a bundle: the bundle itself, the mixins and tools used in the bundle, and of course the software deployed by the bundle. This won't be a big bang feature and we hope to be able to ship these in minor releases through the year. ## Contributors Welcome! Phew! This is a big chunk of work for a pretty small group of maintainers and contributors. So if you find any of this interesting, please consider helping us out! Our [Contributing](https://getporter.org/contribute/) landing page has details on how to get involved with the project and we would welcome all types of contributions such as: * Feedback on use cases and requirements * Testing out early releases of features * Reviews of our designs and proposals * Saying hi in meetings and reminding us that someone cares about any of this shipping * Happy emoji reactions on our slack announcements and progress reports This is gonna be a big year, and we hope you'll stick around for the ride!
Last changed by  
 
Porter
https://getporter.org
187

Read more

Porter Community Meeting Minutes

Bi-weekly call with the Porter maintainers, contributors and community. :::info Agenda: https://porter.sh/dev-meeting/ Zoom: https://porter.sh/zoom/dev/ passcode 77777 Calendar: Get the recurring calendar invite from https://porter.sh/calendar Time: Every other Thursday at 11am Central Time (17:00 UTC) Everyone is invited! 💖 Attendees can add agenda items before a meeting.

4/28/2024
Advanced Dependencies Test Suite

Do we care to make the test bundle realistic in any way? We can have a mega test bundle that does dependencies, separate from our main bundle if it causes performance problems Then have an example bundle or two in our examples repo that really walks through how to use the feature. Make a paired tutorial to explain how to use them. What should our test bundle(s) have so that we have exercise all of depsv2? More than one level deep of dependencies. So root -> A -> B Supports a range of bundle versions, e.g. mysql bundle has more than one available version Has a bundle interface specified as a bundle reference. This bundle could be a porter bundle or something handmade and published just to provide an interface

2/2/2023
Porter 2022 Annual Review

Porter creates installers for cloud-native applications and their infrastructure. Package your application, client tools, configuration, and deployment logic into an installer that you can distribute and run with a single command. Metrics Metric Last Review Today Stars

10/24/2022
Post v1 roadmap

Major features Porter Operator stable release, with tiny grpc service for outputs pep 003 advanced dependencies - "bundle workflow" run multiple bundles and pass data between them pep 005 mixins are bundles build, distribute and execute mixins using CNAB bundles

10/20/2022
Read more from Porter
Published on HackMD