Bug 1859493

Summary:	[4.5] lib-bucket-provisioner v2 upgrade attempt to install both v1 and v2
Product:	OpenShift Container Platform	Reporter:	Vu Dinh <vdinh>
Component:	OLM	Assignee:	Vu Dinh <vdinh>
OLM sub component:	OLM	QA Contact:	Bruno Andrade <bandrade>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	urgent
Priority:	urgent	CC:	bandrade, jiazha, palonsor, scuppett
Version:	4.4
Target Milestone:	---
Target Release:	4.5.z
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-07-30 18:56:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1857424
Bug Blocks:	1855706, 1859594

Description Vu Dinh 2020-07-22 09:39:38 UTC

This bug was initially created as a copy of Bug #1857424

I am copying this bug because: 



Description of problem:
When the OCS 4.4 is installed, the dependent operator lib-bucket-provisioner v1 will be installed. However, when lib-bucket-provisioner v1 is upgrading to v2, there are multiple duplicate InstallPlans that attempts to install both lib-bucket-provisioner v1 and v2.

Version-Release number of selected component (if applicable):
OCS 4.4
OCP 4.4.9+

How reproducible:
100%

Steps to Reproduce:
1. Install OCS 4.4 in OCP 4.4.9+ cluster in Manual approval mode
2. Manually approve the initial InstallPlan (inspect the steps will see only OCS 4.4 and lib-bucket v1 are included).

Actual results:
Multiple new InstallPlans are generated and waiting for approval.
Inspect those InstallPlans and will see they have steps (CSV) for lib-bucket v1 and v2.

Expected results:
The lib-bucket v2 will not be installed as it requires 2 CRDs that are owned by a previous version of itself (lib-bucket v1) and that is NOT allowed. There shouldn't be any InstallPlans generated for lib-bucket v2 installation. The expectation is when OCS 4.5 is released, it will own the CRDs in question and lib-bucket will be able to upgrade to v2.

Additional info:
See linked BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1855706

Comment 3 Bruno Andrade 2020-07-22 19:47:18 UTC

LGTM, marking as VERIFIED

Cluster info:
OCP: 4.5.0-0.nightly-2020-07-22-135825
OLM version: 0.15.1
git commit: 55bd02e5dd5b481ea1e55d2c83b425e88f4419d7
OCS 4.4.1 installed with Manual Approval

As expected, only lib-bucket-provisioner.v1.0.0 was installed and v2 was rejected, only the respective InstallPlans were created

oc get ip -n openshift-storage
NAME            CSV                             APPROVAL   APPROVED
install-rcfsc   lib-bucket-provisioner.v2.0.0   Manual     false
install-sj9qr   ocs-operator.v4.4.1             Manual     true
install-w4zt6   lib-bucket-provisioner.v2.0.0   Manual     false


oc get csv -n openshift-storage 
NAME                            DISPLAY                       VERSION   REPLACES   PHASE
lib-bucket-provisioner.v1.0.0   lib-bucket-provisioner        1.0.0                Succeeded
ocs-operator.v4.4.1             OpenShift Container Storage   4.4.1                Succeeded

oc get pods -n openshift-storage                                                                                       
NAME                                      READY   STATUS    RESTARTS   AGE
lib-bucket-provisioner-79bc798498-9ztx5   1/1     Running   0          5m38s
noobaa-operator-cb9c4dd7c-mvgwk           1/1     Running   0          5m35s
ocs-operator-5f67f4598b-zkqt6             1/1     Running   0          5m36s
rook-ceph-operator-9d7b6cc6f-kgl9c        1/1     Running   0          5m35s

Comment 5 errata-xmlrpc 2020-07-30 18:56:59 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, 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/RHBA-2020:3028