OLM 0.16.1 allows downgrading a dependency to older version by switching channels.

[cdjohnson]

Bug Report

When using the dependencies.yaml olm.package option to resolve dependencies between operators, switching a channel of a dependent operator up to a new version allows the dependency to be downgraded, resulting in an error: conflicting CRD owner in namespace

What did you do?

1. Installed OCP 4.6 nightly build 9/17/2020 which has OLM 0.16.1.
2. Created a catalog index image with the following operator bundle taxonomy using the command:

opm registry add --mode semver-skippatch

Package	Version	Channel	replaces	olm.skipRange	olm.package
testoperatora	1.0.0	v1.0	none	none	none
testoperatora	1.0.1	v1.0	1.0.1	<1.0.1	none
testoperatora	1.1.0	v1.1-eus	none	none	none
testoperatora	1.1.1	v1.1-eus	1.1.0	<1.1.1	none
testoperatora	1.2.0	v1.2	1.2.0	none	none
testoperatorb	4.0.0	v4.0	none	none	testoperatora: <1.3.0
testoperatorb	4.0.1	v4.0	4.0.0	<4.0.1	testoperatora: <1.3.0
testoperatorb	4.1.0	v4.1-eus	none	none	testoperatora:>=1.1.0 <1.2.0
testoperatorb	4.1.1	v4.1-eus	4.1.0	<4.1.1	testoperatora:>=1.1.0 <1.2.0

4. Created the catalog source

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: depcatalogs
  namespace: openshift-marketplace
spec:
  displayName: "depcatalogs-semver-dep-nowork Operators"
  image: docker.io/cdjohnson/depcatalogs@sha256:a1f9a07bd0602d86660d189fafe3f439bc3fd200c02f8c2be354ef866fe50c13
  publisher: IBM
  sourceType: grpc
EOF

5. Create namespace deptest
6. Create a own-namespace operator group

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operatorgroup
spec:
  targetNamespaces:
  - deptest
EOF

7. Create a subscription for operator b that has a dependency on A via the dependency.yaml

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: testoperatorb
spec:
  source: depcatalogs
  sourceNamespace: openshift-marketplace

  channel: v4.0
  installPlanApproval: Automatic
  name: testoperatorb
EOF

8. Wait until A and B are both installed
   • a: 1.2.0 in channel v1.1-eus
   • b: 4.0.1 in channel v4.0
9. Change the channel of b to v4.1-eus

What did you expect to see?
I expected v4.1-eus to be blocked from upgrading since it depends on an older version of operator A than what is installed.

What did you see instead? Under which circumstances?
Operator B successfully installed v4.1.1 in channel v4.1.1-eus
AND
Operator A was installed a second time by a second auto-generated subscription:

The install plan:

spec:
  approval: Automatic
  approved: true
  clusterServiceVersionNames:
  - testoperatorb.v4.1.1
  - testoperatora.v1.1.1

NAME                                                       PACKAGE         SOURCE        CHANNEL
testoperatora-v1.1-eus-depcatalogs-openshift-marketplace   testoperatora   depcatalogs   v1.1-eus
testoperatora-v1.2-depcatalogs-openshift-marketplace       testoperatora   depcatalogs   v1.2
testoperatorb                                              testoperatorb   depcatalogs   v4.1-eus

OLM generates this event:
conflicting CRD owner in namespace

Environment

• operator-lifecycle-manager version:
  0.16.1

• Kubernetes version information:
  Client Version: 4.6.0-0.nightly-2020-09-15-112431
  Server Version: 4.6.0-0.nightly-2020-09-17-073141
  Kubernetes Version: v1.19.0+b4ffb45

• Kubernetes cluster kind:
  OCP on aws

Possible Solution

Additional context
We're trying to model a scenario where we can use a Channel to constrain all dependency operators to other channels with the same characteristics. In this case an eus or lts channel.

[cdjohnson]

Cross link to OCP Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1881222

[njhale]

Hi Chris, had some questions on this and I reached out on the k8s slack: https://kubernetes.slack.com/archives/C0181L6JYQ2/p1600783707008500

[benluddy]

Thanks for filing a detailed issue and especially for sharing the index image you used (with digest!). I was able to repro this at f02ac99. I also found that this isn't reproducible as described starting from d074613.

The relevant change in d074613 is that all CSVs gained a representation in the resolver's constraint system, whereas before, only CSVs that were not associated with a Subscription were directly represented. As a result, the resolver now understands that the installed "A 1.2.0" operator provides the same GVK as other versions of A, and rejects any solution that requires more than one version of A to be installed.

The issue you reported can currently still happen if you modify A such that it doesn't provide a GVK, or such that different versions of A provide different GVKs. This is because package name can't be reliably inferred from a CSV, and as a result, the resolver won't include the already-installed CSV in the constraint prohibiting solutions that include more than 1 operator per package name. I have a patch almost ready to go that will resolve that issue as well.