Bug 1704940 - Subscription appears 'stuck' (doesn't gain a status) when startingCSV isn't present
Summary: Subscription appears 'stuck' (doesn't gain a status) when startingCSV isn't p...
Keywords:
Status: CLOSED DUPLICATE of bug 1706232
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.2.0
Assignee: Evan Cordell
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-30 20:57 UTC by Paul Morie
Modified: 2019-05-07 18:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-07 18:25:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Paul Morie 2019-04-30 20:57:51 UTC
Description of problem:

When I make a Subscription that references an unknown startingCSV, the subscription resource appears to be 'stuck' indefinitely and never gains a status. Meanwhile, the catalog operator logs (which a user would have no idea where to look for) contain the error message i'm looking for:

Version-Release number of selected component (if applicable):

4.1.0

How reproducible:


Make a subscription with a startingCSV field that will not resolve:


$ oc get subscriptions -n federation-test -o yaml
apiVersion: v1
items:
- apiVersion: operators.coreos.com/v1alpha1
  kind: Subscription
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"operators.coreos.com/v1alpha1","kind":"Subscription","metadata":{"annotations":{},"name":"namespaced-federation-sub","namespace":"federation-test"},"spec":{"channel":"alpha","name":"federation","source":"federation","sourceNamespace":"openshift-operator-lifecycle-manager","startingCSV":"federation.v0.0.8"}}                                                                                          
    creationTimestamp: 2019-04-30T20:42:08Z
    generation: 1
    name: namespaced-federation-sub
    namespace: federation-test
    resourceVersion: "131061"
    selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/federation-test/subscriptions/namespaced-federation-sub                                                                                              
    uid: 6bd08b84-6b88-11e9-8a4b-02f19f25e6f8
  spec:
    channel: alpha
    name: federation
    source: federation
    sourceNamespace: openshift-operator-lifecycle-manager
    startingCSV: federation.1.2.3
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""


... the subscription will never gain a status.

Steps to Reproduce:

1.
2.
3.

Actual results:

Subscription's status should reflect when there is a problem preventing the subscription from being serviced.

Expected results:

Subscription's status is never updated.

Additional info:

Comment 1 Evan Cordell 2019-05-01 18:48:41 UTC
We have an entire epic for 4.2 around reporting status better. For 4.1 we are targeting some basic status around the health of the Catalogs a Subscription is looking for, since that's the most common source of confusion.

To be clear (correct me if I'm wrong)

1. Making a subscription without the startingCSV field set works
2. Making a subscription with startingCSV set to a CSV that exists in the specified channel works
3. Making a subscription with a startingCSV set to a CSV that doesn't exist in the channel doesn't install anything and doesn't report the status of why it doesnt

Comment 3 Paul Morie 2019-05-03 13:24:53 UTC
1. Making a subscription without the startingCSV field set works
2. Making a subscription with startingCSV set to a CSV that exists in the specified channel works

These two work in the simple case, but there are cases where the catalog operator just appears not to service subscriptions at all, which I have a note to open another bug for as soon as I have the time.

3. Making a subscription with a startingCSV set to a CSV that doesn't exist in the channel doesn't install anything and doesn't report the status of why it doesnt

Correct.

Comment 4 Evan Cordell 2019-05-03 13:31:48 UTC
> These two work in the simple case, but there are cases where the catalog operator just appears not to service subscriptions at all, which I have a note to open another bug for as soon as I have the time.

Yes, there are always reasons for this but unfortunately they're not communicated back to the user right now. The epic for 4.2 is to ensure they are always communicated. Common reasons are that the catalog is not healthy or some other operator in the namespace is not healthy.

I'm going to go ahead and move this to 4.2, even though thing will get slightly better for 4.1 (by eod) via this pr: https://github.com/operator-framework/operator-lifecycle-manager/pull/825

But your voice is appreciated and heard, we know this is a big problem and we're working to fix it.

Comment 5 Evan Cordell 2019-05-07 18:25:34 UTC
Fix is here: https://github.com/operator-framework/operator-lifecycle-manager/pull/847, closing as a dup

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


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