Bug 1768504 - Operators affect each other's approval strategy
Summary: Operators affect each other's approval strategy
Keywords:
Status: CLOSED DUPLICATE of bug 1767846
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Evan Cordell
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-04 15:47 UTC by Martin Gencur
Modified: 2019-11-04 18:24 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-04 18:24:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.