According to https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment, kubernetes requires that each Deployment have a unique Pod selector:

> Do not overlap labels or selectors with other controllers (including other
> Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping,
> and if multiple controllers have overlapping selectors those controllers might
> conflict and behave unexpectedly.

However, the metal3 Deployment managed by the cluster-baremetal-operator does *not* have a unique Pod selector. It only selects for the label "k8s-app=controller", which is also present on the machine-api-controllers Deployment managed by the machine-api-operator in the same namespace (openshift-machine-api).

Unfortunately the Pod selector for a Deployment is immutable, so there is no way to update it without deleting and recreating the Deployment. The pod will get bounced from one node to another at least once during an upgrade, so this is not a problem per se. However, we cannot delete the Deployment during the upgrade from 4.6 to 4.7 because in 4.6 the Deployment is managed by the machine-api-operator and if it sees the Deployment missing it will assume that it is responsible for attempting to recreate it (https://github.com/openshift/machine-api-operator/blob/release-4.6/pkg/operator/baremetal_pod.go#L244-L246). So deleting it during an upgrade to 4.7 could cause a controller fight.

However, this could be fixed in 4.8 by deleting the Deployment if it has the wrong selector. Only one copy of the cluster-baremetal-operator can run at a time, so once we have upgraded it's safe to go ahead and do this.