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

OLM v1: Manage operators packaged in registry+v1 bundles with OwnNamespace and SingleNamespace installModes

XMLWordPrintable

    • Strategic Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
    • 100% To Do, 0% In Progress, 0% Done
    • 0

      Feature Overview (aka. Goal Summary)  

      OLM v1 effectively manages operators packaged in registry+v1 bundles with OwnNamespace and SingleNamespace installModes.

      Goals (aka. expected user outcomes)

      • Users can rely on OLM v1 to manage operators packaged in registry+v1 bundle format, including those with OwnNamespace and SingleNamespace installModes.
      • Operator authors can rely on OLM v1 to propagate the specified targetNamespaces to the operator deployment manifest during installation as the WATCH_NAMESPACE env vars, ensuring that the operator is scoped to the correct namespace without modifications

      Background

      Our Telco customers and ISV partners are eager to leverage OLM v1's ability to declare specific Operator versions for managed clusters using GitOps/ZTP workflows. 

      By defining Operator versions directly in Git repositories, customers can ensure that only compatible versions are deployed to specific configurations. This GitOps process streamlines initial deployment and subsequent updates, ensuring alignment between Operator versions and managed cluster configurations. 

      While the initial GA release of OLM v1 may have limitations, our goal is to support a broader range of operators, including those packaged in registry+v1 bundles with OwnNamespace and SingleNamespace installModes.  This will enable us to meet the evolving needs of our Telco customers and protect our existing investments. 

      By preserving compatibility with the current operator landscape, we can facilitate a smoother transition to the OLM v1.  This not only secures existing workloads but also opens up new opportunities for growth within the OpenShift business.

      Requirements (aka. Acceptance Criteria)

      • TargetNamespace propagation: 
        • OLM v1 can handle situations where the targetNamespace differs from or equals to the installNamespace when installing a registry+v1 bundle. 
        • OLM v1 can propagate the specified targetNamespace to the operator deployment manifest, ensuring correct namespace scoping for registry+v1 bundles.
      • RBAC enforcement: 
        • OLM v1 enforces RBAC permissions based on the targetNamespace to prevent unauthorized access to cluster-wide resources
      • Error handling and troubleshooting: 
        • OLM v1 provides warning and error logs to help users troubleshoot potential issues related to installing registry+v1 bundles with OwnNamespace and SingleNamespace installModes.

      Customer Considerations

      Telco customers.

      Documentation Considerations

      A step-by-step guide on configuring and managing registry+v1 bundles with OwnNamespace and SingleNamespace install modes in OLM v1.

      Interoperability Considerations

      Existing Red Hat and certified operators packaged in registry+v1 bundles support OwnNamespace and SingleNamespace installModes.

              rhn-coreos-tunwu Tony Wu
              rhn-coreos-tunwu Tony Wu
              Matthew Werner Matthew Werner
              Joe Lanford Joe Lanford
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: