Inconsistent transformer behavior on configMapGenerator when used via components vs not

[alexlatchford]

What happened?

Labels and annotations set from components do not apply to ConfigMap resources created by configMapGenerator, but do apply to other resources.

What did you expect to happen?

The labels and annotations from components would apply to ConfigMap resources created by configMapGenerator.

How can we reproduce it (as minimally and precisely as possible)?

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

components:
- components/metadata

resources:
- namespace.yaml

transformers:
  - metadata.yaml

commonAnnotations:
  inline-commonAnnotations: bar

commonLabels:
  inline-commonLabels: bar

configMapGenerator:
  - name: cm
    literals:
      - A=b

# metadata.yaml
apiVersion: builtin
kind: LabelTransformer
metadata:
  name: metadata
labels:
  inline-labelTransformer: true
fieldSpecs:
- path: metadata/labels
  create: true
---
apiVersion: builtin
kind: AnnotationsTransformer
metadata:
  name: metadata
annotations:
  inline-annotationsTransformer: true
fieldSpecs:
- path: metadata/annotations
  create: true

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ns

# components/metadata/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component

transformers:
- metadata.yaml

commonAnnotations:
  component-commonAnnotations: bar

commonLabels:
  component-commonLabels: bar

# components/metadata/metadata.yaml
apiVersion: builtin
kind: LabelTransformer
metadata:
  name: metadata
labels:
  component-labelTransformer: true
fieldSpecs:
- path: metadata/labels
  create: true
---
apiVersion: builtin
kind: AnnotationsTransformer
metadata:
  name: metadata
annotations:
  component-annotationsTransformer: true
fieldSpecs:
- path: metadata/annotations
  create: true

Expected output

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    component-annotationsTransformer: "true"
    component-commonAnnotations: bar
    inline-annotationsTransformer: "true"
    inline-commonAnnotations: bar
  labels:
    component-commonLabels: bar
    component-labelTransformer: "true"
    inline-commonLabels: bar
    inline-labelTransformer: "true"
  name: ns
---
apiVersion: v1
data:
  A: b
kind: ConfigMap
metadata:
  annotations:
    component-annotationsTransformer: "true"
    component-commonAnnotations: bar
    inline-annotationsTransformer: "true"
    inline-commonAnnotations: bar
  labels:
    component-commonLabels: bar
    component-labelTransformer: "true"
    inline-commonLabels: bar
    inline-labelTransformer: "true"
  name: cm-b9t2424hkf

Actual output

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    component-annotationsTransformer: "true"
    component-commonAnnotations: bar
    inline-annotationsTransformer: "true"
    inline-commonAnnotations: bar
  labels:
    component-commonLabels: bar
    component-labelTransformer: "true"
    inline-commonLabels: bar
    inline-labelTransformer: "true"
  name: ns
---
apiVersion: v1
data:
  A: b
kind: ConfigMap
metadata:
  annotations:
    inline-annotationsTransformer: "true"
    inline-commonAnnotations: bar
  labels:
    inline-commonLabels: bar
    inline-labelTransformer: "true"
  name: cm-b9t2424hkf

Kustomize version

v5.0.0

Operating system

MacOS

---

Obviously a very minor bug (if you can even call it that, maybe this is just expected behavior) for a very niche scenario but wondered whether I'd missed something about resolution order here in the docs.

[snuggie12]

This happens to me as well when using the helm chart generator and patches.

I think in general the manifest does not yet contain the resources when the transformer executes. I was curious if there was a way to re-order them or ask for a refresh or something.

@alexlatchford BTW, you can test this if you move the ConfigMapGenerator to a base and call via

resources:
  - ../base

../base will run it's kustomization.yaml prior to running your components and therefore the CM will be in the manifest. I know that doesn't solve your problem (it doesn't solve mine either,) but would be a good way to confirm.

[KnVerey]

Obviously a very minor bug (if you can even call it that, maybe this is just expected behavior) for a very niche scenario but wondered whether I'd missed something about resolution order here in the docs.

It is in fact expected behaviour, and it is due to the order in which Kustomize fields are processed: first resources, then components, then other generators (including the config map generator), then transformers, then validators. There's no perfect ordering to be had; if we instead ran other generators before the components, then for example the merge behaviour of ConfigMapGenerator wouldn't work with them. For many built-in generators and transformers, the generators and transformers fields can be used to control their execution order--that may work for you @snuggie12 since the helm and configmap generators both work in generators. But resources and components are not exposed that way, so I believe the only option for @alexlatchford case is to introduce additional layers as @snuggie12 noted. #4402 would enable the generators solution for bases and components fwiw, but it is a big undertaking and nobody is working on it right now.

/triage out-of-scope
/close

[k8s-ci-robot]

@KnVerey: Closing this issue.

In response to this:

Obviously a very minor bug (if you can even call it that, maybe this is just expected behavior) for a very niche scenario but wondered whether I'd missed something about resolution order here in the docs.

It is in fact expected behaviour, and it is due to the order in which Kustomize fields are processed: first resources, then components, then other generators (including the config map generator), then transformers, then validators. There's no perfect ordering to be had; if we instead ran other generators before the components, then for example the merge behaviour of ConfigMapGenerator wouldn't work with them. For many built-in generators and transformers, the generators and transformers fields can be used to control their execution order--that may work for you @snuggie12 since the helm and configmap generators both work in generators. But resources and components are not exposed that way, so I believe the only option for @alexlatchford case is to introduce additional layers as @snuggie12 noted. #4402 would enable the generators solution for bases and components fwiw, but it is a big undertaking and nobody is working on it right now.

/triage out-of-scope
/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.

[alexlatchford]

Thanks for turning on the lights here @KnVerey, totally makes sense!