-
Feature
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
Strategic Product Work
-
False
-
-
False
-
OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
-
50% To Do, 0% In Progress, 50% Done
-
0
-
Backlog Refinement
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>
Background
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>
- is related to
-
OCPSTRAT-1117 OLM v1: Support watchNamespaces via parameterization for registry+v1 bundles
- Closed