Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] OLM deletes Operands upon Operator removal #1787

Closed
awgreene opened this issue Oct 1, 2020 · 3 comments
Closed

[RFE] OLM deletes Operands upon Operator removal #1787

awgreene opened this issue Oct 1, 2020 · 3 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Milestone

Comments

@awgreene
Copy link
Member

awgreene commented Oct 1, 2020

Feature Request

Is your feature request related to a problem? Please describe.
As a cluster-admin I can instruct OLM that I want to remove all Operands before removing the Operator, so that I don't end up with orphaned workloads.

Why is this important:
Orphaned workloads are hard to clean up. After the Operator has been removed deleting the custom resource does not clean up secondary resources. It can be hard to find these resources as there is no obligation to put owner references or labels to them. It is probably impossible to find when those resources are outside of the cluster.

Describe the solution you'd like

  • Operands are not automatically removed
  • CRDs are not automatically removed
  • Upon Operator uninstall a cluster-admin can opt-in to the clean up behavior
  • Clean includes Operands (Custom Resource instances) and Custom Resource Definitions
  • The Operand removal should have timeout
  • Hitting the Operand removal timeout should NOT fail Operator removal
  • Hitting the timeout should create an alert event
@awgreene awgreene added this to the 0.17.0 milestone Oct 1, 2020
@hasbro17
Copy link
Contributor

Proposal: operator-framework/enhancements#46

@stale
Copy link

stale bot commented Mar 12, 2021

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contribution.
For more help on your issue, check out the olm-dev channel on the kubernetes slack [1] and the OLM Dev Working Group [2] [1] https://kubernetes.slack.com/archives/C0181L6JYQ2 [2] https://github.com/operator-framework/community#operator-lifecycle-manager-wg

@stale stale bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 12, 2021
@exdx exdx added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Mar 29, 2021
@awgreene
Copy link
Member Author

awgreene commented Aug 5, 2021

The team has come to the conclusion that this feature cannot be completed safely within OLM. The client should be able to understand that the CRs have been deleted before removing the CRDs.

We have introduced the ability to control how an operator is uninstalled via the kubectl operator binary, which will become available in the upcoming v0.4.0 release.

@awgreene awgreene closed this as completed Aug 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants