Description of problem: Upgrade to OCP 4.2 failed How reproducible: All most all the time. Steps to Reproduce: 1. Select the channel stable or fast for 4.1 in cluster setting Actual results: Message: Could not retrieve updates. Unable to retrieve available updates: currently installed version 4.1.20 not found in the "stable-4.2" channel Additional info: =--------------= [quicklab@upi-0 ~]$ curl -H 'Accept: application/json' https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.2| python -m json.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 438 100 438 0 0 420 0 0:00:01 0:00:01 --:--:-- 419 { "edges": [], "nodes": [ { "metadata": { "description": "", "io.openshift.upgrades.graph.release.channels": "stable-4.2", "io.openshift.upgrades.graph.release.manifestref": "sha256:c5337afd85b94c93ec513f21c8545e3f9e36a227f55d41bc1dfb8fcc3f2be129", "url": "https://access.redhat.com/errata/RHBA-2019:2922" }, "payload": "quay.io/openshift-release-dev/ocp-release@sha256:c5337afd85b94c93ec513f21c8545e3f9e36a227f55d41bc1dfb8fcc3f2be129", "version": "4.2.0" } ] } You have new mail in /var/spool/mail/quicklab [quicklab@upi-0 ~]$ oc adm upgrade Cluster version is 4.1.20 warning: Cannot display available updates: Reason: RemoteFailed Message: Unable to retrieve available updates: currently installed version 4.1.20 not found in the "stable-4.2" channel
This is by design, the upgrade from 4.1.20 to 4.2 has not yet been added to the graph. Please see https://access.redhat.com/articles/4495171
Is there a way to find out what specifically is blocking the 4.1.latest -> fast-4.2 upgrade option, or when it will become available? Last week cloud.redhat.com displayed the following message: "To upgrade to 4.2, update your clusters to at least version 4.1.20 and then select the fast-4.2 update channel. Upgrades will be available in the stable channel following a phased release in the fast channel." The article doesn't mention a phased release for the fast-4.2 channel. It says the opposite -- that updates will be available in fast-4.2 as soon as they're GA. Neither the message, nor the linked article, explains why 4.1.20 -> 4.2 isn't available, or when it will be. Where should customers be looking for clarity?
> Is there a way to find out what specifically is blocking the 4.1.latest -> fast-4.2 upgrade option, or when it will become available? Bug 1761557 and bug 1763821 are part of this. [1] shows recent 4.2 nightlies, and you can see differences vs. the latest release by clicking through and setting ?from=..., e.g. [2]. Or from a 4.2 CI build [3]. > The article doesn't mention a phased release for the fast-4.2 channel. It says the opposite -- that updates will be available in fast-4.2 as soon as they're GA. There's a distinction between a release being GA/stable and a particular A->B upgrade into that release being stable. [4] doesn't spend a lot of time on the distinction, but it does have: If issues are discovered with an upgrade between patch levels, Red Hat may withdraw that suggested upgrade for affected versions. A newer patch would become available in the appropriate channels and be suggested for upgrade. which covers this case. And even for candidate-4.2, there's a balance between "folks should only be using candidate-* for clusters they can afford to lose" (arguing for early tagging into the channel) and "this upgrade edge has a non-negligible chance of breaking your cluster" (arguing for not tagging edges that are known to have issues like that). > Neither the message, nor the linked article, explains why 4.1.20 -> 4.2 isn't available, or when it will be. The upgrade will be available when it is stable, hopefully soon. I agree that it would be nice to have the reasons why a given edge was being masked be more easily discoverable. Something like [5] or [6] would give space for that, e.g. [7]. But it's not clear to me if/how we'd want to expose the reasoning as something more machine-readable than "look in the version-control logs". And we don't even have official version control logs at the moment. And even if we did, they wouldn't have a way to expose things like "when is the next 4.2.z going to go stable?", they'd just have "this is what we didn't like about versions and edges we decided not to tag into that channel". [1]: https://openshift-release.svc.ci.openshift.org/#4.2.0-0.nightly [2]: https://openshift-release.svc.ci.openshift.org/releasestream/4.2.0-0.nightly/release/4.2.0-0.nightly-2019-10-18-063630?from=4.2.0 [3]: https://openshift-release.svc.ci.openshift.org/releasestream/4.2.0-0.ci/release/4.2.0-0.ci-2019-10-22-221747?from=4.2.0 [4]: https://access.redhat.com/articles/4495171 [5]: https://github.com/openshift/cincinnati-graph-data/pull/1 [6]: https://github.com/openshift/cincinnati-graph-data/pull/2 [7]: https://github.com/openshift/cincinnati-graph-data/commit/68fb118fc4fd1bc0d4f225f2abefc78405c39845
Thanks for the comments and clarifications. It's hard to document processes that are just now being battle-tested, so I'm glad the team is open to feedback around areas that are less clear from the customer standpoint.
I've marked this bug as being blocked by the one bug that is *currently* known to prevent us from adding the upgrade edge to the graph, this should not be seen as a statement that as soon as that bug is closed it's 100% certain that the upgrade edge will be introduced. Additional internal and phase rollout data will determine when that happens. We're definitely looking at how to better communicate this.