Bug 1995606

*** Bug 1995602 has been marked as a duplicate of this bug. ***

*** Bug 1995603 has been marked as a duplicate of this bug. ***

*** Bug 1995604 has been marked as a duplicate of this bug. ***

*** Bug 1995605 has been marked as a duplicate of this bug. ***

Looking on the list,
only ServiceAccount/cluster-network-addons-operator is something we control directly (at least on U/S, need to see if we deploy it as well on D/S)
the rest are not needed according my understanding

Update -  more unlabeled resources -


ConfigMap/cluster-network-addons-operator-lock
Secret/cluster-network-addons-operator-token-7rmcw
Secret/cluster-network-addons-operator-dockercfg-mbzzp
Secret/cluster-network-addons-operator-token-9hzxs

only ServiceAccount/cluster-network-addons-operator is interesting, but OLM is responsible to label it

This bug is awaiting resolution of the following issue:

https://github.com/operator-framework/operator-lifecycle-manager/issues/2161

The U/S issue is still open and is unlikely to be fixed before 4.10 freezes. Moving to 4.11

This BZ is referring to many objects, allow me to order them as follows:
1. multus related objects - on d/s multus is not deployed by CNAO, so the labels should not be there. (I am referring to these objects: ValidatingWebhookConfiguration/multus.openshift.io, DaemonSet/multus, DaemonSet/multus-additional-cni-plugins, DaemonSet/multus-admission-controller, Pod/multus-5x8c9, Pod/multus-66jd4, Pod/multus-8q4dw, Pod/multus-9qbkx, Pod/multus-additional-cni-plugins-8fx7w, Pod/multus-additional-cni-plugins-h78ch, Pod/multus-additional-cni-plugins-hgcp8, Pod/multus-additional-cni-plugins-kjmp4, Pod/multus-additional-cni-plugins-mqr5x, Pod/multus-additional-cni-plugins-vcrss, Pod/multus-admission-controller-469z2, Pod/multus-admission-controller-q29cg, Pod/multus-admission-controller-r4q4r, Pod/multus-wrvlt, Pod/multus-xv55w, RoleBinding/multus-whereabouts, Secret/multus-admission-controller-secret, Secret/multus-dockercfg-5bm5m, Secret/multus-token-nlb7v, Secret/multus-token-vmm8h, Service/multus-admission-controller, ServiceAccount/multus, ValidatingWebhookConfiguration/multus.openshift.io')

2. knmstate related objects - from CNV v4.11 knmstate is no longer deployed by CNAO, so the labels should not be there. (I am referring to these objects: APIService/v1alpha1.nmstate.io, APIService/v1beta1.nmstate.io, ConfigMap/5d2e944a.nmstate.io, ConfigMap/5d2e944b.nmstate.io, PackageManifest/kubernetes-nmstate-operator, PackageManifest/quay-bridge-operator, PackageManifest/quay-bridge-operator, PackageManifest/kubernetes-nmstate-operator, APIService/v1alpha1.nmstate.io, APIService/v1beta1.nmstate.io, PackageManifest/kubernetes-nmstate-operator, PackageManifest/kubernetes-nmstate-operator, Secret/nmstate-handler-dockercfg-g447x, Secret/nmstate-handler-token-8scv7, Secret/nmstate-handler-token-k2nzs)

3. PackageManifest objects - I think they are not deployed by CNAO. Can you explain how you got those into this list? (I am referring to these objects: PackageManifest/quay-bridge-operator)

4. ServiceAccount with secrets - CNAO does not support reconciling service Accounts with secrets by design (see here https://github.com/kubevirt/cluster-network-addons-operator/blob/28af9319efc0434946adf76c9edb130b82ff9b95/pkg/apply/merge.go#L247). Not sure why though, and if we should insist adding the labels to these objects. (I am referring to these objects: ServiceAccount/cluster-network-addons-operator)

5. CNAO deployed secrets - not sure why these are not labeled, pending further investigation. (I am referring to these objects:Secret/bridge-marker-dockercfg-dvhk, Secret/bridge-marker-token-8gpts, Secret/bridge-marker-token-9mdmp, Secret/cluster-network-addons-operator-token-clfdc, Secret/linux-bridge-dockercfg-tqw4z, Secret/linux-bridge-token-78sd2, Secret/linux-bridge-token-t8kqq)

About 5 - We concluded that we don't label dockercfg / secret/*-token
as Those are created by k8s internally, not directly by us
We only deploy a secret, and k8s creates the token and give it to the entities according the binding

About 3 - PackageManifest are not deployed by CNAO indeed IIRC

See please https://bugzilla.redhat.com/show_bug.cgi?id=1995606#c7 in case it helps

But since then indeed 4.11 stopped deploying nmstate, so in case something is still labeled we will need to take care about.
If it is not, then all good, we better refetch the status of what labeled or not on fresh 4.11

Setting target to future since this BZ is of a low priority and blocked by upstream work https://github.com/operator-framework/operator-lifecycle-manager/issues/2161

*** Bug 2187532 has been marked as a duplicate of this bug. ***

Created attachment 1963308 [details]
identity thief

Hi @dbasunag
Would you able please to fetch a fresh list of components
that do not have the correct labels ?
Lot of time passed since the last fetch.

Then as was discussed, lets create a list of what we can ignore

Thanks

This was the freshly fetched ones:
=================
{
   
   "Role":[

      "kubevirt-hyperconverged-operator.v4.14.0-cluster-net-7dcf5fd9f6",
   ],
   
   "RoleBinding":[
      "kubevirt-hyperconverged-operator.v4.14.0-cluster-net-7dcf5fd9f6",
   ],
   "Secret":[

      "linux-bridge-token-b82xw",
      "linux-bridge-dockercfg-gx7l4",
      "cluster-network-addons-operator-token-sgnc5",
      "cluster-network-addons-operator-dockercfg-lqsg7",
      "bridge-marker-token-97fnw",
      "bridge-marker-dockercfg-g5444"
   ],
   "ServiceAccount":[
      "cluster-network-addons-operator",
   ],
}

Based on the chat conversation OLM ones, secrets ending with token / dockercfg would be ignored. I will update the automation and rerun before I can close this ticket.

After whitelisting, we are good with this bug. It can be closed.