Bug 1859594

Summary:	[4.4] 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:	assingh, bandrade, cpassare, jiazha, palonsor
Version:	4.4	Flags:	vdinh: needinfo- bandrade: needinfo-
Target Milestone:	---
Target Release:	4.4.z
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1859748 (view as bug list)		Environment:
Last Closed:	2020-08-04 14:16:04 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:	1859493
Bug Blocks:	1855706, 1859748

Description Vu Dinh 2020-07-22 14:24:51 UTC

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

I am copying this bug because: 



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-23 18:22:46 UTC

LGTM, marking as VERIFIED

Cluster info:
OCP: 4.4.0-0.nightly-2020-07-23-152929
OLM version: 0.14.2
git commit: a2211b81521f16ed9521d9edc0eb7b31453be133
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-ds9mt   lib-bucket-provisioner.v1.0.0   Manual     true

oc get csv -n openshift-storage                                       130 ↵
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-5b75b6b98-mjnfz   1/1     Running   0          12m
noobaa-operator-7bf59fd4b8-gkqng         1/1     Running   0          11m
ocs-operator-bb8db46ff-bhfss             1/1     Running   0          11m
rook-ceph-operator-65cd5d878b-vxqf4      1/1     Running   0          11m

Comment 9 errata-xmlrpc 2020-08-04 14:16:04 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 (OpenShift Container Platform 4.4.15 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/RHBA-2020:3128