You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proposal suggests transitioning Porter's architecture from utilizing mixins to adopting custom invocation images that can be referenced remotely. The primary motivation for this design is to eliminate the complexities of creating a custom mixin and shift towards using custom invocation images. This encourages community-driven contributions, supports a broader range of languages and technologies, and aligns with Docker's universally accepted standards.
Additionally, invocation images will automatically mount the porter.yaml file, reducing or eliminating the need for manual "wiring" of porter.yaml metadata, streamlining the process for developers.
Publicly available invocation images, much like the mixin CLI, would be indexed and searchable, creating a vibrant ecosystem of pre-built images for various devops stacks such as Kubernetes, Helm, Terraform, etc.
Additional Context
The proposed transition will chiefly impact areas such as the CLI, porter.yaml manifests, and the way bundles are defined and managed. This change allows for more flexible use of remote invocation images within the porter.yaml, enabling reuse and promoting community-created standard images.
The existing custom Dockerfile functionality can serve as a precursor to new custom invocation images. Developers can refine custom Dockerfiles into invocation images, which can then be shared through community platforms or repositories, enhancing collaboration and tool accessibility.
Risks/Concerns
Transition Complexity: There may be challenges for users transitioning to this new model, necessitating well-documented migration strategies and extensive user support.
Security and Integrity: Introducing remote invocation images requires careful management to ensure the authenticity and integrity of images used. Strict validation, security layers, and possibly image signing will be critical defenses.
Development Workload: Increased demands on development and maintenance are expected to support the transition, requiring additional resources for systematic upgrades and tool creation.
What other approaches were considered?
Alternative approaches included maintaining a hybrid model to offer legacy support for mixins. This would reduce disruption but involve maintaining dual models, potentially complicating the overall system architecture. Another approach was enhancing existing mixins to make them easier to use, but this was seen as an insufficient measure given the greater flexibility and community engagement custom invocation images offer.
Implementation Details
Upon acceptance, the proposal would make changes centered around the porter.yaml file, allowing direct specification of custom remote invocation images. This encourages the development and uptake of community-driven solution images. Below is an example configuration to illustrate this concept:
This proposal has remained open for at least one week, allowing time for community feedback.
The text was updated successfully, but these errors were encountered:
jmcudd
changed the title
Transitioning from Mixins to Custom Remote Invocation Images
(proposal) Transitioning from Mixins to Custom Remote Invocation Images
Oct 17, 2024
Hi @jmcudd, this is an interesting proposal.
There exist a similar PEP 005, and the initial proposal for the PEP can be found here. The PEP was never completed, but I think it is worth taking some of the same considerations into account.
What design is being proposed?
The proposal suggests transitioning Porter's architecture from utilizing mixins to adopting custom invocation images that can be referenced remotely. The primary motivation for this design is to eliminate the complexities of creating a custom mixin and shift towards using custom invocation images. This encourages community-driven contributions, supports a broader range of languages and technologies, and aligns with Docker's universally accepted standards.
Additionally, invocation images will automatically mount the
porter.yaml
file, reducing or eliminating the need for manual "wiring" ofporter.yaml
metadata, streamlining the process for developers.Publicly available invocation images, much like the mixin CLI, would be indexed and searchable, creating a vibrant ecosystem of pre-built images for various devops stacks such as Kubernetes, Helm, Terraform, etc.
Additional Context
The proposed transition will chiefly impact areas such as the CLI,
porter.yaml
manifests, and the way bundles are defined and managed. This change allows for more flexible use of remote invocation images within theporter.yaml
, enabling reuse and promoting community-created standard images.The existing custom Dockerfile functionality can serve as a precursor to new custom invocation images. Developers can refine custom Dockerfiles into invocation images, which can then be shared through community platforms or repositories, enhancing collaboration and tool accessibility.
Risks/Concerns
What other approaches were considered?
Alternative approaches included maintaining a hybrid model to offer legacy support for mixins. This would reduce disruption but involve maintaining dual models, potentially complicating the overall system architecture. Another approach was enhancing existing mixins to make them easier to use, but this was seen as an insufficient measure given the greater flexibility and community engagement custom invocation images offer.
Implementation Details
Upon acceptance, the proposal would make changes centered around the
porter.yaml
file, allowing direct specification of custom remote invocation images. This encourages the development and uptake of community-driven solution images. Below is an example configuration to illustrate this concept:Additional Examples
Example 1: Kubernetes Deployment Workflow
Example 2: Infrastructure Management with Terraform
Example 3: CI/CD Pipeline with Docker
Checklist
The text was updated successfully, but these errors were encountered: