Description of problem: Subscriptions without a sourceNamespace set hang forever without any failure status. Version-Release number of selected component (if applicable): OLM How reproducible: 100% Steps to Reproduce: 1. Create a subscription without a sourceNamespace 2. 3. Actual results: Subscription without a sourceNamespace set hang forever without any failure status. Expected results: Subscription should get resolved properly. Additional info:
LGTM, marking as VERIFIED. Cluster version: 4.2.0-0.nightly-2019-09-06-073347 OLM version: 0.11.0 git commit: 09537286f6e8ca771f99287b3d09e6e595f5b8e2 Steps used to validate: 1) Create a namespace called test-operators oc create ns test-operators oc project test-operators 2) Create the ConfigMap and the Catalog Source. oc create -f https://raw.githubusercontent.com/bandrade/v3-testfiles/v4.1/olm/configmap/configmap_etcd.yaml oc create -f https://raw.githubusercontent.com/bandrade/v3-testfiles/v4.1/olm/catalogsource/catalogsource.yaml 3) Create the Operator Group schema oc create -f - <<EOF apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: test-operators-og namespace: test-operators spec: targetNamespaces: - test-operators EOF 4) Create the subscription, as below: oc create -f - <<EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: etcd-etcdoperator.v0.9.2 spec: channel: alpha installPlanApproval: Automatic name: etcd-update source: installed-community-global-operators startingCSV: etcdoperator.v0.9.2 EOF 4) Check the csv status. oc get csv NAME DISPLAY VERSION REPLACES PHASE etcdoperator.v0.9.2 etcd 0.9.2 Succeeded
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:2922