Bug 1705135

Summary: Operators installed to resolve a dependency can not be updated
Product: OpenShift Container Platform Reporter: David Zager <dzager>
Component: OLMAssignee: Evan Cordell <ecordell>
OLM sub component: OLM QA Contact: Jian Zhang <jiazha>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: high CC: scuppett
Version: 4.1.0   
Target Milestone: ---   
Target Release: 4.1.0   
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-06-04 10:48:19 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 David Zager 2019-05-01 15:25:25 UTC
Note: It was not possible to leave the Sub Component blank. This issue is specific to OLM but not necessarily related to OperatorHub.

Description of problem:

When a user subscribes to an operator that "required" the CRD that is provided by another operator, OLM generates a subscription to that operator. Unfortunately, when the InstallPlan completes the status of the generated Subscription is never updated. The consequence of this is that when updates become available for the dependent operator, they are not taken/installed.

Version-Release number of selected component (if applicable):
Client Version: version.Info{Major:"4", Minor:"0+", GitVersion:"v4.0.0-alpha.0+3bc8da4-1481-dirty", GitCommit:"3bc8da4", GitTreeState:"", BuildDate:"2019-03-05T02:25:42Z", GoVersion:"", Compiler:"", Platform:""}                      
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+6bdc5da", GitCommit:"6bdc5da", GitTreeState:"clean", BuildDate:"2019-05-01T03:59:59Z", GoVersion:"go1.11.8", Compiler:"gc", Platform:"linux/amd64"}

How reproducible: Always

Steps to Reproduce:
Everything needed to reproduce this issue can be found here -- https://github.com/djzager/olm-playground/tree/master/scenario2

I attempted with operator-registry and configmap based catalogs.

1. (optional) Create namespace scenario2
apiVersion: v1
kind: Namespace
metadata:
  name: scenario2

2. (optional) Create Operator Group in scenario2 namespace
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: scenario2
  namespace: scenario2

3. Create ConfigMap with operator catalog in openshift-operator-lifecycle-manager namespace
https://raw.githubusercontent.com/djzager/olm-playground/d3edd369ca7fd1e800c2dd096f57ebc67eeb6545/scenario2/configmap/scenario2-v1.configmap.yaml

Two operators with one channel (alpha) AND one version (v0.0.1)

  packages: |-
    - packageName: example-operator-a
      channels:
      - name: alpha
        currentCSV: example-operator-a.v0.0.1
    - packageName: example-operator-b
      channels:
      - name: alpha
        currentCSV: example-operator-b.v0.0.1

4. Create CatalogSource in openshift-operator-lifecycle-manager namespace
https://raw.githubusercontent.com/djzager/olm-playground/d3edd369ca7fd1e800c2dd096f57ebc67eeb6545/scenario2/configmap/scenario2.catalogsource.yaml

5. Create a Subscription to example-operator-a in scenario2 namespace
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  generateName: example-operator-a-
  namespace: scenario2
spec:
  source: scenario2
  sourceNamespace: openshift-operator-lifecycle-manager
  name: example-operator-a
  startingCSV: example-operator-a.v0.0.1
  channel: alpha

6. See that the InstallPlan is complete
$ kubectl get installplan -n scenario2 install-bfcbm -o go-template='{{ .status.phase }}'
Complete

7. Check the Subscriptions in scenario2 namespace
$ kubectl get subscriptions -n scenario2 -o go-template='{{ range .items }}{{ .metadata.name }}{{ " -- " }}{{ .status.state }}{{ "\n" }}{{ end }}'                                                              
example-operator-a-nn2r6 -- AtLatestKnown
example-operator-b-alpha-scenario2-openshift-operator-lifecycle-manager -- UpgradePending

8. Update the scenario2 ConfigMap in openshift-operator-lifecycle-manager namespace
https://raw.githubusercontent.com/djzager/olm-playground/d3edd369ca7fd1e800c2dd096f57ebc67eeb6545/scenario2/configmap/scenario2-v2.configmap.yaml

There is now a new CSV available for example-operator-b

  packages: |-
    - packageName: example-operator-a
      channels:
      - name: alpha
        currentCSV: example-operator-a.v0.0.1
    - packageName: example-operator-b
      channels:
      - name: alpha
        currentCSV: example-operator-b.v0.0.2

Actual results: No change.


Expected results: For example-operator-b deployment to be upgraded and using docker.io/djzager/example-operator-b:v2

Comment 1 Evan Cordell 2019-05-01 19:03:34 UTC
Verified that the dependent subscription seems to be stuck in upgradepending.

Comment 2 Evan Cordell 2019-05-01 20:41:28 UTC
This is fixed in this PR: https://github.com/operator-framework/operator-lifecycle-manager/pull/838

Comment 4 Jian Zhang 2019-05-06 09:08:53 UTC
LGTM, verify it. Details as below:

OLM version: io.openshift.build.commit.id=b2d1cd21368bc8cc10e4ca11a231f09077630c33
Cluster version is 4.1.0-0.nightly-2019-05-06-011159

The steps as the original description shows,

Update that ConfigMap, as below:
mac:~ jianzhang$ oc apply -f https://raw.githubusercontent.com/djzager/olm-playground/d3edd369ca7fd1e800c2dd096f57ebc67eeb6545/scenario2/configmap/scenario2-v2.configmap.yaml
Warning: oc apply should be used on resource created by either oc create --save-config or oc apply
configmap/scenario2 configured

Check the image of example-operator-b, it's the docker.io/djzager/example-operator-b:v2, LGTM.
mac:~ jianzhang$ oc get pods -n scenario2
NAME                                  READY   STATUS    RESTARTS   AGE
example-operator-a-59c7fffd7f-m2zzq   2/2     Running   0          5m41s
example-operator-b-d86647689-qdg6t    2/2     Running   0          57s
mac:~ jianzhang$ oc get pods -n scenario2 example-operator-b-d86647689-qdg6t -o yaml|grep image
    image: docker.io/djzager/example-operator-b:v2
    imagePullPolicy: IfNotPresent
    image: docker.io/djzager/example-operator-b:v2
    imagePullPolicy: IfNotPresent
  imagePullSecrets:
    image: docker.io/djzager/example-operator-b:v2
    imageID: docker.io/djzager/example-operator-b@sha256:7c6fe505434f2e70f368c41534f4c21297402756571815f52b4d5a4254d2e8fc
    image: docker.io/djzager/example-operator-b:v2
    imageID: docker.io/djzager/example-operator-b@sha256:7c6fe505434f2e70f368c41534f4c21297402756571815f52b4d5a4254d2e8fc

Comment 6 errata-xmlrpc 2019-06-04 10:48:19 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, 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-2019:0758