Bug 1907313: Don't create ClusterOperator during precreation step if it's present in overrides #488
Conversation
…in overrides Using the installer, if a cluster operator is in overrides list, it is still created during the precreation step. When both the cluster operator and the deployment of an operator are overridden, the CVO (and the installer) waits for ever the end of the end of the provisioning.
openshift-ci-robot
requested review from
LalatenduMohanty and
smarterclayton
guillaumerose
changed the title
openshift-ci-robot
added
bugzilla/severity-unspecified
|
@guillaumerose: This pull request references Bugzilla bug 1907313, which is invalid:
Comment DetailsIn 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. |
|
/bugzilla refresh |
openshift-ci-robot
added
bugzilla/severity-low
|
@LalatenduMohanty: This pull request references Bugzilla bug 1907313, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
DetailsIn 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. |
openshift-ci-robot
removed
the
bugzilla/invalid-bug
| if task.Manifest.GVK != configv1.SchemeGroupVersion.WithKind("ClusterOperator") { | ||
| continue | ||
| } | ||
| ov, ok := getOverrideForManifest(work.Overrides, task.Manifest) |
There was a problem hiding this comment.
Shouldn't be this check come before the if task.Manifest.GVK != configv1.SchemeGroupVersion.WithKind("ClusterOperator") ?
There was a problem hiding this comment.
We could, it is equivalent.
The only difference will be that CVO will log for all types of objects, like: Skipping precreation of deployment foobar as unmanaged. It can be misleading as we only precreate ClusterOperator and not others objects.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: guillaumerose, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
@guillaumerose: All pull requests linked via external trackers have merged: Bugzilla bug 1907313 has been moved to the MODIFIED state. DetailsIn 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. |
This is a hack fix for [1], where we have a delay on 4.6->4.7 updates, and on some 4.7 installs, between the very early ClusterOperator precreation and the operator eventually coming up to set its status conditions. In the interim, there are no conditions, which causes cluster_operator_up to be 0, which causes the critical ClusterOperatorDown to fire. We'll want a more general fix going forward, this commit is a temporary hack to avoid firing the critical ClusterOperatorDown while we build consensus around the general fix. The downside to dropping precreates for this operator is that we lose the must-gather references when the operator fails to come up. That was what precreation was designed to address in 2a469e3 (cvo: When installing or upgrading, fast-fill cluster-operators, 2020-02-07, openshift#318). If we actually get a must-gather without the bare-metal bits and we miss them, we can revisit the approach this hack is taking. Manually picked back to 4.6, which doesn't include b0f73af (Don't create ClusterOperator during precreation step if it's present in overrides, 2020-12-10, openshift#488). [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1929917
5 participants
Using the installer, if a cluster operator is in overrides list, it is
still created during the precreation step.
When both the cluster operator and the deployment of an operator are
overridden, the CVO (and the installer) waits for ever the end of the
end of the provisioning.
I faced this when I tried to disable monitoring for CRC
It means that we can't disable fully an operator with overrides. It has to be deployed once.