Bug 2280818 - [odf-operator] csi-addons upgrade should be handled by ocs-client-op
Summary: [odf-operator] csi-addons upgrade should be handled by ocs-client-op
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: odf-operator
Version: 4.16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ODF 4.16.0
Assignee: Nitin Goyal
QA Contact: Jilju Joy
URL:
Whiteboard: isf-provider
Depends On:
Blocks: 2280820
TreeView+ depends on / blocked
 
Reported: 2024-05-16 12:41 UTC by Leela Venkaiah Gangavarapu
Modified: 2024-07-17 13:23 UTC (History)
5 users (show)

Fixed In Version: 4.16.0-106
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 2280820 (view as bug list)
Environment:
Last Closed: 2024-07-17 13:22:55 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github red-hat-storage odf-operator pull 411 0 None open controllers: Do not manage csi addons if running in provider mode 2024-05-17 05:19:15 UTC
Github red-hat-storage odf-operator pull 413 0 None open Bug 2280818:[release-4.16] controllers: Do not manage csi addons if running in provider mode 2024-05-17 08:55:57 UTC
Red Hat Product Errata RHSA-2024:4591 0 None None None 2024-07-17 13:23:03 UTC

Description Leela Venkaiah Gangavarapu 2024-05-16 12:41:32 UTC
It was seen in https://bugzilla.redhat.com/show_bug.cgi?id=2276565 (4.15) that client operator upgrade didn't trigger csi-addons upgrade from 4.14 to 4.15, similarly in 4.16 we don't have a clear logical owner who can update csi-addons depending on deployment modes.

We want to tie upgrade of csi-addons to the operator that becomes a logical owner depending on deployment mode as follows:

1. only ocs-client-operator deployed: ocs-client-op should upgrade csi-addons
2. odf in non-provider mode: odf-operator should upgrade csi-addons
3. odf in provider mode: ocs-client-op should upgrade csi-addons

We need to continue this for atleast upto a couple of releases (~4.18).

Testing:
1. Deploy 4.16 in above mentioned cases
2. When the ODF is upgraded to earlier builds of next release (4.17) csi-addons should get upgraded as well. Specifically mentioning earlier builds as by 4.17 FF builds might get changed.

Comment 11 Jilju Joy 2024-06-12 12:22:35 UTC
Verified in ODF 4.16.0-125

ODF on provider cluster upgraded from 4.16.0-125 to 4.17.0-19. Ocs-client-operator and odf-csi-addons-operator were installed in the same namespace of odf-operator(this is the default configuration). Ocs-client-operator and odf-csi-addons-operator were upgraded automatically to 4.17.0-19. 


% oc get csv
NAME                                        DISPLAY                            VERSION               REPLACES                                     PHASE
mcg-operator.v4.17.0-19.stable              NooBaa Operator                    4.17.0-19.stable      mcg-operator.v4.16.0-125.stable              Succeeded
metallb-operator.v4.16.0-202405161711       MetalLB Operator                   4.16.0-202405161711   metallb-operator.v4.15.0-202405161507        Succeeded
ocs-client-operator.v4.17.0-19.stable       OpenShift Data Foundation Client   4.17.0-19.stable      ocs-client-operator.v4.16.0-125.stable       Succeeded
ocs-operator.v4.17.0-19.stable              OpenShift Container Storage        4.17.0-19.stable      ocs-operator.v4.16.0-125.stable              Succeeded
odf-csi-addons-operator.v4.17.0-19.stable   CSI Addons                         4.17.0-19.stable      odf-csi-addons-operator.v4.16.0-125.stable   Succeeded
odf-operator.v4.17.0-19.stable              OpenShift Data Foundation          4.17.0-19.stable      odf-operator.v4.16.0-125.stable              Succeeded
odf-prometheus-operator.v4.17.0-19.stable   Prometheus Operator                4.17.0-19.stable      odf-prometheus-operator.v4.16.0-125.stable   Succeeded
recipe.v4.17.0-19.stable                    Recipe                             4.17.0-19.stable      recipe.v4.16.0-125.stable                    Succeeded
rook-ceph-operator.v4.17.0-19.stable        Rook-Ceph                          4.17.0-19.stable      rook-ceph-operator.v4.16.0-125.stable        Succeeded

OCP version is 4.17.0-0.nightly-2024-06-07-045541 on provider cluster (upgraded from 4.16.0 before the testing)


Clients were on hosted clusters using kubevirt and agent(2 each). Total 4 storageclients were connected from 4 hosted clusters. Subscription channel of client-operator in these hosted clusters were changed automatically to stable-4.17. After changing the catalogsource image to 4.17.0-19, ocs-client-operator and odf-csi-addons-operator on client clusters were upgraded automatically to 4.17.0-19.

% oc get csv
NAME                                        DISPLAY                            VERSION            REPLACES                                     PHASE
ocs-client-operator.v4.17.0-19.stable       OpenShift Data Foundation Client   4.17.0-19.stable   ocs-client-operator.v4.16.0-125.stable       Succeeded
odf-csi-addons-operator.v4.17.0-19.stable   CSI Addons                         4.17.0-19.stable   odf-csi-addons-operator.v4.16.0-125.stable   Succeeded

OCP version on kubevirt based hosted clusters is 4.15.13 and agent based hosted clusters is 4.16.0-ec.6.

Comment 12 errata-xmlrpc 2024-07-17 13:22:55 UTC
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 (Important: Red Hat OpenShift Data Foundation 4.16.0 security, enhancement & bug fix 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-2024:4591


Note You need to log in before you can comment on or make changes to this bug.