Skip to content

Conversation

@rene-dekker
Copy link
Member

@rene-dekker rene-dekker commented Dec 30, 2025

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.

@@ -1,4 +1,4 @@
// Copyright (c) 2022-2024 Tigera, Inc. All rights reserved.
// Copyright (c) 2022-2025 Tigera, Inc. All rights reserved.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol on Dec 29th...

@rene-dekker rene-dekker force-pushed the ci-1800-recommended-labels branch 5 times, most recently from 628c1c9 to 1cbb0a6 Compare December 30, 2025 16:39
"app.kubernetes.io/instance": "tigera-secure",
"app.kubernetes.io/managed-by": "tigera-operator",
"app.kubernetes.io/name": "tigera-external-prometheus",
"app.kubernetes.io/part-of": "TigeraSecureEnterprise",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do CalicoEnterprise with the enterprise variant?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Expect(serviceMonitor.Spec.Endpoints).To(HaveLen(1))
// Verify that the default settings are propagated.
Expect(serviceMonitor.Labels).To(Equal(map[string]string{render.AppLabelName: monitor.TigeraExternalPrometheus}))
Expect(serviceMonitor.Labels).To(Equal(map[string]string{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about app.kubernetes.io/version?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"?

@rene-dekker rene-dekker force-pushed the ci-1800-recommended-labels branch from 54bfbbc to 0c939f5 Compare January 16, 2026 19:52
@rene-dekker rene-dekker deleted the ci-1800-recommended-labels branch January 16, 2026 19:52
@rene-dekker rene-dekker restored the ci-1800-recommended-labels branch January 16, 2026 19:55
@rene-dekker rene-dekker deleted the ci-1800-recommended-labels branch January 16, 2026 19:57
@rene-dekker rene-dekker restored the ci-1800-recommended-labels branch January 16, 2026 19:58
@rene-dekker rene-dekker deleted the ci-1800-recommended-labels branch January 16, 2026 19:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants