reconcile clusteroperator status more frequently #3006
Conversation
openshift-ci
bot
added
the
needs-ok-to-test
|
Hi @sanchezl. Thanks for your PR. I'm waiting for a operator-framework member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
sanchezl
force-pushed
the
sanchezl-patch-1
branch
from
712477e to
100bf56
Compare
|
/ok-to-test |
openshift-ci
bot
added
ok-to-test
|
/retest |
1 similar comment
|
/retest |
sanchezl
force-pushed
the
sanchezl-patch-1
branch
2 times, most recently
from
9cf60d7 to
1752b4d
Compare
|
/lgtm |
|
@mfojtik: changing LGTM is restricted to collaborators 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 kubernetes/test-infra repository. |
|
@joelanford can we get a review on this one? |
|
/lgtm |
If status is modified, the operator must set status to proper values. This ensures that accidents cannot permanently reset status and gives a clear indication that the operator is "live". This came up as important when operators were NOT live, during cert rotations and we had no indication of problems. Signed-off-by: Luis Sanchez <[email protected]>
perdasilva
force-pushed
the
sanchezl-patch-1
branch
from
f4420ab to
4e187c0
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: perdasilva, sanchezl The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/lgtm |
Needed for openshift/cluster-kube-apiserver-operator#1423.
If status is modified, the operator must set status to proper values. This ensures that accidents cannot permanently reset status and gives a clear indication that the operator is "live". This came up as important when operators were NOT live, during cert rotations and we had no indication of problems.
Ideally this should happen on every sync (e.g. move this logic to its own crontroller loop, as it was done for the
operator-lifecycle-manager) but setting the backoff interval on sucess small enough to avoid triggering the future stale condition controller from flagging these conditions as stale /Unknownshould be sufficient as a quick fix.