OLM dependency doesn't always deploy operator from the default channel

[horis233]

Bug Report

What did you do?
A clear and concise description of the steps you took (or insert a code snippet).

I have Operator A and Operator B,

Operator A depends on Operator B.

In the bundle metadata of Operator A, there is a dependencies.yaml file to specify the package version and GVK of Operator B.

In Operator B, there are two channels that can fulfill the requirements in the dependencies.yaml of Operator A, beta channel and v3 channel. The v3 channel is the default channel of Operator B.

What did you expect to see?
A clear and concise description of what you expected to happen (or insert a code snippet).

What I expect to see is v3 channel of the Operator B can be always chosen when deploying the Operator A.

What did you see instead? Under which circumstances?
A clear and concise description of what you expected to happen (or insert a code snippet).

What I observe is after deploying the Operator A, sometimes beta channel of Operator B is picked and sometimes v3 channel of Operator B is picked up, which is against the dependency resolution

Environment

• operator-lifecycle-manager version:
  0.16.1 and 0.17.0

• Kubernetes version information:
  1.19 and 1.20

• Kubernetes cluster kind:
  OCP

Possible Solution
NO

Additional context
Add any other context about the problem here.

[benluddy]

Are you able to share the index image that you've used to reproduce this? That doc looks correct to me -- it should consistently select the version in the default channel unless there is a conflict that blocks installation of the default channel entry.

[horis233]

@benluddy

Yes sure, Thanks for your quick response!

These are steps to reproduce this issue:

1. Create two catalogsources

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: ibm-operator-catalog
  namespace: openshift-marketplace
spec:
  displayName: IBM Operator Catalog
  image: docker.io/ibmcom/ibm-operator-catalog
  publisher: IBM
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 45m

and

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: opencloud-operators
  namespace: openshift-marketplace
spec:
  displayName: IBMCS Operators
  image: 'docker.io/ibmcom/ibm-common-service-catalog:3.7.1'
  publisher: IBM
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 45m

2. Create IBM Automation Foundation Core operator in a namespace , which is from IBM Operator Catalog and depends on IBM Cloud Pak foundational services from opencloud-operators.
   This is what it looks like

3. However, when we check the IBM Cloud Pak foundational services, we can find it is deployed in the beta channel instead of the default channel v3.

[benluddy]

Great, thanks. Using the CatalogSources and images you provided, I was able to reproduce this with https://github.com/benluddy/depster. It's fixed for me with #2068.

[horis233]

@benluddy

Thanks for your quick fix!

Could we cherry-pick the fix to release-4.6 and release-4.7?

We will add it as a known issue in our product, but we expect it will be fixed in the Z version OCP.

[benluddy]

I opened https://bugzilla.redhat.com/show_bug.cgi?id=1945261 to track this downstream and marked it to be backported to 4.6.