argocd-operator-controller-manager-service pod selector not unique to argo

[fuerer]

Describe the bug
The service argocd-operator-controller-manager-service has the pod selector control-plane=controller-manager
In our OpenShift environment we have two additional operators (amq/otel) which have the same label on their operator pods.
With that the service points to the amq, argocd and otel pod.

To Reproduce
Steps to reproduce the behavior:

1. Install all 3 operators (amq broker/argocd/otel) in the OLM suggested namespace (openshift-operators) from the operator hub.

oc get pods -n openshift-operators -l control-plane=controller-manager
NAME                                                         READY   STATUS    RESTARTS   AGE
amq-broker-controller-manager-674dcf8866-bp5qd               1/1     Running   0          77m
argocd-operator-controller-manager-5887d66dc6-cghxz          1/1     Running   0          6d4h
opentelemetry-operator-controller-manager-5b64497db6-hg9qj   2/2     Running   0          64m

Expected behavior
Have a more selective pod selector, for example use something like:
app.kubernetes.io/name=argocd-operator, control-plane=controller-manager

Additional information
ArgoCD Operator 0.8.0

[keskad]

Hi, I have experienced exactly the same issue on OpenShift, using latest ArgoCD Operator v0.8.0. I think the issue started appearing after upgrade to this version.

How it looks in ArgoCD (when trying to synchronize kind: ArgoCD):

error when retrieving current configuration of: Resource: "argoproj.io/v1alpha1, Resource=argocds", GroupVersionKind: "argoproj.io/v1alpha1, Kind=ArgoCD" Name: "xxxx", Namespace: "xxxx" from server for: "xyz": conversion webhook for argoproj.io/v1beta1, Kind=ArgoCD failed: Post "[https://argocd-operator-controller-manager-service.xxx.svc:443/convert?timeout=30s](https://argocd-operator-controller-manager-service.xxx.svc/convert?timeout=30s)": dial tcp xxx.xxx.y.zzz:9443: connect: connection refused

When I do the oc get pods -n openshift-operators -l control-plane=controller-manager I get very similar result, there are pods of other operators visible.

kind: Service is having a label selector control-plane=controller-manager which is too generic.

[keskad]

I'm not sure if I found the problematic place:
https://github.com/argoproj-labs/argocd-operator/blob/v0.8.0/deploy/olm-catalog/argocd-operator/0.8.0/argocd-operator.v0.8.0.clusterserviceversion.yaml#L1726

It seems that in v0.9.0 the issue is probably resolved:

argocd-operator/deploy/olm-catalog/argocd-operator/0.9.0/argocd-operator.v0.9.0.clusterserviceversion.yaml

Line 1726 in c238af6

control-plane: argocd-operator

So I guess that next upgrade to v0.9.0 will fix it and make manual workarounds not neccessary anymore.

[fuerer]

As version 0.9.0 has been released which fixed this issue, we can close this case.

[keskad]

I see that v0.9.0 disappeared?

In meantime somebody made an upgrade via RedHat Operator Hub and it ended with:

install strategy failed: Deployment.apps "argocd-operator-controller-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"control-plane":"argocd-operator"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

[Elyytscha]

@svghadi can we reopen this? we have the same issue with 0.12.0

i think the issue is this

argocd-operator/deploy/olm-catalog/argocd-operator/0.12.0/argocd-operator.v0.12.0.clusterserviceversion.yaml

Lines 1876 to 1883 in c93f2fe

	- label:
	control-plane: controller-manager
	name: argocd-operator-controller-manager
	spec:
	replicas: 1
	selector:
	matchLabels:
	control-plane: controller-manager

im guessing right now olm creates the service for the operator from the clusterserviceversion which is the only place where i find those (missing) labels

the issue is simply

  selector:
    control-plane: controller-manager

is not guaranteed to be unique

[svghadi]

It was updated to argocd-operator for one release and again changed back to controller-manager. Need to check with other maintainers to understand the reason.

[Elyytscha]

i would maybe add more labels then just one, so this can't happen again.

our workaround for now is installing the argocd operator in ins own namespace via an own operatorgroup, where only this operator is installed

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: argocd-operator
  namespace: argocd-operator
spec:
  upgradeStrategy: Default