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

OLM 1.0 - Initial Support for Namespace-scoped operators/extensions


    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • None
    • Operator Framework
    • None
    • False
    • Hide


    • False
    • OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
    • 50% To Do, 0% In Progress, 50% Done
    • 0
    • Program Call

      Feature Overview (aka. Goal Summary)  

      • Cluster administrators need the ability to delegate the installation of operators/extensions to tenants with the proper permissions.
      • Cluster tenants desire the ability to install operators/extensions in their namespace.

      Goals (aka. expected user outcomes)

      Adding support for namespace-scoped operators/extensions to OLM 1.0 will improve the user experience for both cluster administrators and tenants by:

      • Allowing tenants to install their operators/extensions.
      • Automating the challenge of ensuring only versions with compatible APIs are installed.
      • Ensuring changes from one tenant don't impact others.

      Requirements (aka. Acceptance Criteria):

      A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

      • OLM 1.0 allows a user with sufficient permissions to install and manage the lifecycle of an operator/extension in a namespace.
      • When two or more copies of an operator/extension exist, upgrading (or downgrading) one copy must not impact the operations and/or data of the other copy.
      • Namespace-scoped operators/extensions must not specify a webhook.
      • Namespace-scoped operators/extensions must not have cluster-scoped CRDs.
      • When multiple copies of the same extension exist, OLM must only apply CRDs from the latest version of the extension, as defined by semver.
      • Namespace scoped operators/extensions must not watch all namespaces.
      • Installation should fail if both a cluster- and namespace-scoped extension are for the same package (the first one installed should succeed).


      Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both  
      Classic (standalone cluster)  
      Hosted control planes  
      Multi node, Compact (three node), or Single node (SNO), or all  
      Connected / Restricted Network  
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x)  
      Operator compatibility  
      Backport needed (list applicable versions)  
      UI need (e.g. OpenShift Console, dynamic plugin, OCM)  
      Other (please specify)  

      Use Cases (Optional):

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

      <your text here>

      Questions to Answer (Optional):

      Include a list of refinement / architectural questions that may need to be answered before coding can begin.  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>


      Today, OLM 1.0 only supports managing operators/operators/extensions in cluster scope.  This imposes a limitation that operators/extensions can only be installed by cluster administrators and any changes to that extension impact all users of the cluster.  In a multi-tenant cluster, this means that the cluster administrator is now responsible for managing requests from all tenants for operators/extensions, resolving any discrepancies between the requests to ensure a version that works for all tenants is installed, and ensuring changes made by one tenant don't impact another tenant.

      Upstream engineering brief: https://docs.google.com/document/d/1by_XVU7X6n1kGRzPp5FsTGpY2h_861pr8Tn1I5AVMjM/edit?usp=sharing


      Customer Considerations

      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

      <your text here>

      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>

      Interoperability Considerations

      Which other projects, including ROSA/OSD/ARO, 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.

      <your text here>

            Unassigned Unassigned
            rhn-coreos-tunwu Tony Wu
            Matthew Werner Matthew Werner
            0 Vote for this issue
            4 Start watching this issue