Ability to run replacements after transformers

[GuyPaddock]

Describe the solution you'd like

Ideally, there would be a way for us to indicate that we want a replacement to run after transformers have run, versus before.

We have created a transformer for Kustomize that generates storage definitions (e.g., PVs, PVCs, volumes, and volume mounts) from a set of templates and a static list of values, to handle the use case where several volumes and mounts can be dynamic but follow the sample basic recipe, such as when you have a multi-tenant situation.

For one of our applications, we need to be able to toggle whether a specific mount is read-only or not based on the value of a config map (e.g., during upgrades, the software being run needs its config volume to be writable, but for security and durability at all other times it needs to be read-only). For this situation, we'd normally use replacements, but since the mount in question gets added via our transformer, this doesn't work because the transformer runs after replacements has run.

Describe alternatives you've considered

Without the ability to run replacements after transformers, we have three less-ideal options:

1. Re-implement what replacements does within our own transformer, greatly increasing the scope and complexity of our transformer; OR
2. Move the volume in question out of being generated by our transformer (creating a maintenance burden since we have two places to maintain similar storage config); OR
3. Switch from using replacements to using the now-deprecated vars. (Doesn't seem to work; the variables do not get replaced by vars, likely because the readOnly field on a mount is a boolean field and vars only works for strings).

[k8s-ci-robot]

@GuyPaddock: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[natasha41575]

You can run replacements within the transformers field if you'd like, and if you want it to run after all your other transformers, you can place it last.

Here is an example if what that might look like:

kustomization.yaml:

transformers:
  - mytransformer1.yaml
  - |-
  apiVersion: builtin
  kind: ReplacementTransformer
  metadata:
    name: notImportantHere
  replacements:
    # your replacements here

Would this work for you?

Another option would be to create an overlay, and move your replacements to the overlay layer.

/kind support
/triage needs-information

[GuyPaddock]

@natasha41575 Whoa... I did not realize that you could compose transformers like that! Is it documented?

[GuyPaddock]

@natasha41575 The yaml you provided does not parse, but it does work if I put the transformer in its own file.

Only downside is that since the configmap being referenced varies by overlay, I have to put a copy of this transformer Yaml file with replacements in every overlay. Would be great if I could put it into a component, but components appear to run before transformers.

[natasha41575]

Ah I may have gotten something wrong with the indentation with the yaml I provided.

This isn't really documented anywhere... there is some stuff here: https://kubectl.docs.kubernetes.io/references/kustomize/builtins/

And an example in one of our tests here:

kustomize/api/krusty/legacyprefixsuffixtransformer_test.go

Lines 15 to 26 in 8dab949

	resources:
	- service.yaml
	transformers:
	- |-
	apiVersion: builtin
	kind: PrefixSuffixTransformer
	metadata:
	name: notImportantHere
	prefix: baked-
	suffix: -pie
	fieldSpecs:
	- path: metadata/name

This really should be documented somewhere, perhaps there should be a guide somewhere near the first link I sent or a transformers guide on the main kustomization doc page.

I have to put a copy of this transformer Yaml file with replacements in every overlay.

Could you try following the indentation style in this example? I think that should work. If not, we have a bug somewhere that needs to be fixed.

[GuyPaddock]

@natasha41575 That inline syntax works with that indentation; thank you!

I still have to copy the transformer between the various overlays b/c of the aforementioned "components run before transformers" piece, but this is definitely a lot closer to a solution! Thank you very much.

[natasha41575]

@GuyPaddock someone else made a similar request to control component ordering, we have KEPs open for a feature that will make it moot. Here is a comment explaining more with links: #4345 (comment)

Unless you have further questions, I think this issue can be closed. Feel free to reopen if you think there needs to be further discussion.

[GuyPaddock]

Sounds good! Thanks

[jeanmorais]

@natasha41575 Can I get the name transformed in some way, following what you suggested above?

I have a transformer to add a prefix and I'd like to use the name with the prefix in the replacements after that, in some simpler way.

transformers:
- nameprefix-transformer.yaml
- |-
  apiVersion: builtin
  kind: ReplacementTransformer
  metadata:
    name: notImportantHere
  replacements:
  - source:
      kind: Secret
      fieldPath: metadata.name
    targets:
    - select:
        kind: Pod
      fieldPaths:
      - metadata.annotations.[test.com/x]

apiVersion: v1
kind: Secret
metadata:
  name: prefix-my-secret
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    test.com/x: my-secret # I'd like to put "prefix-my-secret" here
  name: prefix-my-pod

[natasha41575]

@jeanmorais

Yeah, it's called PrefixTransformer. All of the transformers here work in the exact same way.

[natasha41575]

@GuyPaddock @jeanmorais If either of you two (or anyone else reading this) want to help document this, would highly appreciate it. A new guide here https://github.com/kubernetes-sigs/cli-experimental/tree/master/site/content/en/guides called "transformers" or something might be helpful. No pressure though, we will eventually get to it if no one else does.

[jeanmorais]

@jeanmorais

Yeah, it's called PrefixTransformer. All of the transformers here work in the exact same way.

First, thanks for the fast response.

I've used PrefixSuffixTransformer (nameprefix-transformer.yaml) in the example above. But, the ReplacementTransformer is called before the transformation, this way, I can't get the name with the prefix+metadata.name to use in the ReplacementTransformer. There is some way to do that?

Following the example above, I get metadata.name without the prefix. There is some way to get prefix+metadata.name?

  - source:
      kind: Secret
      fieldPath: metadata.name

[burmanm]

@jeanmorais Did you ever find a way? This makes the replacements utterly pointless and with Kustomize 5.0.x deprecating vars there's no way to do a lot of things. All the components that used to do these are now worthless since replacements can't be used in them.

[ArshiAAkhavan]

is there any update? i do have the same issue, I need name suffix/prefix to propagate into my replacements