-
Feature
-
Resolution: Done
-
Major
-
None
-
Strategic Product Work
-
False
-
-
False
-
OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
-
0% To Do, 0% In Progress, 100% Done
-
0
-
Program Call
Feature Overview
- Administrative personas need to be able to remove an extension including all the content that was part of the original installation bundle.
Goals
- Administrators benefit from predictable cluster state when they are able to cleanly remove an OLM-managed extension. Clusters are easier to troubleshoot when they are able to be set back to the state before an extension got installed.
Requirements
Requirement | Notes | isMvp? |
---|---|---|
Extension bundle content is completely removable | YES | |
Any custom objects (CR) and CRDs that belong to the extension can only be removed when cascading deletion (F17) is chosen | NO | |
If extension removal leaves behind CRDs, those must not contain any references to the extension controller | e.g. CRD conversion webhooks | NO |
Extensions get a signal from OLM to initiate any clean up the extension needs to perfom before getting removed | this is different from custom objects getting deleted | NO |
OLM waits for appropriate amount of time for any clean up logic to be concluded | The amount of time should have a default, and the time period should be configurable per installed extension | NO |
OLM can optionally trigger a forceful removal of an extension if a reasonable time period has passed and the extension did not signal completion of of clean-up | This force override should be opt-in | NO |
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
Main use case:
- The cluster admin wants to remove an extension that shipped with auxiliary manifests (like customization of UIs, standard configuration in ConfigMaps, etc) in the Operator bundle. Upon removal, all these additional objects are also removed.
Definition of Done / Acceptance criteria
- all use cases above are implemented
Background, and strategic fit
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
Assumptions
- Extensions are handled at the cluster scope level
Documentation Considerations
- users need to understand that in this release, "removing an extension/Operator" means removing of all bundle contents including CRDs, without an opt-out mechanism.
- blocks
-
OCPSTRAT-199 [Phase 1 MVP/Tech Preview] OLM 1.0 - Cluster-level Operator API (B1)
- Closed
- depends on
-
OPRUN-2770 [upstream] Deppy/Operator API Integration
- Dev Complete
-
OPRUN-2832 [upstream] Build Deppy library for simple resolution
- Dev Complete
- incorporates
-
RFE-3332 OLM: CSV installable dependecies
- Accepted
- is related to
-
OPRUN-2935 [Tech Preview] Include rukpak OLMv1 MVP.1 in OCP payload
- Closed
-
OPRUN-2940 [Tech Preview] Downstream builds for rukpak OLMv1 MVP.1
- Closed
- split from
-
OCPSTRAT-76 [PRD scope] OLM 1.0 - Extension Removal (F16)
- Closed
- links to