Feature Overview (aka. Goal Summary)  

OLM v1 supports deploying and managing operators/extensions packaged as Helm charts without requiring repackaging for OLM-enabled clusters.

Goals (aka. expected user outcomes)

In essence, supporting Helm chart-packaged operators and CRDs in OLM v1 is essential to foster a thriving operator ecosystem, improve developer experience, and drive broader adoption of the OLM and the OpenShift platform for several reasons:

• Accelerated OLM v1 adoption: By supporting the widely adopted Helm packaging format, OLM v1 can significantly lower the barrier to entry for both ISV partners and end-users.  This expanded compatibility will encourage a broader ecosystem of operators and drive faster adoption of the OLM and the OpenShift platform.
• Enhanced ecosystem growth: Many popular open-source operator projects are distributed as Helm charts.  Enabling OLM v1 to manage these charts will facilitate their seamless integration into OpenShift clusters, promoting a richer and more diverse operator ecosystem.
• Faster time-to-market and improved feature parity: For ISV partners, supporting Helm chart packaging can reduce the effort required to re-package existing operators from their Helm charts to the OLM bundle format.  Enabling OLM v1 to manage these charts directly will enable faster time-to-market for new partners/solutions we want to onboard and improve feature alignment for existing partners/solutions with competing platforms.
• Improved developer experience: Helm offers a powerful and flexible way to package and distribute applications.  By integrating Helm support into OLM v1, developers can leverage their existing Helm knowledge and tooling, streamlining the operator development and deployment process.
• Increased platform stickiness: By providing a comprehensive solution for managing both native OLM bundles and Helm chart-based operators, OLM v1 strengthens its position as the de facto standard for operator lifecycle management, increasing our platform stickiness and adoption.

Background and Current State (what we’ve seen so far)

• ISV partners have been leveraging Helm charts to package and distribute their operators and associated Custom Resource Definitions (CRDs) in a platform-agnostic fashion.  Typically, these charts include the controller code, CRD manifests, and necessary (platform-specific) configuration files.

• Typically, ISV partners install controllers and CRDs using Helm's built-in mechanisms.  This involves orchestrating the deployment of CRDs before creating the custom resource (CR) objects and controllers to provide the Zero-Touch Provisioning (ZTP) feature for the initial configuration of their service stacks.  Helm's templating capabilities allow for customization based on environment/platform-specific configurations.  

• To manage CRD upgrades, ISV partners often rely on manual updates via kubectl or utilize Helm hooks for custom scripts to be executed at specific points in the Helm lifecycle, such as before and/or after chart upgrades to orchestrate the installation order of specific CRD management tasks.  Another common practice in managing CRD upgrades is to separate CRD manifests into a dedicated chart.  This approach often leverages Helm’s dependency management to ensure the main chart depends on the CRD chart to guarantee that CRDs are installed before other components.  

• Beyond the dependencies between the operator charts and CRD charts are managed through Helm's dependency management features, it is also common for ISV partners to source other operator charts as dependencies either from remote repositories or local directories. 

• Installing Helm charts in disconnected environments needs careful preparation and planning.  ISV partners often guide customers in obtaining images without Internet access, requiring image downloads, packaging, and transfer to offline hosts.  This ensures chart availability offline.  If the chart relies on external dependencies such as repositories or direct image URLs, users must download and include dependent charts, pull those images, store them locally, and update image references to point to a local image registry.

While Helm provides a robust framework for packaging and deploying applications, it currently lacks dedicated lifecycle management for controllers and Custom Resource Definitions (CRDs).  Specifically, Helm v3 does not natively support CRD upgrades or deletions.  

OLM v1 plans to offer automated CRD upgrades with built-in safety checks to address these limitations and enhance operator lifecycle management.  As the Helm community explores CRD management advancements in Helm v4, OLM v1 can collaborate to offer complementary features. 

Beyond lifecycle management, OLM v1 enhances the discoverability of updated Helm chart versions.  Users can be notified of new Helm chart versions available for installation or mirroring from both OLM catalogs and Helm chart repositories.  

To streamline Helm chart installations in disconnected environments, OLM v1 and OpenShift facilitate image pre-pulling and local storage.  By leveraging the oc-mirror plugin, Helm charts can be mirrored to an internal or air-gapped image registry, enabling installations from local image registries, chart repositories, or file-based catalogs.

