Kustomize: Adding individual labels to configMap

[nbn]

I have come cross a situation where I would like to generate the configmap using kustomize, but I need to add an additional label to some individual configMaps. They are needed in our case because of cluster-wide management tools need to introspect certain configMaps, which are designated with specific labels.

I cannot find a simple solution (commonLabel would be too much), but am currently resolving it by keeping those configMaps in yaml.

configMapGenerator:
- name: my-config-map
  envs:
  - some.properties
  labels:
  - howto: do-this

Any suggestions or is this a feature request.

[jbrette]

Don't think this is a bug nor a feature request. Have a look at a mix of generator and patches here. This shows you how to add individual labels.

This is the output of the kustomize build command

apiVersion: v1
data:
  a: "0"
kind: ConfigMap
metadata:
  labels:
    apps: a
  name: a-config-map-26kgmbk2md
---
apiVersion: v1
data:
  b: "1"
kind: ConfigMap
metadata:
  labels:
    apps: b
  name: b-config-map-gh56k7ggb5

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[benjamin-bergia]

Having the same issue here.
I generate a bunch of configmaps (~10) and I just want to add a labels on each. There is no value in the generator if I need to make 10 distinct json patches to add a label.

Can we have a feature request for this? The current CM generators are very powerful and concise but are pointless if adding metadata requires patches.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.

[adrian-gierakowski]

/remove-lifecycle rotten

[adrian-gierakowski]

/reopen

[k8s-ci-robot]

@adrian-gierakowski: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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.

[adrian-gierakowski]

can we please reopen this?

[QuRa]

Since v3.5.5 it is already available by an options field LINK

- name: dashboards
  files:
  - mydashboard.json
  options:
    annotations:
      dashboard: "1"
    labels:
      app.kubernetes.io/name: "app1"

[deen13]

I think especially when using kubectl --prune to remove the old configmaps this would be a handy feature.