Bug 1859748

Summary:	[4.3] lib-bucket-provisioner v2 upgrade attempt to install both v1 and v2
Product:	OpenShift Container Platform	Reporter:	Evan Cordell <ecordell>
Component:	OLM	Assignee:	Evan Cordell <ecordell>
OLM sub component:	OLM	QA Contact:	Bruno Andrade <bandrade>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	urgent
Priority:	urgent	CC:	assingh, bandrade, jiazha, vdinh
Version:	4.4
Target Milestone:	---
Target Release:	4.3.z
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1859594	Environment:
Last Closed:	2020-08-05 10:54:08 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:	1859594
Bug Blocks:	1855706

Description Evan Cordell 2020-07-22 20:19:50 UTC

+++ This bug was initially created as a clone of Bug #1859594 +++

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 4 Bruno Andrade 2020-07-24 14:19:09 UTC

LGTM, marking as VERIFIED

Cluster info:
OCP: 4.3.0-0.nightly-2020-07-24-015357 
OLM version: 0.13.0
git commit: 3af2a4b1875bc4af5dea61044792e6626a4d6017
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 test-operators                        
NAME            CSV                   APPROVAL   APPROVED
install-gpczs   ocs-operator.v4.4.1   Manual     true

oc get csv                                           
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 test-operators
NAME                                    READY   STATUS    RESTARTS   AGE
lib-bucket-provisioner-8899bc7b-ldfgh   1/1     Running   0          16m
noobaa-operator-7ddf595464-w2fvv        1/1     Running   0          16m
ocs-operator-69cc9596c5-md4td           1/1     Running   0          16m
rook-ceph-operator-6cb4c75fd8-2nmzp     1/1     Running   0          16m

Comment 6 errata-xmlrpc 2020-08-05 10:54:08 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.3.31 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:3180