Aggiornamento o sostituzione dei nodi di lavoro VPC che utilizzano OpenShift Data Foundation

Virtual Private Cloud

Per i cluster VPC con una soluzione di archiviazione come OpenShift Data Foundation, è necessario cordonare, svuotare e aggiornare ogni nodo worker in modo sequenziale. Per i nodi di lavoro bare metal, ora è possibile utilizzare il comando worker reload al posto di worker replace``. Se si è distribuito OpenShift Data Foundation a un sottoinsieme di nodi worker nel cluster, dopo aver aggiornato il nodo worker, è necessario modificare la risorsa ocscluster per includere il nuovo nodo worker.

La seguente esercitazione tratta gli aggiornamenti maggiori e minori e gli aggiornamenti dei nodi worker.

Major update: Completa la procedura con questa etichetta per applicare un aggiornamento principale; ad esempio, se stai aggiornando i tuoi nodi di lavoro a una nuova versione principale, come ad esempio da 4.11 a 4.12 e OpenShift Data Foundation da 4.11 a 4.12.
Minor update: Completa la procedura con questa etichetta per applicare un aggiornamento della patch, ad esempio se stai eseguendo l'aggiornamento da 4.12.15_1542_openshift a 4.12.16_1544_openshift mantenendo OpenShift Data Foundation alla versione 4.12. È necessario ripetere questi passi per ogni nodo che si desidera aggiornare.
Worker replace: Completa i passi con questa etichetta se stai sostituendo un nodo di lavoro alla stessa versione di patch. È necessario ripetere queste operazioni per ogni nodo che si desidera sostituire.

Il salto di versioni durante un aggiornamento, ad esempio da 4.8 a, non 4.12 è supportato.

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Prima di eseguire l'aggiornamento dei tuoi nodi di lavoro, assicurati di eseguire il backup dei tuoi dati dell'applicazione. Inoltre, pianifica di completare la seguente procedura per un nodo di lavoro alla volta. Ripetere questi passaggi per ogni nodo di lavoro che si desidera aggiornare.

Controllare lo stato del cluster di archiviazione

Major update Minor update Worker replace

Elenca i pod eseguendo il seguente comando. Verificare che tutti i pod nello spazio dei nomi openshift-storage siano in buono stato. Gestire tutti i pod che non si trovano nello stato “ Running ” o “ Completed ”.
```
	oc get pods -n openshift-storage
```

Eseguire il seguente comando e verificare che Phase di ocs-storagecluster sia Ready.

	oc get storagecluster -n openshift-storage

Output di esempio

	NAME                 AGE     PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   3m49s   Ready              2025-04-06T09:37:49Z   4.16.9

Verificare lo stato di Ceph Storage eseguendo il seguente comando. Verificare che lo stato di salute sia HEALTH_OK, che tutti gli OSD siano up e IN e che tutti gli pgs siano active+clean. Se uno di questi controlli non riesce, aprire un caso di assistenza. Nei dettagli del caso, assicurarsi di includere tutti i file di log, i messaggi di errore o gli output dei comandi pertinenti. Risolvere eventuali problemi prima di continuare.

	oc rsh -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-operator) ceph status -c /var/lib/rook/openshift-storage/openshift-storage.config

Output di esempio

	health: HEALTH_OK  # Verify health is HEALTH_OK
	services:
		mon: 3 daemons, quorum a,b,c (age 3h)
		mgr: a(active, since 6h)
		mds: ocs-storagecluster-cephfilesystem:1 {0=ocs-storagecluster-cephfilesystem-b=up:active} 1 up:standby-replay
		osd: 27 osds: 27 up (since 2h), 27 in (since 111m) # Verify OSDs are “up” and “in”
		rgw: 2 daemons active (ocs.storagecluster.cephobjectstore.a, ocs.storagecluster.cephobjectstore.b)
	data:
		pools:   10 pools, 1136 pgs
		objects: 5.50M objects, 3.3 TiB
		usage:   9.9 TiB used, 43 TiB / 53 TiB avail
		pgs:     1136 active+clean   # Verify psgs are active+clean
	io:
		client:   93 KiB/s rd, 2.0 MiB/s wr, 5 op/s rd, 29 op/s wr

