Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-2154

[Tech Preview/Phase 1] OLM v1: Native support for Helm chart-packaged Operators

XMLWordPrintable

    • Product / Portfolio Work
    • OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
    • False
    • Hide

      None

      Show
      None
    • False
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Feature Overview (goal summary)  

      As a Tech Preview, OLM v1 supports deploying and managing operators/extensions packaged as Helm charts in OLM-enabled clusters without requiring repackaging.

      Goals (expected user outcomes)

      This ticket tracks the initial milestones aimed at bringing OLM v1 to feature parity with the Helm client.  Achieving this parity will allow OLM v1's user-facing APIs to provide core Helm chart lifecycle operations (install, upgrade, delete) and ensure compatibility with existing Helm chart conventions, minimizing the need for additional tooling or conversion.  (More detailed information about the business context, goals, and importance can be found in the (internal only) doc and the full scope Jira ticket: OCPSTRAT-442.)

      Key areas for these initial milestones include:

      1. Chart source:

      • Support installation from direct URLs and Helm chart repositories.

      2. Chart parsing:

      • Parse Helm chart metadata (Chart.yaml, values.yaml) to extract essential information.
      • Resolve Helm chart dependencies (subcharts, Chart.yaml, or requirements.yaml).
      • Process Helm hooks.

      3. Chart installation:

      • Handle dependency installation.
      • Execute pre-install and post-install hooks.
      • Install CustomResourceDefinitions (CRDs) defined in the Helm chart's `crds` directory (note: no upgrades or deletions of these CRDs).
      • Provide configuration management (value injection) for Helm chart values.

      4. Chart upgrade:

      • Support Helm chart upgrades with dependency updates.
      • Execute pre-upgrade and post-upgrade hooks.
      • Handle CRD upgrades for CRDs defined in separate charts (by treating them as dependencies).

      5. Chart deletion:

      • Support Helm chart deletion with dependency cleanup and resource removal.
      • Execute pre-deletion and post-deletion hooks.
      • Handle CRD deletion for CRDs defined in separate charts (by treating them as dependencies).

      6. Chart status:

      • Provide status information about Helm chart installations and upgrades.
      • Integrate Helm chart status with OLM's user-facing API health stats.

      Requirements (acceptance criteria):

      1. Helm chart lifecycle management: OLM v1 provides full lifecycle management for operators/extensions packaged as Helm charts, enabling installation, updates, and uninstallation.  Existing Helm chart deployments should remain unaffected until explicitly converted or managed by OLM v1.

      2. Installation from various sources: OLM v1 users can install Helm chart-based operators/extensions by referencing charts directly from:

      • Direct URLs, or
      • Helm chart repositories (specifying a Helm chart name and version, packaged in OCI media type or tarball format)

      3. Configuration management (value injection): OLM v1’s user-facing API enables users to configure Helm chart values, allowing overrides of default values specified in values.yaml file. 

      4. Dependency management: OLM v1 handles dependencies specified within a Helm chart, including those referenced in a Helm repository or bundled as subcharts.  This includes:

      • resolving dependencies and their versions,
      • managing the lifecycle of dependencies, and
      • ensuring correct installation order.

      5. CustomResourceDefinition (CRD) support: OLM v1 integrates CRD handling:

      • CRD upgrade safety checks: Incorporate OLM’s existing CRD upgrade safety check logic whenever OLM v1 is tasked with creating or updating CRDs in the cluster.
      • Handling CRDs defined within the same chart:
        • In `crds` directory: CRDs in this directory will be installed by default before other manifests during a Helm chart installation (in consistent with Helm’s behavior). Note: Upgrades and deletions of CRDs defined within the Helm chart's `crds` directory are out of scope. 
        • In `templates` directory: CRDs defined as templates will also be installed by default before other manifests during installation.
      • Handling CRDs defined in separate charts: Support scenarios where CRD manifests are in one chart, and resources using those CRDs are in another, typically managed as dependencies.  CRD upgrades and deletions will be handled for these dependencies.

      6. Interoperability with Chart Hooks: OLM v1 recognizes and parses Helm chart hook definitions, including hook type (e.g., pre-install, post-install), 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 and provides logs for troubleshooting. 
      • To ensure seamless integration, OLM v1 coordinates hook execution with other OLM features, such as aligning pre-install/pre-upgrade hooks with CRD upgrade safety checks and coordinating pre/post-deletion hooks with CRD deletion.

      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.

      Customer Considerations/Interoperability Considerations

      See Customer Considerations (use cases)

      Documentation Considerations

      Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

      <your text here>

      Out of Scope

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

      <your text here>

              rhn-support-mkalinin Marina Kalinin
              rhn-coreos-tunwu Tony Wu
              None
              Daniel Messer, Tony Wu
              Joe Lanford Joe Lanford
              None
              Matthew Werner Matthew Werner
              None
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: