Bug 1957725

Summary:	bundle-upgrade from the traditional installed operator doesn't use the default registry image may cause the registry pod failed
Product:	OpenShift Container Platform	Reporter:	Fan Jia <jfan>
Component:	Operator SDK	Assignee:	Rashmi Gottipati <rgottipa>
Status:	CLOSED WONTFIX	QA Contact:	Fan Jia <jfan>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.8	CC:	aos-bugs, jesusr
Target Milestone:	---	Flags:	jesusr: needinfo-
Target Release:	4.8-premerge
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:	2021-06-07 13:46:45 UTC	Type:	Bug
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:
Bug Blocks:	1956382

Comment 1 Rashmi Gottipati 2021-05-11 18:36:27 UTC

I have tried to reproduce this bug on OpenShift release version 4.8.0-fc.3. I installed an etcd operator of version 0.9.2 traditionally using OLM, and have tried to run `bundle-upgrade` command and the operator upgraded the bundle to the next version that I provided i.e 0.9.4. 

#oc get csv
NAME                  DISPLAY   VERSION   REPLACES              PHASE
etcdoperator.v0.9.4   etcd      0.9.4     etcdoperator.v0.9.2   Succeeded

However, I noticed that the registry pod was failing and is in CrashLoopBackOff state as below, as mentioned in the bug description. 

quay-io-olmqe-etcd-bundle-0-9-4-share     0/1     CrashLoopBackOff


I'm investigating the root cause for this currently and I will post an update soon.

Comment 2 Rashmi Gottipati 2021-06-07 13:42:22 UTC

One of the assumptions of `run bundle-upgrade` command is that the newer operator bundle (that a user intends to upgrade to) should not exist in the index image, if the previous version of the operator bundle was installed traditionally using OLM. This will cause the registry pod to fail as the bundle is already added to the index that provides package and CSV. If an operator bundle was installed using OLM, the next versions of upgrades should not be using the default index image but should be using the index image obtained from the annotations in the catalog source. `bundle-upgrade` from the traditional installed operator not using default registry image is expected. 

To clarify the assumptions of `run bundle-upgrade`, I opened a documentation update PR:  https://github.com/operator-framework/operator-sdk/pull/4968


However, these kind of errors in pod logs should be reported well and visible to the user through the command output as opposed to having to look through logs of various pods/deployments. For this, I will be creating a feature request in SDK issues. I will post the link for it here once I create it. 

Closing this issue as it's not a bug and is the expected outcome.