Per configMap defined labels in configMapGenerator

[aschaber1]

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?

I'd like to set labels on a configMap level and not only on a generatorOptions level, which causes all configMaps to have these labels.

Why is this needed?

I'd like to use this to add configMaps containing Grafana Dashboards. These need a label: grafana_dashboard: 1.
But I don't want this on all configMaps I'm generating with this kustomization. For instance I regularly create a configMap for Flux' Helm values.yaml. This configMap should not have that label.

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

Yes, by manually generating configMaps like this and adding the result to the resources:

kubectl create configmap --dry-run=client -o yaml --from-file 13768_rev4.json grafana-dashboard > grafana-dashboard.yaml

What other solutions have you considered?

Above manual configmap solution.

Anything else we should know?

Here's an example of how it could look:

configMapGenerator:
  - name: grafana-dashboard-13768
    labels:
      grafana_dashboard: "1"
    files:
      - grafana_dashboard.json=13768_rev4.json

Feature ownership

• I am interested in contributing this feature myself! 🎉

[ephesused]

This feature is available via options, which basically is a per-generator generatorOptions:

kustomization.yaml

configMapGenerator:
- name: grafana-dashboard-has-label
  options:
    labels:
      grafana_dashboard: "1"
  literals:
  - key=value
- name: other-configmap-lacks-label
  literals:
  - other-key=other-value

$ kustomize build .
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  labels:
    grafana_dashboard: "1"
  name: grafana-dashboard-has-label-t757gk2bmf
---
apiVersion: v1
data:
  other-key: other-value
kind: ConfigMap
metadata:
  name: other-configmap-lacks-label-t8297hht97

$

[stormqueen1990]

Hi there, @aschaber1! Could you please check if the solution offered in #5724 (comment) addresses your issue?

/kind support
/triage needs-information

[aschaber1]

Awesome, works for us :) Thank you for pointing us in the right direction.