labels' includeSelectors doesn't do what it implies

[arttuperala]

Describe the bug

The new labels feature introduced in 4.1.0 includes a boolean flag called includeSelectors, which does not do what one might assume from the name. Examining the source code reveals that when includeSelectors is enabled, the label pairs are added just like commonLabels would be, and when includeSelectors is disabled, only metadata.labels is updated. This of course excludes selectors, but also other parts of the output that are not selectors, such as spec.template.metadata.labels.

includeSelectors should in my mind be updated to only include/exclude selectors, or it should be renamed to onlyMetadata or something to better reflect its actual behaviour.

Files that can reproduce the issue

kustomization.yaml

kind: Kustomization
apiVersion: kustomize.config.k8s.io/v1beta1

resources:
- deployment.yaml

labels:
- pairs:
    foo: bar
  includeSelectors: false

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: a
    app.kubernetes.io/instance: b
    app.kubernetes.io/name: c
    app.kubernetes.io/part-of: d
  name: deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: a
      app.kubernetes.io/instance: b
      app.kubernetes.io/name: c
      app.kubernetes.io/part-of: d
  template:
    metadata:
      labels:
        app.kubernetes.io/component: a
        app.kubernetes.io/instance: b
        app.kubernetes.io/name: c
        app.kubernetes.io/part-of: d

Expected output

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: a
    app.kubernetes.io/instance: b
    app.kubernetes.io/name: c
    app.kubernetes.io/part-of: d
    foo: bar
  name: deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: a
      app.kubernetes.io/instance: b
      app.kubernetes.io/name: c
      app.kubernetes.io/part-of: d
  template:
    metadata:
      labels:
        app.kubernetes.io/component: a
        app.kubernetes.io/instance: b
        app.kubernetes.io/name: c
        app.kubernetes.io/part-of: d
        foo: bar

Actual output

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: a
    app.kubernetes.io/instance: b
    app.kubernetes.io/name: c
    app.kubernetes.io/part-of: d
    foo: bar
  name: deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: a
      app.kubernetes.io/instance: b
      app.kubernetes.io/name: c
      app.kubernetes.io/part-of: d
  template:
    metadata:
      labels:
        app.kubernetes.io/component: a
        app.kubernetes.io/instance: b
        app.kubernetes.io/name: c
        app.kubernetes.io/part-of: d

Kustomize version

kustomize/v4.1.3

Platform

macOS

[Shell32-Natsu]

Yeah, maybe onlyMetadata is a better name.

[jbeisen]

I'm not sure onlyMetadata is better, because I think most users would want the labels applied to spec.template.metadata.labels too.

[mrmartan]

includeSelectors: false is exactly what also we want. This feature is missing for far too long. We were happy to finally see it in 4.1.0 only to find out its useless since is doesn't do what it promises, i.e. omitting the pairs from selectors and only that.

[RobinMcCorkell]

We also want labels to be applied everywhere except in selectors, so that frequently changing labels (like a version label) do not attempt to update Deployment selectors. This means that these labels should still be applied to Pod templates, just not the selectors that match on them.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[aibarbetta]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale