Bug 1768504

Summary: Operators affect each other's approval strategy
Product: OpenShift Container Platform Reporter: Martin Gencur <mgencur>
Component: OLMAssignee: Evan Cordell <ecordell>
OLM sub component: OLM QA Contact: Jian Zhang <jiazha>
Status: CLOSED DUPLICATE Docs Contact:
Severity: high    
Priority: unspecified    
Version: 4.1.z   
Target Milestone: ---   
Target Release: ---   
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: 2019-11-04 18:24:46 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:

Description Martin Gencur 2019-11-04 15:47:24 UTC 
Description of problem:

If I install two different operators the second one will affect the first one's approval strategy, resulting in the first one being upgraded even though the two operators are completely unrelated. 

This behavior can be seen on OCP 4.1.18. It is similar to https://jira.coreos.com/browse/OLM-1299 but it has slightly different steps to reproduce it. Also similar to https://jira.coreos.com/browse/OLM-1263

Steps to reproduce:
 * install ServiceMesh operator 1.0.0 (the latest version is 1.0.1 but I am installing the previous version on purpose (I want to test its rolling upgrade)
 * at this point the ServiceMesh operator stays at version 1.0.0 and there are two install plans available for ServiceMesh: 
 * 

oc get installplan --all-namespaces
NAMESPACE                              NAME            CSV                                          SOURCE   APPROVAL    APPROVED
openshift-operator-lifecycle-manager   install-qjm7h   packageserver.v0.9.0                                  Automatic   true
openshift-operators                    install-k8h2c   servicemeshoperator.v1.0.1                            Manual      false
openshift-operators                    install-mbx2d   servicemeshoperator.v1.0.0                            Manual      true


 * install a different operator, for example OpenShift Serverless 1.0.0
 * at this point we can see one more InstallPlan for openshift-serverless and one more for ServiceMesh (the new one is install-7vqc6 and it includes references to the serverless-operator.v1.0.0 CSV) ! So one InstallPlan includes references to both ServiceMesh and Serverless CSVs:
 * 

[root@ocp-dynamic-2106 ~]# oc get installplan --all-namespaces
NAMESPACE                              NAME            CSV                                          SOURCE   APPROVAL    APPROVED
openshift-operator-lifecycle-manager   install-qjm7h   packageserver.v0.9.0                                  Automatic   true
openshift-operators                    install-7vqc6   servicemeshoperator.v1.0.1                            Manual      false
openshift-operators                    install-8f86g   serverless-operator.v1.0.0                            Manual      true
openshift-operators                    install-k8h2c   servicemeshoperator.v1.0.1                            Manual      false
openshift-operators                    install-mbx2d   servicemeshoperator.v1.0.0                            Manual      true

 * now the ServiceMesh operator automatically upgrades to 1.0.1 even though we did not ask for it

As a side effect of this, I don't see a separate install plan for Serverless 1.0.1 CSV (I already installed 1.0.0 for which I can see the installplan, but not for the latest available version 1.0.1). The Serverless CSV seems to be aggregated in the new installplan for ServiceMesh. The UI shows this situation correctly - and I can approve Serverless 1.0.1 there but I don't see a separate installplan for it which I could approve.

More info in the linked CoreOS JIRA issue
Comment 1 Evan Cordell 2019-11-04 18:24:46 UTC 

*** This bug has been marked as a duplicate of bug 1767846 ***