I am unable to reproduce, but what I suspect was happening is starting in 4.6, the console checks for the channels in `cv.status.desired.channels` (but otherwise falls back to hard-coded values--see https://github.com/openshift/console/blob/master/frontend/public/module/k8s/cluster-settings.ts#L45), and I suspect `cv.status.desired.channels` in 4.6.0-fc.5 did not include `fast` and `stable`, so they did not appear in the dropdown picker (but `candidate` did). In trying to reproduce, I am not seeing `cv.spec.desired.channels` in 4.6.0-fc.4 or 4.6.0-fc.5, so the console is falling back to the hard-coded values (see https://github.com/openshift/console/blob/master/frontend/public/module/k8s/cluster-settings.ts#L45). @Trevor, does this sound plausible to you?
> ...I suspect `cv.status.desired.channels` in 4.6.0-fc.5 did not include `fast` and `stable`... Correct. Feature candidates (fc) and release candidates (rc) are never going to be supported releases, and only supported releases will be promoted into fast/stable channels. > In trying to reproduce, I am not seeing `cv.spec.desired.channels` in 4.6.0-fc.4 or 4.6.0-fc.5... Are you installing via their canonical pullspecs? $ curl -s https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp-dev-preview/4.6.0-fc.5/release.txt | grep Pull Pull From: quay.io/openshift-release-dev/ocp-release@sha256:5883d0db15939484bd477147e6949c53fbc6f551ec20a0f1106b8a3acfb86ef8 I realized last week that if you install from an alternative pullspec, e.g. registry.svc.ci.openshift.org/ocp/release@sha256:5883d0db15939484bd477147e6949c53fbc6f551ec20a0f1106b8a3acfb86ef8 , that the cluster-version operator will not claim to find a matching version from which to extract the current channel list. Going forward, we will likely pivot to comparing only the digest, for digest-based pullspecs, instead of the full pullspec with irrelevant canonical repository ;).
'oc get -o yaml clusterversion version' should be sufficient to distinguish between cluster-version side stuff and the consuming console code, if you can attach that.
Reassigning to Trevor as this is an issue with the CVO. He'll either fix this bug or file a new one to cover the issue noted in https://bugzilla.redhat.com/show_bug.cgi?id=1879976#c4.
I'll wait for ClusterVersion YAML confirming that the issue here is the image comparison discussed in comment 4. Rajni, can you provide that YAML, per comment 5?
Still waiting on ClusterVersion YAML requested in comment 7.
Still waiting on ClusterVersion YAML requested in comment 7. I'm going to assume we'll never get it, and we'll just move forward with the fix for the comment 4 image comparison issue next sprint.
I thought I understood what was going on here with comment 4, but turns out we match ourselves by version number in the Cincinnati graph [1], so I'm back to having no idea what was going on here. Closing INSUFFICIENT_DATA, but please re-open with ClusterVersion YAML if you can reproduce. [1]: https://github.com/openshift/cluster-version-operator/blob/dc6f4f07d8986272b538b5d6bed9e8b6412b3ce6/pkg/cincinnati/cincinnati.go#L119
I should have linked code in comment 4, back when I seem to have understood where the pullspec comparison was happening which should have been a digest comparison or version-string comparison ;). Reproduced today by: 1. Install a 4.6.6 cluster with an alternative pullspec, e.g. via cluster-bot 'launch 4.6.6', which gives a cluster with: status: desired: image: registry.svc.ci.openshift.org/ocp/release@sha256:c7e8f18e8116356701bd23ae3a23fb9892dd5ea66c8300662ef30563d7104f39 version: 4.6.6 2. Set the channel (this is the usual default, but my cluster-bot-launched cluster clears the default, so I had to manually restore it): $ oc patch clusterversion version --type json -p '[{"op": "add", "path": "/spec/channel", "value": "stable-4.6"}]' 3. Waited 30 minutes. Still getting: $ oc get -o json clusterversion version | jq .status.desired.channels null 4. Patch to use the canonical 4.6.6 pullspec: $ oc adm upgrade --allow-explicit-upgrade --to-image quay.io/openshift-release-dev/ocp-release@sha256:c7e8f18e8116356701bd23ae3a23fb9892dd5ea66c8300662ef30563d7104f39 5. Moments later: $ oc get -o json clusterversion version | jq .status.desired.channels [ "candidate-4.6", "eus-4.6", "fast-4.6", "stable-4.6" ] I'm hunting for the code I missed in comment 10.
Ah, here it is [1]. I'll get a pull up shortly. [1]: https://github.com/openshift/cluster-version-operator/pull/419/files#diff-490d2318856a4a078992ebab5b3f70db6b2c074dee480aa0112dc7c52e37550eR634
Reproduced with 4.6.0-0.nightly-2020-12-16-201440 by: 1. Install a 4.6 cluster with registry.svc.ci.openshift.org/ocp/release@sha256:faf7c37ca625da7ddf71be3d492a4a245536d600ff99595e6893b1dab026fea1 2. Patched to use below graph { "nodes": [ { "version": "4.6.0-0.nightly-2020-12-16-201440", "payload": "quay.io/openshift-release-dev/ocp-release@sha256:faf7c37ca625da7ddf71be3d492a4a245536d600ff99595e6893b1dab026fea1", "metadata": { "io.openshift.upgrades.graph.release.channels": "channel-a,channel-b" } }, { "version": "4.7.0-fc.0", "payload": "quay.io/openshift-release-dev/ocp-release@sha256:2419f9cd3ea9bd114764855653012e305ade2527210d332bfdd6dbdae538bd66", "metadata": { "io.openshift.upgrades.graph.release.channels": "channel-a,channel-b" } } ], "edges": [ [0,1] ] } 3. # oc get -o json clusterversion version | jq .status.desired.channels null Verified with 4.7.0-0.nightly-2020-12-19-192007 by: 1. Install a 4.7 cluster with registry.svc.ci.openshift.org/ocp/release@sha256:3b16e75f9f7b38cd7e02d304ea4982de2c03061b2705851edccfad36b22d4cb4 2. Patched to use below graph { "nodes": [ { "version": "4.7.0-0.nightly-2020-12-19-192007", "payload": "example.com@sha256:3b16e75f9f7b38cd7e02d304ea4982de2c03061b2705851edccfad36b22d4cb4", "metadata": { "io.openshift.upgrades.graph.release.channels": "channel-a,channel-b" } }, { "version": "4.7.0-0.nightly-2020-12-20-031435", "payload": "registry.svc.ci.openshift.org/ocp/release@sha256:5fbd961fe2fcafd95dbccaa731975ed65b237b7bc461070c6b1f193cd607d37b", "metadata": { "io.openshift.upgrades.graph.release.channels": "channel-a,channel-b" } } ], "edges": [ [0,1] ] } 3. # oc get -o json clusterversion version | jq .status.desired.channels [ "channel-a", "channel-b" ] With the fix, status.desired.channels is able to be populated if digest matches.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5633