NO-JIRA: New rules about CO's conditions #1842
Conversation
|
@hongkailiu: This pull request explicitly references no jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
hongkailiu
force-pushed
the
co-conditions
branch
from
b9b5550 to
3ac7ce2
Compare
| In general, ClusterOperators should contain at least three core conditions: | ||
|
|
||
| * `Progressing` must be true if the operator is actually making change to the operand. | ||
| The change may be anything: desired user state, desired user configuration, observed configuration, version update, etc. |
There was a problem hiding this comment.
Did we want to drop this line when syncing with the Progressing Godocs? I think "may be anything" is pushing away from the tighter scoping you're aiming for, and think it's worth being very clear on what value we're adding in divergence between these docs and the Godocs.
| Operators should not report Progressing only because DaemonSets owned by them are adjusting to a new node from cluster scaleup or a node rebooting from cluster upgrade. | ||
| A component in a cluster with less than 250 nodes must complete a version change within a limited period of time: 90 minutes for Machine Config Operator and 20 minutes for others. Machine Config Operator is given more time as it needs to restart control plane nodes. | ||
| * `Available` must be true if the operand is functional and available in the cluster at the level in status. | ||
| If this is false, it means there is an outage. Someone is probably getting paged. |
There was a problem hiding this comment.
While syncing with Godocs, should this line move to:
Available=Falsemeans at least part of the component is non-functional, and that the condition requires immediate administrator intervention.
The way I read it, that's the same meaning. But if we stick to the same words in both situations, it's more obvious that they have the same meaning (although maybe more risky that Alice thinks "yes, this matches the Godocs" while having a different understanding of the meaning than Bob?).
| * `Available` must be true if the operand is functional and available in the cluster at the level in status. | ||
| If this is false, it means there is an outage. Someone is probably getting paged. | ||
| A component must not report Available=False during the course of a normal upgrade. | ||
| * `Degraded` should be true if the operator has encountered an error that is preventing it or its operand from working properly. |
There was a problem hiding this comment.
This list entry is much shorter than the associated Degraded Godocs. Did we want to catch these docs up more completely with the Godocs?
hongkailiu
force-pushed
the
co-conditions
branch
from
3ac7ce2 to
790c171
Compare
| ### Conditions | ||
|
|
||
| Refer [the godocs](https://godoc.org/github.com/openshift/api/config/v1#ClusterStatusConditionType) for conditions. | ||
|
|
There was a problem hiding this comment.
The link I was talking about is already there.
I did not notice it.
Eventually I copied everything over and then
$ sed -i 's|// ||g' dev-guide/cluster-version-operator/dev/clusteroperator.mdThe main thing we lose here is when to handle it for Degraded and Long Progressing which is OK as discussed in openshift/api#2469 (comment)
This is to sync up the changed from [api#2469](openshift/api#2469) to dev-guide.
hongkailiu
force-pushed
the
co-conditions
branch
from
790c171 to
2659b66
Compare
|
@hongkailiu: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
Inactive enhancement proposals go stale after 28d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
4 participants
This is to sync up the changed from api#2469 to dev-guide.