pkg/cvo: Drop the explicit 'upstream' from our replacement ClusterVersion#640
Conversation
openshift-ci
bot
added
the
approved
| }, | ||
| Spec: configv1.ClusterVersionSpec{ | ||
| Upstream: upstream, | ||
| Channel: "fast", |
There was a problem hiding this comment.
Why can't we remove the fast channel as default?
There was a problem hiding this comment.
It's good to have a signal that this code is happening, because it's very serious admin errors or a bug when it trips. For example, we had rhbz#1708697, from the CVO racing cluster-bootstrap during install (fixed by telling the CVO not do push this default into the cluster during install).
…sion Hopefully we never actually have to stuff a CVO-generated ClusterVersion into the cluster; it's just for recovery after admins accidentally delete their existing ClusterVersion. But if we ever do hit this code, we want to push it without spec.upstream, to allow later ClusterVersion-consuming code to say "ah, user doesn't care which upstream I use, so I'll use the best default I'm aware of". This effectively pushes default choice from the CVO that creates the ClusterVersion out to the CVO that consumes the ClusterVersion, and that later CVO is almost certainly more current on which default is best. Similar to openshift/installer@c9095b3451 (data/manifests/bootkube/cvo-overrides: Drop the explicit upstream, 2020-08-28, openshift/installer#4112).
wking
force-pushed
the
drop-default-upstream-from-default-ClusterVersion
branch
from
b8975db to
0b60b87
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, 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 |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
4 similar comments
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/refresh |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
5 similar comments
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
5 participants
Hopefully we never actually have to stuff a CVO-generated ClusterVersion into the cluster; it's just for recovery after admins accidentally delete their existing ClusterVersion. But if we ever do hit this code, we want to push it without
spec.upstream, to allow later ClusterVersion-consuming code to say "ah, user doesn't care which upstream I use, so I'll use the best default I'm aware of". This effectively pushes default choice from the CVO that creates the ClusterVersion out to the CVO that consumes the ClusterVersion, and that later CVO is almost certainly more current on which default is best.Similar to openshift/installer@c9095b3451 (openshift/installer#4112).