feat(recommended labels)

[rene-dekker]

feat(recommended labels): Set recommended labels as per
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

For example:

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2025-12-29T18:44:40Z"
  labels:
    app.kubernetes.io/component: Installation.operator.tigera.io
    app.kubernetes.io/instance: default
    app.kubernetes.io/managed-by: tigera-operator
    app.kubernetes.io/name: calico-system
    app.kubernetes.io/part-of: TigeraSecureEnterprise
    k8s-app: calico-system
    kubernetes.io/metadata.name: calico-system
    name: calico-system
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: latest
  name: calico-system
  ownerReferences:
  - apiVersion: operator.tigera.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: Installation
    name: default
    uid: 9df390bc-84bd-4990-a839-5cfbb1a68287
  resourceVersion: "78244"
  uid: 4fa83b63-932d-4b0c-8eb7-8280bc58023e
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Set recommended labels as per 
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

The version label was deliberately skipped as discussed in our operator grooming meetings.

[rene-dekker]

lol on Dec 29th...

[caseydavenport]

Shoud this just be Calico always? I think that makes more sense.

[tmjd]

Should we do CalicoEnterprise with the enterprise variant?

[caseydavenport]

We could, although I think from a users perspective "Calico" is probably the most useful. Not sure it adds value for a user to have this change between product variants?

[rene-dekker]

Either of your suggestions are nicer than TigeraSecureEnterprise. My take would be that:

• Either we hardcode "calico"
• Or - since we don't really like TigeraSecureEnterprise - we deprecate Variant enum value TigeraSecureEnterprise in favour of CalicoEnterprise as well.

[caseydavenport]

Let's hard code Calico for now IMO - the use-case of allow-listing a set of components means a singular value here is probably better.

We should look at getting rid of TSE separately IMO.

[caseydavenport]

What about app.kubernetes.io/version?

[tmjd]

I think if we're including version we need to differentiate in one of the other labels enterprise vs open source.

[caseydavenport]

Yeah, unless it was app.kubernetes.io/version: v3.30-enterprise or something.

[rene-dekker]

We spoke about this during the dev grooming meetings (IIRC twice even) and we concluded that today we don't have a very good way of ensuring they are all correct, that doing it correct would take a lot of work and so we decided to defer this label for the time being.

[caseydavenport]

Hm, I don't recall those (or maybe I just missed them). How would they be incorrect? Don't we have the version compiled into operator?

[rene-dekker]

I believe we chatted only briefly on the approach before debating if there would be value in having it. In the end we basically concluded that it was low ROI and worth skipping until a user asks for it with a valid use case.

[caseydavenport]

What are the use-cases for all of the other labels?

Feel free to go ahead without it, I'm just a bit confused as to the motivations for some of these labels but not others.

[rene-dekker]

We have a user that wants to block resources being deployed using a webhook if they do not belong to allow-listed components. Previously they would filter resources on the expected name prefix such as "tigera-" or "calico-". Labels would be a better way of implementing this.

[caseydavenport]

Surely that's only an argument for adding the app.kubernetes.io/component label then, and not all of the others? Or maybe "app.kubernetes.io/part-of"?