Ripetere questi controlli prima di ripetere la procedura di aggiornamento per altri nodi. L'eliminazione di più di un pod OSD alla volta potrebbe compromettere i dati degli utenti.

Aggiorna il master cluster

Major update

Se stai aggiornando i tuoi nodi di lavoro a una nuova versione principale, ad esempio da 4.11 a 4.12, aggiorna prima il master cluster.

	ibmcloud oc cluster master update --cluster CLUSTER_NAME --version MAJOR.MINOR.PATCH --force-update

Comando di esempio:

	ibmcloud oc cluster master update --cluster mycluster --version 4.21.31 --force-update

Attendere qualche minuto, quindi verificare che l'aggiornamento del master sia stato completato.
```
	  ibmcloud oc cluster ls
```

Decidere quali nodi di archiviazione si desidera aggiornare o sostituire

Major update Minor update Worker replace

Elenca i tuoi nodi di lavoro utilizzando oc get nodes e determina quali nodi di archiviazione vuoi aggiornare.

oc get nodes

Output di esempio

NAME           STATUS   ROLES           AGE    VERSION
10.241.0.4     Ready    master,worker   106s   v1.21.6+4b61f94
10.241.128.4   Ready    master,worker   22d    v1.21.6+bb8d50a
10.241.64.4    Ready    master,worker   22d    v1.21.6+bb8d50a

Assicurarsi che il cluster di storage sia sano

Major update Minor update Worker replace

Eseguire i seguenti comandi per verificare lo stato del cluster di storage.

oc get storagecluster -n openshift-storage
oc get cephcluster -n openshift-storage

Assicurarsi che il cluster di storage sia sano prima di continuare.

Delimitare e ridimensionare la base dati “ OpenShift ”

Major update Minor update Worker replace

Ridimensionare le istanze di rook-ceph-mon, rook-ceph-osd e crashcollector prima di procedere allo svuotamento garantisce che questi processi di archiviazione vengano arrestati correttamente, anziché essere terminati forzatamente. I pod OSD e monitor in esecuzione devono essere arrestati in modo corretto, in modo che Ceph possa sospendere in sicurezza le operazioni di I/O e mantenere l'integrità dei dati mentre il nodo è offline. Dopo che il nodo aggiornato o sostituito si è ricollegato al cluster, l’operatore Rook-Ceph riporta automaticamente queste distribuzioni al numero originale di repliche.

Cordone il nodo. Il cordonamento del nodo impedisce che qualsiasi pod venga pianificato su quel nodo mentre si riduce la scala delle distribuzioni ODF.
```
	oc adm cordon NODE_NAME
```
Output di esempio
```
	node/10.241.0.4 cordoned
```
Individua i pod “ rook-ceph-mon ” e “ rook-ceph-osd ” in esecuzione sul nodo che stai aggiornando. Prendi nota dei nomi dei pod presenti nell'output: ti serviranno nel passaggio successivo.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
Il nome del deployment corrisponde al nome del pod senza il simbolo di hash " ReplicaSet " finale e senza i suffissi relativi all'ID del pod. Ad esempio, un pod denominato rook-ceph-osd-1-6d9f99c68f-pgvxt appartiene al deployment rook-ceph-osd-1, mentre un pod denominato rook-ceph-mon-e-85fbb8bcc-kttbt appartiene al deployment rook-ceph-mon-e.
Riduci la scala delle distribuzioni relative ai pod individuati nel passaggio precedente. Sostituisci ROOK_CEPH_MON_DEPLOYMENT e ROOK_CEPH_OSD_DEPLOYMENT con i nomi delle distribuzioni ricavati dai nomi dei pod. Se il comando precedente non ha restituito alcun pod rook-ceph-mon o rook-ceph-osd su questo nodo, saltare questi due comandi e passare al comando crashcollector.
```
	oc scale deployment ROOK_CEPH_MON_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment ROOK_CEPH_OSD_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE_NAME --replicas=0 -n openshift-storage
```
Se il comando restituisce " error: no objects passed to scale", verificare che su questo nodo non sia in esecuzione alcun pod crashcollector eseguendo il comando " oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep crashcollector". Se non viene restituito alcun pod, puoi tranquillamente saltare questo comando e proseguire.

