-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
Strategic Product Work
-
False
-
-
False
-
-
67% To Do, 0% In Progress, 33% Done
-
0
Feature Overview
- Administrative personas need to be able to remove an extension including all the content that was part of the original installation bundle.
- For clean removal of custom controllers, special handling should be implemented for CRDs, which when not removed, are left behind in a functioning state. When they are to be removed this can only happen if the user opts into cascading deletion of managed workloads (F17).
- Special care also needs to be taken to allow the extension to cleanly remove. Extension should get a signal when they are to be removed. This needs to happen in a way and order that allows the extension to run clean up logic as part of a graceful shutdown.
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.
- Compared to today's removal behavior in OLM 0.x, extension removal can now optionally include removing all operands (CRs) and even the CRDs themselves.
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 | YES |
| 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:
- Cluster admin wants to remove an extension that automatically provisioned resources external to the cluster. Upon removal, OLM 1.0 signals the extension that deletion is imminent and waits, allowing the extension to remove any provisioned external resources.
- Cluster admin wants to remove an extension for debugging purposes. OLM 1.0 by default does not remove any Custom Resources or Custom Resource definitions to leave potentially provisioned / managed workloads in tact.
- The cluster admin wants to remove an extension that shipped with auxiliary manifests (like customization of UIs, standard configuration in ConfigMaps etc). Upon removal these additional objects are also removed.
Definition of Done / Acceptance criteria
- all use cases above are implemented
- extension removal by default does not remove any CRs / CRDs
Out of Scope
- Cascading removal of extensions (including CRs and CRDs)
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 removing an extension by default does not cause any impact on the currently managed workloads
- users need to be made aware that CRDs are left behind by default in order to allow re-installation of an operator to take over existing custom resources, and thus, existing running workloads
- it needs to become clear that deletion is not instant and should not be forced as the operator might need to run additional logic for clean removal
- is related to
-
-
- New
-
- relates to
-
-
- New
-
- split to
-
-
- Closed
-