We see a collaborative approach between OLM v1 and Helm will benefit the operator ecosystem by offering robust tools and options for managing complex applications.

Requirements (aka. Acceptance Criteria)

These requirements are derived from a comprehensive analysis of market demands and our partners’ experiences, see “Customer Considerations” section for more details.  By addressing the identified gaps in Helm feature coverage, we aim to enhance OLM’s capabilities and provide a more robust solution for managing operator workloads.

• Lifecycle management: OLM v1 introduces lifecycle management for Helm chart-based operators and extensions, enabling installation, updates, and uninstallation as valid operator packages while leaving existing Helm chart deployments unaffected until explicitly converted.
  • Open question: Can OLM v1 convert existing chart releases into OLM-managed resources, or does this require uninstallation and reinstallation?

• Installation from direct URLs or chart repositories: An OLM v1 user can directly specify a Helm chart for their operator/extension by referencing a Helm chart repository, including chart name and version, in OCI media type or tarball format.

• Installation from a file-based catalog: An OLM v1 user can specify a reference to a package within a catalog, where the package is a Helm-packaged operator/extension. 
  • A package maintainer can create a file-based catalog by referencing a chart repository where a set of operator/extension releases are packaged as Helm charts. 

• Configuration management (value injection): Enable users to configure Helm chart values through OLM v1’s user-facing API, overriding default values specified in values.yaml file. 

• Dependency management: Handle dependencies specified in a Helm chart for other operators/extensions, including those referenced in a Helm repository or bundled within the chart itself. 
  • This includes resolving dependencies and their versions, managing their lifecycle, and ensuring correct installation order.

• CustomResourceDefinition (CRD) support:
  • Integrate OLM’s CRD upgrade safety checks:
    • Initial focus: Feature parity with core Helm chart lifecycle operations without integrating with CRD upgrade safety checks.
    • Long-term: Ensure compatibility with OLM's CRD management capabilities in upgrade safety checks. 
  • Handle CRDs defined in the same chart:
    • In `crds` directory: In this case, CRDs will be installed by default when running a helm install for the chart before other manifests.  
      • Initial focus: No upgrades or deletions for CRDs defined within the Helm chart's `crds` directory. 
      • Long-term: Support upgrades or deletions for CRDs defined in the Helm chart's `crds` directory with OLM’s CRD upgrade safety checks.
    • In `templates` directory: In this case, CRDs will be installed by default when running a helm install for the chart before other manifests. 
      • Initial focus: No integration with CRD upgrade safety checks.
      • Long-term: Integrate OLM’s CRD upgrade safety checks.
  • Handle CRDs defined in separate charts: 
    • In this case, manifests for CRDs are put in one chart, while manifests for other resources that use CRDs are put in another chart. 
      • Initial focus: Handle CRD upgrades for CRDs defined in separate charts (when defined as dependencies) without integration with CRD upgrade safety checks. 
      • Long-term: Integrate OLM’s CRD upgrade safety checks.
    • See “Proposed Milestones” section for more details. 

• Interoperability with Chart Hooks: OLM v1 recognizes and parses Helm chart hook definitions, including hook type (pre-install, post-install, etc.), execution order (via hook-weight), and deletion policy (via hook-delete-policy). 
  • OLM v1 supports executing hook scripts or commands during the corresponding chart lifecycle phase, providing logs for troubleshooting.
    • Worth considering: A mechanism at the OLM level to selectively disable hooks if potential conflicts arise between Helm hook scripts and OLM v1 operations.
  • To ensure seamless integration, OLM v1 coordinates hook execution with other OLM features.  This includes aligning pre-install and pre-upgrade hooks with CRD upgrade safety checks and coordinating pre and post-deletion hooks with CRD deletion.

• Usability: Provides user interfaces for managing Helm charts through OLM v1's ClusterExtension or Extension APIs, integrating with existing OLM features to notify users of new Helm chart versions available for installation or upgrade, and supports disconnected environments, along with other general OpenShift product requirements.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

Open Questions

• Open question: Can OLM v1 convert existing chart releases into OLM-managed resources, or does this require uninstallation and reinstallation?
• Worth considering: A mechanism at the OLM level to selectively disable hooks if potential conflicts arise between Helm hook scripts and OLM v1 operations.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Customer Considerations

• See docs

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.