Svuotare il nodo di lavoro

Major update Minor update Worker replace

Svuotare il nodo per rimuovere tutti i pod. Quando scarichi il nodo di lavoro, i pod si spostano sugli altri nodi di lavoro assicurandoti che non vi sia alcun tempo di inattività. Il drenaggio garantisce inoltre che non vi sia alcuna interruzione del budget di interruzione del pod.

	oc adm drain NODE_NAME --force --delete-emptydir-data --ignore-daemonsets

Output di esempio

	evicting pod "managed-storage-validation-webhooks-7fd79bc9f7-pdpv6"
	evicting pod "calico-kube-controllers-647dbbd685-fmrp9"
	evicting pod "certified-operators-2v852"
	evicting pod "csi-snapshot-controller-77fbf474df-47ddt"
	evicting pod "calico-typha-8574d89b8c-7f2cc"
	evicting pod "dns-operator-6d48cbff67-vrrsw"
	evicting pod "router-default-6fc798b98b-9m6kh"
	evicting pod "prometheus-adapter-5b77ffdd5f-hzqrp"
	evicting pod "alertmanager-main-1"
	evicting pod "prometheus-k8s-0"
	evicting pod "network-check-source-66c7fbb86-2r78z"

Se durante lo scaricamento alcuni pod di NooBaa dovessero bloccarsi, eliminali nel seguente ordine in modo che vengano riprogrammati su un nodo diverso.

	oc delete pod -n openshift-storage -l app=noobaa-db

	oc delete pod -n openshift-storage -l app=noobaa-core

	oc delete pod -n openshift-storage -l app=noobaa-endpoint

	oc delete pod -n openshift-storage -l app=noobaa-operator

Attendere il termine del drenaggio, quindi completare i passaggi seguenti per aggiornare il nodo worker.

Ripulire i volumi persistenti dei nodi di lavoro bare metal

Major update Minor update Worker replace

Solo per i nodi worker bare metal: se si sta aggiornando o sostituendo un nodo worker bare metal, seguire la procedura riportata di seguito per cancellare i dischi ODF e preparare il nodo per la nuova distribuzione. Se stai lavorando con nodi di lavoro basati su istanze di server virtuali (VSI), salta questa sezione e passa alla sezione " Aggiornamento del nodo di lavoro ".

Prima di iniziare, assicurati di aver completato i passaggi precedenti relativi all’isolamento e allo svuotamento del nodo di lavoro.

Cancella i dischi ODF sul nodo bare metal per prepararlo alla creazione di un nuovo volume persistente. Avvia un pod di debug sul nodo che stai aggiornando. Sostituisci " NODE_NAME " con il nome del tuo nodo worker bare metal.
```
	kubectl debug node/NODE_NAME -it --image=registry.access.redhat.com/ubi8/ubi
```
Comando di esempio
```
	kubectl debug node/kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -it --image=registry.access.redhat.com/ubi8/ubi
```
All'interno del pod di debug, passare alla directory principale dell'host.
```
	chroot /host
```

Cancella tutti i dischi NVMe utilizzati da ODF. Regolare l'intervallo dei dischi (nvme{0..7}n1) in base al numero di dischi presenti nella configurazione.

	for disk in /dev/nvme{0..7}n1; do
	  echo "Wiping $disk..."
	  wipefs -af $disk
	  dd if=/dev/zero of=$disk bs=1M count=100
	  sgdisk --zap-all $disk 2>/dev/null || true
	done

