Labels support for Transformer Configurations

[ciaccotaco]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

Currently (as of kustomize 5.3.0), there is no labels support for Transformer Configurations. It would be beneficial to add support for labels, as commonLabels is deprecated.

Why is this needed?

This is needed because

1. commonLabels is deprecated
2. The combination of labels in the base kustomizationl.yaml file only works with a commonLabels transformer configuration when includeSelectors: true is configured. If the granularity for not including selectors (or templates) is needed, then there is no support for a labels transform configuration.

Can you accomplish the motivating task without this feature, and if so, how?

There is no way to use custom transformer configurations with labels and a combination of includeSelectors: false).

What other solutions have you considered?

The only option is to continue using the commonLabels transformer config and labels with includeSelectors: true

Anything else we should know?

Example

An example of what the end user would configure is the following:

YAMLs

File Structure

├── kconf
│   └── configurations.yaml
├── kustomization.yaml
└── resources
    └── flinkdeployment.yaml

Base Kustomization

configurations:
  - kconf/configurations.yaml

labels:
  - includeSelectors: false # or true
    includeTemplates: true  # or false
    pairs:
      app: myapp
      contact: username
      department: kustomize
      environment: dv

resources:
  - resources/flinkdeployment.yaml

Transformer Configuration

labels:
  - path: spec/podTemplate/metadata/labels
    create: true
    kind: FlinkDeployment
  - path: spec/jobManager/podTemplate/metadata/labels
    create: true
    kind: FlinkDeployment
  - path: spec/taskManager/podTemplate/metadata/labels
    create: true
    kind: FlinkDeployment

Resource

apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  labels: {}
  name: myflinkapp
spec:
  jobManager:
    podTemplate:
      metadata:
        labels: {}
  podTemplate:
    metadata:
      labels: {}
  taskManager:
    podTemplate:
      metadata:
        labels: {}

Output

apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  labels:
    app: myapp
    contact: username
    department_name: kustomize
    environment: dv
  name: myflinkapp
spec:
  jobManager:
    podTemplate:
      metadata:
        labels:
          app: myapp
          contact: username
          department_name: kustomize
          environment: dv
  podTemplate:
    metadata:
      labels:
        app: myapp
        contact: username
        department_name: kustomize
        environment: dv
  taskManager:
    podTemplate:
      metadata:
        labels:
          app: myapp
          contact: username
          department_name: kustomize
          environment: dv

Feature ownership

• I am interested in contributing this feature myself! 🎉

[koba1t]

/assign @stormqueen1990

[saschaa442]

Highly interested as well!

[stormqueen1990]

Hello there, @ciaccotaco! 👋

The labels structure in the Kustomization file can optionally take a list of fields to which you would like to apply the labels. I tested it locally and it appears to cover the use case you described in this issue, but would you please give it a try and confirm whether it works for your use case?

The configuration I tested looks similar to the following:

labels:
  - includeSelectors: false # or true
    includeTemplates: true  # or false
    pairs:
      app: myapp
      contact: username
      department: kustomize
      environment: dv
    fields:
      - path: spec/podTemplate/metadata/labels
        create: true
        kind: FlinkDeployment
      - path: spec/jobManager/podTemplate/metadata/labels
        create: true
        kind: FlinkDeployment
      - path: spec/taskManager/podTemplate/metadata/labels
        create: true
        kind: FlinkDeployment

resources:
  - resources/flinkdeployment.yaml

Note the absence of the configurations section in this example.

[stormqueen1990]

/kind support
/triage needs-information

[stormqueen1990]

/remove-kind feature

[ciaccotaco]

Hi @stormqueen1990 👋

I tested your suggestion and it indeed works - I guess I should have rtfm!

Our GitOps pipeline uses a common set of configs that are referenced when applications are promoted between environments. Having transformer configuration support for labels would help ease the transition from commonLabels (and let us utilize the sweet new functionality to ignore selectors 😀).

While a desirable feature, I understand if it is something that cannot be implemented. We can certainly make things work using labels.fields.

Thanks!

Edit: It currently is not in the manual. Thank you for creating an issue to add it.

[stormqueen1990]

Hi @stormqueen1990 👋

I tested your suggestion and it indeed works - I guess I should have rtfm!

Our GitOps pipeline uses a common set of configs that are referenced when applications are promoted between environments. Having transformer configuration support for labels would help ease the transition from commonLabels (and let us utilize the sweet new functionality to ignore selectors 😀).

While a desirable feature, I understand if it is something that cannot be implemented. We can certainly make things work using labels.fields.

Thanks!

Edit: It currently is not in the manual. Thank you for creating an issue to add it.

Nice to know this addresses your use case! I added a note to record this feedback in #5436 (comment), as the deprecation of commonLabels is being handled through that other issue.

I will be closing this issue but feel free to reopen if needed!

/close

[k8s-ci-robot]

@stormqueen1990: Closing this issue.

In response to this:

Hi @stormqueen1990 👋

I tested your suggestion and it indeed works - I guess I should have rtfm!

Our GitOps pipeline uses a common set of configs that are referenced when applications are promoted between environments. Having transformer configuration support for labels would help ease the transition from commonLabels (and let us utilize the sweet new functionality to ignore selectors 😀).

While a desirable feature, I understand if it is something that cannot be implemented. We can certainly make things work using labels.fields.

Thanks!

Edit: It currently is not in the manual. Thank you for creating an issue to add it.

Nice to know this addresses your use case! I added a note to record this feedback in #5436 (comment), as the deprecation of commonLabels is being handled through that other issue.

I will be closing this issue but feel free to reopen if needed!

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.