Description of problem: ----------------------- The upgrading CNV cluster v4.9.7-5(nightly build) to v4.10.7-39(nightly build), has a upgrade path: 4.9.7-5 ->4.10.0 -> 4.10.1 -> 4.10.2 -> 4.10.3 -> 4.10.4 -> 4.10.5 -> 4.10.6 -> 4.10.7-39, which is a longer upgrade path. Upgrading from CNV v4.9.6(GA) to CNV 4.10.6(GA) had a much lesser hops to upgrade: 4.9.6-> 4.10.4 -> 4.10.5 -> 4.10.6 Version-Release number of selected component (if applicable): ------------------------------------------------------------- CNV v4.9.7-5 How reproducible: ------------------ Always Steps to Reproduce: ------------------- 1. Find out the upgrade path of CNV v4.9.7-5 to CNV 4.10.7-39 using CNV explorer tool Actual results: --------------- Upgrade path was much longer 4.9.7-5 ->4.10.0 -> 4.10.1 -> 4.10.2 -> 4.10.3 -> 4.10.4 -> 4.10.5 -> 4.10.6 -> 4.10.7-39 Expected results: ----------------- Much lesser hops to upgrade would be more efficient to upgrade
Starting from CNV 4.10.7-6, a direct upgrade path has been added, from v4.9.7
Upgrade from OCP 4.9.51 and CNV 4.9.7-50 to OCP 4.10.40 and CNV 4.10.7. Upgrade was successful with no intermediate hops during upgrade. There exists the direct upgrade from CNV-4.9.7 to CNV-4.10.7 Also verified that HCO was stable after upgrade [root@ ~]$ oc get csv -n openshift-cnv NAME DISPLAY VERSION REPLACES PHASE jaeger-operator.v1.38.0-2 Red Hat OpenShift distributed tracing platform 1.38.0-2 jaeger-operator.v1.36.0-2 Succeeded kiali-operator.v1.57.3 Kiali Operator 1.57.3 kiali-operator.v1.48.3 Succeeded kubevirt-hyperconverged-operator.v4.10.7 OpenShift Virtualization 4.10.7 kubevirt-hyperconverged-operator.v4.9.7 Succeeded servicemeshoperator.v2.3.0 Red Hat OpenShift Service Mesh 2.3.0-0 servicemeshoperator.v2.2.3 Succeeded
Is the target version of this bug 4.9.z r 4.10.z?
A direct upgrade path has been added from 4.9.7 to 4.10.7, so the target version of this BZ is 4.10.z (4.10.7)