Verificare che i dischi siano puliti e non presentino più alcuna traccia del file system.
```
	for disk in /dev/nvme{0..7}n1; do
	  echo "=== $disk ==="
	  blkid $disk 2>&1 || echo "Clean"
	done
```
Per ogni disco, nell'output dovrebbe comparire la dicitura "Clean", a indicare che tutte le firme del filesystem sono state rimosse.
Esci dal pod di debug.
```
	exit
	exit
```

Elenca le risorse localvolumediscoveryresults per individuare la voce relativa al nodo che stai aggiornando.

	kubectl get localvolumediscoveryresults -n openshift-local-storage

Output di esempio

	NAME                                                                      AGE
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3   5d
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000004a1   5d

Elimina la risorsa “ localvolumediscoveryresults ” relativa al nodo che stai aggiornando. Sostituisci " DISCOVERY_RESULT_NAME " con il nome indicato nel passaggio precedente.

	kubectl delete localvolumediscoveryresults DISCOVERY_RESULT_NAME -n openshift-local-storage

Comando di esempio

	kubectl delete localvolumediscoveryresults discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -n openshift-local-storage

Dopo aver completato questi passaggi, passare alla sezione successiva per aggiornare il nodo di lavoro. I nuovi volumi persistenti vengono creati e pianificati automaticamente sul nodo bare metal dopo il suo riavvio.

Aggiornare il nodo worker

Major update Minor update Worker replace

Elenca i tuoi nodi di lavoro utilizzando il comando ibmcloud oc worker ls e trova il nodo di lavoro che hai isolato e svuotato nel passo precedente.

	ibmcloud oc worker ls -c CLUSTER

Output di esempio

	ID                                                 Primary IP     Flavor     State    Status   Zone        Version
	kube-c85ra07w091uv4nid9ug-vpcoc-default-000001c1   10.241.128.4   bx2.4x16   normal   Ready    us-east-3   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000288   10.241.0.4     bx2.4x16   normal   Ready    us-east-1   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000352   10.241.64.4    bx2.4x16   normal   Ready    us-east-2   4.8.29_1544_openshift*

Aggiornare il nodo worker. Per i nodi worker bare metal, utilizzare il comando worker reload. Per i nodi worker dell'istanza di server virtuale (VSI), utilizzare il comando worker replace.

Nodi worker in metallo nudo: Utilizzare il comando worker reload per ricaricare il nodo worker. Questo comando è supportato per i worker bare metal di VPC. sh {: pre} ibmcloud oc worker reload --worker NODE_NAME Nodi di lavoro VSI: Major update Minor update Esempio di comando per sostituire il nodo di lavoro e applicare l'ultimo aggiornamento della patch. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME --update Nodi di lavoro VSI: Worker replace Esempio di comando per sostituire il nodo di lavoro senza applicare l'ultimo aggiornamento della patch. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME Esempio di output per la sostituzione del nodo worker VSI: sh {: screen} The replacement worker node is created in the same zone with the same flavor, but gets new public or private IP addresses. During the replacement, all pods might be rescheduled onto other worker nodes and data is deleted if not stored outside the pod. To avoid downtime, ensure that you have enough worker nodes to handle your workload while the selected worker nodes are being replaced. Replace worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288? [y/N]> y Deleting worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288 and creating a new worker node in cluster

Attendere che il nodo worker venga ricaricato o sostituito e quindi elencare i nodi worker. Tenere presente che questo processo potrebbe richiedere 20 minuti o più.

	oc get nodes

Output di esempio

	NAME           STATUS   ROLES           AGE   VERSION
	10.241.0.4     Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.128.4   Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.64.4    Ready    master,worker   22d   v1.21.6+bb8d50a

Ripulisci le risorse dal vecchio nodo

