(OpenShift) ConfigMap created by the operator controller is not removed when unsubscribing

[fabiobrz]

When installing the Infinispan Operator on OpenShift a ConfigMap is created, e.g.: 632512e4.infinispan.org.
Looking at the resource definition, it turns out it's held by the operator controller Pod:

kind: ConfigMap
apiVersion: v1
metadata:
  name: 632512e4.infinispan.org
  namespace: intersmash-community4
  uid: 1254c3c1-0fcc-428a-a919-efd2cacb5f83
  resourceVersion: '59920706'
  creationTimestamp: '2023-04-18T10:07:01Z'
  annotations:
    control-plane.alpha.kubernetes.io/leader: >-
      {"holderIdentity":"infinispan-operator-controller-manager-5699cb5b97-fnzk5_447e345a-7670-4a89-804a-fc5419fafa45","leaseDurationSeconds":15,"acquireTime":"2023-04-18T10:11:16Z","renewTime":"2023-04-18T10:12:10Z","leaderTransitions":2}
  ...

but this resource is not deleted once the operator is uninstalled, despite its holder is.

• Infinispan operator version: 2.3.1
• channel: 2.3.x
• upgrade mode: automatic
• can be reproduced easily via the web console: check config maps, install operator, check config maps, uninstall operator, check config maps

This is not a critical issue, since a subsequent install would check for the COnfigMap to exist, and update the holder accordingly, but it would be good to know whether this behavior is expected, since it can be confusing or compromise assertions that rely on initial state (e.g.: 0 config maps -> subscribe -> unsubscribe -> 1 config map while expected 0).

[ryanemerson]

Hi @fabiobrz. This is the ConfigMap created by the controller-runtime as part of the controller leader election. As the ConfigMap is created at runtime, and needs to survive pod recreation, I'm not sure there's anything the Infinispan Operator can do to better handle this.

There's an open question on the controller-runtime repository about how to automate this, but there's not been much discussion so far: kubernetes-sigs/controller-runtime#2241.