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] Installed Operators can expose a communication channel with OLM for update readiness #1783

Closed
awgreene opened this issue Oct 1, 2020 · 3 comments
Labels
triage/unresolved Indicates an issue that can not or will not be resolved.
Milestone

Comments

@awgreene
Copy link
Member

awgreene commented Oct 1, 2020

Feature Request

Is your feature request related to a problem? Please describe.
OLM currently infers the state of an operator by inspecting the Kubernetes resources that define the operator. OLM does not provide operators with the means to communicate complex states.

Operators managed by OLM would benefit from the ability to communicate their state directly to OLM through a supported channel. Operators could communicate complex conditions and influence how OLM manages the operator, dramatically improving user experience.

A core requirement of this enhancement is to provide operators with the ability to communicate "Upgrade Readiness", providing operators with the ability to signal to OLM that they should not be upgraded at this time. Consider the following scenario based on OLM today:

An operator installed with automatic updates is executing a critical process that could place the cluster in a bad state if OLM upgrades the operator. While this critical process is running, a new version of the operator becomes available. Since the operator was installed with automatic updates, OLM upgrades the operator without allowing the critical process to finish and places the cluster in an unrecoverable state.

OLM could handle the scenario described above had the operator had the ability to communicate that it should not be upgraded as it ran the critical process.

Describe the solution you'd like
The desired solution can be seen here

@awgreene awgreene added this to the 0.17.0 milestone Oct 1, 2020
@stale
Copy link

stale bot commented Nov 30, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Nov 30, 2020
@openshift-ci-robot openshift-ci-robot added triage/unresolved Indicates an issue that can not or will not be resolved. and removed wontfix labels Dec 1, 2020
@kevinrizza
Copy link
Member

Completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/unresolved Indicates an issue that can not or will not be resolved.
Projects
None yet
Development

No branches or pull requests

3 participants