Major update Minor update Worker replace

Dopo che il nodo si è ricollegato al cluster, l’operatore Ceph di Rook ridimensiona automaticamente verso l’alto le distribuzioni rook-ceph-mon, rook-ceph-osd e crashcollector. Verificare che i pod ODF siano in esecuzione prima di proseguire.

Verificare che i pod rook-ceph-mon e rook-ceph-osd, il cui numero era stato ridotto in precedenza, siano tornati allo stato " Running " sul nodo aggiornato. Sostituisci “ NODE_NAME ” con il nome del nodo aggiornato o sostituito.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
Verifica che l'output mostri i pod " rook-ceph-mon " e " rook-ceph-osd " nello stato " Running ". Se mancano ancora dei pod o non sono ancora presenti in Running, attendi qualche minuto ed esegui nuovamente il comando prima di procedere.
Verificare che il pod OSD sia stato avviato sul nodo sostituito in stato “ Running ”. Sostituisci " NODE_NAME " con il nome del nuovo nodo sostitutivo.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep osd
```
Se il pod è in esecuzione, procedere ad aggiornare la risorsa OcsCluster con il nuovo nodo. Se il pod non funziona correttamente, procedere come segue. Se più di un pod OSD non è in stato " Running", interrompere l'operazione e contattare l'assistenza. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere qualsiasi file di registro, messaggio di errore o output di comando pertinente.
Passare al progetto openshift-storage.
```
	oc project openshift-storage
```
Rimuovere l'OSD non riuscito dal cluster. Se necessario, è possibile specificare più OSD falliti.
```
	oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
Il valore FAILED_osd_id è il numero intero nel nome pod immediatamente dopo il prefisso rook-ceph-osd. Il valore FORCE_OSD_REMOVAL deve essere modificato in true nei cluster che hanno solo tre OSD o nei cluster con spazio insufficiente per ripristinare tutte e tre le repliche dei dati dopo la rimozione di OSD.
Verifica che l'OSD sia stato rimosso correttamente controllando lo stato del pod ocs-osd-removal-job.
```
	oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

Verificare che la rimozione OSD sia stata completata.

	oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

Output di esempio

	2023-03-10 06:50:04.501511 I | cephosd: completed removal of OSD 0

Solo per nodi di lavoro bare metal: dopo la rimozione dell’OSD, individuare eventuali volumi persistenti (PV) in stato “ Released ” associati alla classe di stoccaggio “ localblock ”. La rimozione dell'OSD fa entrare questi PV in uno stato di " Released ", pertanto questa operazione deve essere completata dopo la rimozione dell'OSD.
```
	oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
```
Output di esempio
```
	local-pv-d6bf175b  1490Gi  RWO  Delete  Released  openshift-storage/ocs-deviceset-0-data-0-6c5pw  localblock  2d22h  compute-1
```
Solo per i nodi di lavoro bare metal: se sono presenti PV in stato “ Released ”, eliminarli. Sostituisci " PERSISTENT_VOLUME " con il nome del PV indicato nel passaggio precedente.
```
	oc delete pv PERSISTENT_VOLUME
```
Comando di esempio
```
	oc delete pv local-pv-d6bf175b
```
Output di esempio
```
	persistentvolume "local-pv-d6bf175b" deleted
```

Aggiorna la risorsa OcsCluster con il nuovo nodo

Prima di procedere con i passaggi successivi, assicurati di aver completato i passaggi precedenti relativi a questo nodo di archiviazione prima di passare al nodo successivo del cluster.

Major update Minor update Worker replace

Se hai limitato la tua distribuzione ODF a un sottoinsieme di nodi di lavoro specificando i nomi dei nodi durante l'installazione, devi aggiornare il CRD ocscluster per includere il nuovo nome. Se hai applicato ODF a tutti i tuoi nodi di lavoro e non hai limitato la distribuzione a un sottoinsieme di nodi, salta questo passaggio e procedi con l'aggiornamento del componente aggiuntivo " OpenShift Data Foundation ".

Se non si è limitata la configurazione solo ad alcuni nodi worker, non è necessario aggiornare il CRD ocscluster.
```
	oc edit ocscluster
