Installation of an `Operator` fails when `BundleDeployment` with the same bundle already exists

[m1kola]

Steps to reproduce:

1. Create a catalog on cluster: kubectl apply -f config/samples/catalogd_operatorcatalog.yaml
2. Create a BundleDeployment:

apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
 name: operator-sample-manual
spec:
 provisionerClassName: core-rukpak-io-plain
 template:
 metadata: {}
 spec:
 provisionerClassName: core-rukpak-io-registry
 source:
 image:
 ref: quay.io/operatorhubio/argocd-operator@sha256:1a9b3c8072f2d7f4d6528fa32905634d97b7b4c239ef9887e3fb821ff033fef6
 type: image

1. Create an Operator which resolves to the same bundle:

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
 labels:
 app.kubernetes.io/name: operator
 app.kubernetes.io/instance: operator-sample
 app.kubernetes.io/part-of: operator-controller
 app.kubernetes.io/managed-by: kustomize
 app.kubernetes.io/created-by: operator-controller
 name: operator-sample
spec:
 packageName: argocd-operator
 version: 0.6.0

Actual result:

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
 # ...
 name: operator-sample
spec:
# ...
status:
 conditions:
 - lastTransitionTime: "2023-10-06T12:26:51Z"
 message: resolved to "quay.io/operatorhubio/argocd-operator@sha256:1a9b3c8072f2d7f4d6528fa32905634d97b7b4c239ef9887e3fb821ff033fef6"
 observedGeneration: 1
 reason: Success
 status: "True"
 type: Resolved
 - lastTransitionTime: "2023-10-06T12:26:57Z"
 message: 'bundledeployment not ready: rendered manifests contain a resource that
 already exists. Unable to continue with install: Namespace "argocd-operator-system"
 in namespace "" exists and cannot be imported into the current release: invalid
 ownership metadata; annotation validation error: key "meta.helm.sh/release-name"
 must equal "operator-sample": current value is "operator-sample-manual"'
 observedGeneration: 1
 reason: InstallationFailed
 status: "False"
 type: Installed
 resolvedBundleResource: quay.io/operatorhubio/argocd-operator@sha256:1a9b3c8072f2d7f4d6528fa32905634d97b7b4c239ef9887e3fb821ff033fef6

Expected result:

Not sure what would be the expected behaviour in here. Perhaps a better error message indicating conflict. Or, if we can successfully resolve, updating ownerReferences on already existing BundleDeployment instead of creating a new one?

[joelanford]

This probably requires more thought, but my instinct is that we should not automatically adopt existing BundleDeployments.

[fgiloux]

How is it expected to work with dependency resolution? Would you check for on-cluster availability as part of the resolution and not add the resolved bundle if it has already been installed?
What are the potential conflicts when multiple operators share the same dependency?

• RBAC
• upgrades: channel, constraint policy
• anything else?

[m1kola]

Cross posting @joelanford's comment from this thread. I believe it is related to this ticket.

I don't think we need to worry too much about this [conflicts between unmanaged content and managed via Operator]. An unmanaged BundleDeployment isn't all that different than an unmanaged CRD or unmanaged cluster role or whatever else that ultimately conflicts with something that comes from an Operator.

What I would expect to happen is:

• Resolution is not affected by the conflicting BundleDeployment
• If the conflicting BundleDeployment has the same name as the one that we want to create/manage, there should be an error along the lines of "couldn't create BD foo, already exists" or "couldn't update BD foo, not owned by Operator"
• The the conflict BundleDeployment does not have the same name, operator-controller should create/update it, and then rukpak should report the conflict along the lines of "could not create CustomResourceDefinition foos.acme.org, already exists or not owned by BD", which would then bubble up on the Installed condition back to the Operator.

[m1kola]

We no longer have BundleDeployment. No BundleDeployment - no problem. Closing this.