-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
Strategic Product Work
-
False
-
-
False
-
-
67% To Do, 0% In Progress, 33% Done
-
0
Feature Overview (aka. Goal Summary)
To support multi-tenant environments a request/approval flow is desirable for generally available content within default catalogs.
Goals (aka. expected user outcomes)
- In this model, any tenant with enough privilege can discover installable content and can trigger an install request, which can in turn be approved or denied by a more privileged administrative role.
- Such requests should also have timeouts.
- Administrators should have the ability to define a list of extensions that are automatically approved at the scope of a namespace.
- Administrators should be able to get aware of unapproved and timeout requests via alerts triggered by the platform.
Requirements (aka. Acceptance Criteria):
| Requirement | Notes | isMvp? |
|---|---|---|
| Tenants with enough privilege can discover installable content and trigger an install request, which can in turn be approved or denied by a more privileged administrative role. | YES | |
| Such requests should also have timeouts. | YES | |
| Administrators should have the ability to define a list of extensions that are automatically approved at the scope of a namespace. | YES | |
| Administrators should be able to get aware of unapproved and timeout requests via alerts triggered by the platform. | YES | |
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. | YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. | YES |
Use Cases (Optional):
- A tenant with enough privilege can discover installable content and trigger an install request, which can in turn be approved or denied by a more privileged administrative role before the request timeouts.
- Administrator can configure self-service Operator installs for any tenants on a per catalog level.
- Administrators should be able to get aware of unapproved and timeout requests via alerts triggered by the platform.
Background, and strategic fit
- Cluster-admin involvement/approval is frequently reported as a barrier to Operator adoption
- In certain use cases, it is perceived as an acceptable risk to let cluster tenants install Operators
- The current implementation requires admins hand picking namespaces and RBAC scope upfront which is tedious and also forces namespaced installs which we want to move away from.
This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing
Dependencies (internal and external)
- Approval mechanism that gates Operator install
OLM-1786
Documentation Considerations