```
```
	apiVersion: ocs.ibm.io/v1
	kind: OcsCluster
	metadata:
	name: ocscluster-auto
	spec:
	. . .
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-metro-10iops-tier
	workerNodes:
	- NODE-NAME # Example 10.248.128.42
	- NODE-NAME
	- NODE-NAME
```
Attendi che i pod OpenShift Data Foundation vengano distribuiti al nuovo nodo di lavoro. Verifica che i nuovi volumi persistenti siano stati creati e che tutti i pod siano in uno stato Running.
```
	oc get pv
	oc get ocscluster
	oc get pods -n openshift-storage
```

Verifica che tutti gli altri pod OpenShift Data Foundation richiesti siano in stato In esecuzione.

	oc get pod -n openshift-storage | grep mon

Output di esempio:

	rook-ceph-mon-a-cd575c89b-b6k66         2/2     Running
	0          38m
	rook-ceph-mon-b-6776bc469b-tzzt8        2/2     Running
	0          38m
	rook-ceph-mon-d-5ff5d488b5-7v8xh        2/2     Running
	0          4m8s

Verificare che i nuovi pod OSD siano in esecuzione sul nodo sostitutivo.

	oc get pods -o wide -n openshift-storage| egrep -i NEW_NODE_NAME | egrep osd

Aggiorna il componente aggiuntivo OpenShift Data Foundation

Major update

Verificare la versione esistente.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Aggiornare il componente aggiuntivo.

	ibmcloud oc cluster addon update openshift-data-foundation --cluster CLUSTER --version VERSION

Verificare che il componente aggiuntivo sia aggiornato.
```
	ibmcloud oc cluster addon ls --cluster CLUSTER
```

Aggiorna la risorsa cluster

Major update

Ottieni il nome della tua risorsa ocscluster.

	oc get ocscluster

Output di esempio

	NAME             AGE
	ocscluster-vpc   19d

Esegui il seguente comando per modificare la tua risorsa ocscluster.
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

Impostare il parametro ocsUpgrade su true.

	...
	spec:
		billingType: hourly
	monSize: 20Gi
	monStorageClassName: ibmc-vpc-block-10iops-tier
	numOfOsd: 1
	ocsUpgrade: true
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-10iops-tier
	status:
		storageClusterStatus: Decreasing the capacity not allowed

Salva e chiudi il file.
Attendere il completamento dell'aggiornamento.

Verificare che le risorse storagecluster e cephcluster siano distribuite correttamente.

	oc get storagecluster -n openshift-storage

Output di esempio.

	NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   43h   Ready              2023-06-21T09:22:00Z   4.11.0

	oc get cephcluster -n openshift-storage

Output di esempio.

	NAME                             DATADIRHOSTPATH   MONCOUNT   AGE   PHASE   MESSAGE                        HEALTH      EXTERNAL
	ocs-storagecluster-cephcluster   /var/lib/rook     3          43h   Ready   Cluster created successfully   HEALTH_OK

	oc get csv -n openshift-storage

Output di esempio.

	NAME                              DISPLAY                       VERSION   REPLACES                          PHASE
	mcg-operator.v4.11.8              NooBaa Operator               4.11.8    mcg-operator.v4.11.7              Succeeded
	ocs-operator.v4.11.8              OpenShift Container Storage   4.11.8    ocs-operator.v4.11.7              Succeeded
	odf-csi-addons-operator.v4.11.8   CSI Addons                    4.11.8    odf-csi-addons-operator.v4.11.7   Succeeded
	odf-operator.v4.11.8              OpenShift Data Foundation     4.11.8    odf-operator.v4.11.7              Succeeded