-
Notifications
You must be signed in to change notification settings - Fork 213
make operator status more kube-like #31
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
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The larger implication here is a formalization of a more rigid hierarchy of "truth" for cluster configuration:
Those are the configuration inputs to a cluster. There is a parallel hierarchy of operators:
By making this change we are implying that an operator is a controllable object that has state that is reconciled with the cluster, and that the controllable object is the common interface to "cluster operators". I think that having a consistent set of control knobs for operators is the right thing to do (there are zero today, but the first one would be something like "paused"), rather than having to duck type control knobs on config (since the config hierarchy is not operator focused but functional areas focused).
All "cluster operators" should report status. It should be possible to list all cluster operators. It should be possible to build a UI that summarizes the rough relationships between cluster operators (although in most cases that should not be necessary).
It should be the job of the CVO to summarize operator status underneath the state of an upgrade. Ultimately this is the level of truth:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the CVO is a reconciler, I think it's appropriate to talk about CVOConfig/ClusterVersion having a spec "desired outcome" and a status "actual state". The state the CVO might present to an end user via ClusterVersion would be different than the status passed to OperatorStatus/Operator.status - both are for humans, but one reflects the desired action in cluster version, and the other reflects the desired state the operators themselves are trying to achieve.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you familiar with how OLM works? It would be much nicer if there was a united view of operators, and OLM already figured a lot of this out already (like having a UI 🙂).
It's called the "ClusterServiceVersion" in OLM.
The operators even report back the status of their components: https://github.com/operator-framework/operator-lifecycle-manager/blob/d99daea0086cf92976617dd9326d0ed2b7ba85cf/pkg/api/apis/operators/v1alpha1/clusterserviceversion_types.go#L2
I'm not saying OLM solved all of the pieces needed for bootstrapping, but quite a bit of the stuff being discussed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. These are going to be a deliberate subset of what an OLM operator may support. The conditions on CSV status are very relevant to CV. The spec is not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The biggest difference is that CSV needs conditions, and it's possible that we'll want to drive a phase for CV or something similar to simplify user input (although I'm leaning towards not having a phase and instead displaying human readable status instead).