Bug 2139639

Summary:	Reduce the number of intermediate upgrade hop when upgrading from CNV v4.9.7 to v4.10.7
Product:	Container Native Virtualization (CNV)	Reporter:	SATHEESARAN <sasundar>
Component:	Installation	Assignee:	Oren Cohen <ocohen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	SATHEESARAN <sasundar>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.9.7	CC:	dholler, ocohen, stirabos
Target Milestone:	---
Target Release:	4.9.7
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	CNV v4.10.7-6	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-08 10:55:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description SATHEESARAN 2022-11-03 07:37:05 UTC

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

Comment 3 Oren Cohen 2022-11-03 16:15:50 UTC

Starting from CNV 4.10.7-6, a direct upgrade path has been added, from v4.9.7

Comment 4 SATHEESARAN 2022-11-21 18:51:08 UTC

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

Comment 6 Dominik Holler 2023-08-04 13:19:08 UTC

Is the target version of this bug 4.9.z r 4.10.z?

Comment 7 Oren Cohen 2023-08-08 07:52:51 UTC

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)