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.

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.