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