Description of problem: In dependency resolution, Subscription uniqueness is currently based on the subscribed package name. If two Subscriptions in a namespace subscribe to the same package, they are treated as a single Subscription internally, resulting in some surprising behaviors. Version-Release number of selected component (if applicable): 4.6 How reproducible: Always Steps to Reproduce: 1. Subscribe to an operator: $ cat << EOF | kubectl create -f- apiVersion: v1 kind: Namespace metadata: name: test-namespace --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: test-operatorgroup namespace: test-namespace spec: targetNamespaces: - test-namespace --- apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: test-catalog namespace: test-namespace spec: displayName: Community Operators image: quay.io/operatorhubio/catalog:latest sourceType: grpc --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: test-subscription-stable namespace: test-namespace spec: name: redis-operator source: test-catalog sourceNamespace: test-namespace channel: stable startingCSV: redis-operator.v0.4.0 EOF namespace/test-namespace created operatorgroup.operators.coreos.com/test-operatorgroup created catalogsource.operators.coreos.com/test-catalog created subscription.operators.coreos.com/test-subscription-stable created 2. Wait for the operator to be installed: $ kubectl -n test-namespace get csv -w NAME DISPLAY VERSION REPLACES PHASE redis-operator.v0.4.0 Redis Operator 0.4.0 redis-operator.v0.3.0 redis-operator.v0.4.0 Redis Operator 0.4.0 redis-operator.v0.3.0 Pending redis-operator.v0.4.0 Redis Operator 0.4.0 redis-operator.v0.3.0 InstallReady redis-operator.v0.4.0 Redis Operator 0.4.0 redis-operator.v0.3.0 Installing redis-operator.v0.4.0 Redis Operator 0.4.0 redis-operator.v0.3.0 Installing redis-operator.v0.4.0 Redis Operator 0.4.0 redis-operator.v0.3.0 Succeeded 3. Create a conflicting subscription to the same package: $ cat << EOF | kubectl create -f- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: test-subscription-alpha namespace: test-namespace spec: name: redis-operator source: test-catalog sourceNamespace: test-namespace channel: alpha startingCSV: redis-operator.v0.0.1 EOF subscription.operators.coreos.com/test-subscription-alpha created Expected results: Resolution should warn about a conflict between the installed v0.4.0 CSV and the requested v0.0.1 operator from the same package, something like this: $ kubectl logs -n openshift-operator-lifecycle-manager deploy/catalog-operator | grep ResolutionFailed | tail -1 I0223 18:08:32.095488 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"", Name:"test-namespace", UID:"59f61254-01b3-4309-9ecc-3ff29f1d979f", APIVersion:"v1", ResourceVersion:"851", FieldPath:""}): type: 'Warning' reason: 'ResolutionFailed' constraints not satisfiable: subscription test-subscription-stable requires @existing/test-namespace//redis-operator.v0.4.0, subscription test-subscription-stable exists, subscription test-subscription-alpha requires test-catalog/test-namespace/alpha/redis-operator.v0.0.1, subscription test-subscription-alpha exists, @existing/test-namespace//redis-operator.v0.4.0 and test-catalog/test-namespace/alpha/redis-operator.v0.0.1 originate from package redis-operator Actual results: The conflict between the two subscriptions is not indicated in the catalog-operator log. There may be some warnings that occur before the CatalogSource becomes available. Those would not indicate that there are two subscriptions to the redis-operator package, and may look something like this: $ kubectl logs -n openshift-operator-lifecycle-manager deploy/catalog-operator | grep ResolutionFailed | tail -1 I0223 18:03:02.611310 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"", Name:"test-namespace", UID:"27194bfe-65ee-4d24-86b0-6384fb6fb1a6", APIVersion:"v1", ResourceVersion:"855", FieldPath:""}): type: 'Warning' reason: 'ResolutionFailed' constraints not satisfiable: no operators found matching the subscription criteria for redis-operator, a subscription to package redis-operator exists in the namespace
A patch for this already merged into release-4.8 (https://github.com/operator-framework/operator-lifecycle-manager/pull/2005), but before this BZ was created.
Cluster version is 4.8.0-0.nightly-2021-02-23-200827 [jzhang@dhcp-140-36 ~]$ oc -n openshift-operator-lifecycle-manager exec catalog-operator-6f645747d-nb2sb -- olm --version OLM version: 0.17.0 git commit: fd0ce87079d83588ad4c6e74f3175edf340e28a8 1, Subscribe an operator, for example, etcd-operator [jzhang@dhcp-140-36 ~]$ oc create -f og.yaml operatorgroup.operators.coreos.com/test-og created [jzhang@dhcp-140-36 ~]$ cat sub-etcd.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: sub-etcd1 namespace: default spec: sourceNamespace: openshift-marketplace channel: singlenamespace-alpha installPlanApproval: Automatic name: etcd source: community-operators startingCSV: etcdoperator.v0.9.4 [jzhang@dhcp-140-36 ~]$ oc create -f sub-etcd.yaml subscription.operators.coreos.com/sub-etcd1 created [jzhang@dhcp-140-36 ~]$ oc get sub -n default NAME PACKAGE SOURCE CHANNEL sub-etcd1 etcd community-operators singlenamespace-alpha [jzhang@dhcp-140-36 ~]$ oc get csv -n default NAME DISPLAY VERSION REPLACES PHASE etcdoperator.v0.9.4 etcd 0.9.4 etcdoperator.v0.9.2 Installing [jzhang@dhcp-140-36 ~]$ oc get csv -n default NAME DISPLAY VERSION REPLACES PHASE etcdoperator.v0.9.4 etcd 0.9.4 etcdoperator.v0.9.2 Succeeded 2, After it was deployed, rename the subscription, and subscribe to it. [jzhang@dhcp-140-36 ~]$ cat sub-etcd.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: sub-etcd2 namespace: default spec: sourceNamespace: openshift-marketplace channel: singlenamespace-alpha installPlanApproval: Automatic name: etcd source: community-operators startingCSV: etcdoperator.v0.9.4 [jzhang@dhcp-140-36 ~]$ oc create -f sub-etcd.yaml subscription.operators.coreos.com/sub-etcd2 created [jzhang@dhcp-140-36 ~]$ oc get sub -n default NAME PACKAGE SOURCE CHANNEL sub-etcd1 etcd community-operators singlenamespace-alpha sub-etcd2 etcd community-operators singlenamespace-alpha [jzhang@dhcp-140-36 ~]$ oc get ip -n default NAME CSV APPROVAL APPROVED install-9rpvb etcdoperator.v0.9.4 Automatic true 3, Check OLM logs. [jzhang@dhcp-140-36 ~]$ oc logs -n openshift-operator-lifecycle-manager deploy/catalog-operator | grep ResolutionFailed | tail -1 I0224 03:27:08.740276 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"", Name:"default", UID:"54434924-b887-4a01-8e8f-f3c7c14fd5aa", APIVersion:"v1", ResourceVersion:"28715", FieldPath:""}): type: 'Warning' reason: 'ResolutionFailed' constraints not satisfiable: subscription sub-etcd2 requires community-operators/openshift-marketplace/singlenamespace-alpha/etcdoperator.v0.9.4, subscription sub-etcd2 exists, subscription sub-etcd1 requires @existing/default//etcdoperator.v0.9.4, subscription sub-etcd1 exists, @existing/default//etcdoperator.v0.9.4 and community-operators/openshift-marketplace/singlenamespace-alpha/etcdoperator.v0.9.4 originate from package etcd The logs pop-up a conflict waring, LGTM, verify it.
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 (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), 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/RHSA-2021:2438