OLM happily creates duplicate PackageManifest resources in the same namespace

[jiridanek]

Bug Report

Originally asked as https://stackoverflow.com/questions/77866634/multiple-resources-of-the-same-type-with-the-same-name-in-a-single-kubernetes-na?noredirect=1#comment137280139_77866634

What did you do?

I've added additional CatalogSource, which happens to define some of the same cluster operators as the default catalog in my OpenShift.

What did you see? Under which circumstances?

There are duplicate PackageManifests on my cluster now

$ kubectl get packagemanifest -n olm | grep rho | sort
rhoas-operator                                     Community Operators              20d
rhods-operator                                     Red Hat OpenShift Data Science   16h
rhods-operator                                     Red Hat Operators                20d
rhods-prometheus-operator                          Red Hat OpenShift Data Science   16h
rhods-prometheus-operator                          Red Hat Operators                20d

Querying by kind, name, and namespace seems to give one of the two at random.

$ kubectl get packagemanifest/rhods-operator -n olm
NAME             CATALOG                          AGE
rhods-operator   Red Hat OpenShift Data Science   16h
$ kubectl get packagemanifest/rhods-operator -n olm
NAME             CATALOG             AGE
rhods-operator   Red Hat Operators   20d

What did you expect to see?

Each object in your cluster has a Name that is unique for that type of resource. Every Kubernetes object also has a UID that is unique across your whole cluster.

For example, you can only have one Pod named myapp-1234 within the same namespace, but you can have one Pod and one Deployment that are each named myapp-1234.

~~ https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

I am not sure what I'd want to see instead. What I wanted to accomplish (install newer version of rhods-operator from the added catalogue image) works fine. Inspecting the resources on the cluster later gets difficult, however. Especially the last point about getting one of the two versions at random in kubectl and not being able to easily select which one I want.

Environment

• operator-lifecycle-manager version:

  • name: OPERATOR_NAME
    value: olm-operator
  • name: RELEASE_VERSION
    value: 4.14.7
    image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d07c0051cd46700b8bc88914ee79be5876a78f261242eb6b9978b6fd8d6571fd

• Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.0", GitCommit:"45460a55f50834ff18308b13b4569a6c89b9d37a", GitTreeState:"clean", BuildDate:"2022-07-20T07:04:21Z", GoVersion:"go1.17.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.8+4fab27b", GitCommit:"c7a50586071278562f15130ff5ba194015aedee2", GitTreeState:"clean", BuildDate:"2023-12-01T15:11:39Z", GoVersion:"go1.20.10 X:strictfipsruntime", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.23) and server (1.27) exceeds the supported minor version skew of +/-1

• Kubernetes cluster kind:

Openshift Local 4.14

Possible Solution

Additional context
Add any other context about the problem here.

[damobrisbane]

2nd this as an issue. In my case wrt to skupper operator. We have v1.5.3 running as the CSV, however "oc get packagemanifest skupper-operator", will randomly return with another version (v1.2.1, different catalogsource) instead of the v1.5.3 version.

It would be good to know what impact if any, this has on an already installed operator. Case above, CSV is v1.5.3, are there any scenarios that can be triggered due to an unintentional packagemanifest api response.

[jiridanek]

It would be good to know what impact if any, this has on an already installed operator. Case above, CSV is v1.5.3, are there any scenarios that can be triggered due to an unintentional packagemanifest api response.

I believe there is no impact. Installing means creating a Subscription resource and that resource mentions name and source catalog for the operator. Subsequently it (correctly) seems to only take into account the data from that one catalog.

[lixin9311]

A workaround:

kubectl get packagemanifest \
  --selector=catalog=community-operators \
  --field-selector metadata.name=rhoas-operator