kustomize edit add replacement

[Gikkman]

Is your feature request related to a problem? Please describe.
We got some scripts which generates a replacement file , and would like to automatically add the replacement file to the kustomization.yaml file. (I patch in a init container, and then we want that init container to have the same image as a main container. I know, it's hacky, but I am testing some PoCs) Similarly to how we can add a patch with kustomize edit add patch --path or a label with kustomize edit add label.

I've recently started working with replacements, so maybe I am missing something in the documentation or the intentions with it, but I can't see any support for this feature and I would consider it really useful.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Gikkman]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Gikkman]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[Gikkman]

/remove-lifecycle rotten

[annasong20]

@Gikkman Just to confirm, given a replacement.yaml, you'd like to add

replacements:
- path: replacement.yaml

to kustomization.yaml?

While we triage this feature request, how does kustomize edit add transformer replacement-transformer.yaml work for you? Since you already have the replacement.yaml, you'd only need to write a script that generates

# replacement-transformer.yaml
apiVersion: builtin
kind: ReplacementTransformer
metadata:
  name: your-choice
replacements:
- path: replacement.yaml

[annasong20]

@KnVerey How do we feel about this request for kustomize edit add replacement?

I'm not very familiar with the rationale behind the kustomize edit command and why we support adding some fields but not others. I assume kustomize edit add doesn't have built-in support for replacements because it's a newer field?

[annasong20]

/triage under-consideration

[annasong20]

/triage accepted

on the condition that kustomize edit add replacement is only responsible for accepting a replacement.yaml and adding

replacements:
- path: replacement.yaml

This command should not be responsible for adding an "inline" replacement

replacements:
- source:
    ...
  targets:
  ...

given all the field values under source and targets as flags.

[annasong20]

/good-first-issue

[annasong20]

/remove-good-first-issue

[Gikkman]

Hi @annasong20 . Sorry for the late reply.

Just to confirm, given a replacement.yaml, you'd like to add

replacements:
- path: replacement.yaml

to kustomization.yaml?

Yes. This is the same behavior we see when we use kustomize edit add patch, so that seems reasonable. Worth noting I guess is that if the kustomization.yaml file already contains an array of replacements, the added replacement(s) should be added to the existing array (again, similar to how kustomize edit add patch works).

[charles-chenzz]

to confirm something, are we trying to add a sub-command on kustomize edit add ? as I would like to take this issue

[annasong20]

add a sub-command on kustomize edit add ? as I would like to take this issue

@charles-chenzz, that's correct!

[charles-chenzz]

/assign

[charles-chenzz]

hi @Gikkman . can you provide a detail example of the input and output that we expect? It would help a lot for the implement! Thanks

[Gikkman]

From how I've use kustomize in the past, I think the following two cases should explain. Please note that the command doesn't validate whether anything actually exists at the path we give it, it merely adds to the kustomization.yaml file (this is consistent with the other edit add ... commands).

Case 1 - No pre-existing replacements list

>> Layout
kustomize/
├─ kustomization.yaml
├─ changes.yaml

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

resources:
  - deployment.yaml

We want to add the replacement.yaml file to the kustomization.yaml. We position our shell in the kustomize folder, and execute the following command:

kustomize edit add replacement --path changes.yaml

This should add a list named replacements in the kustomization.yaml, with one element (the path we passed) like this:

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

resources:
  - deployment.yaml
replacements:
- path: changes.yaml

Case 2 - A pre-existing replacements list

>> Layout
kustomize/
├─ kustomization.yaml
├─ replacements.yaml
├─ changes.yaml

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

resources:
  - deployment.yaml

replacements:
- path: replacement.yaml

We want to add the replacement.yaml file to the kustomization.yaml. We position our shell in the kustomize folder, and execute the following command:

kustomize edit add replacement --path changes.yaml

This should append to the list named replacements in the kustomization.yaml (the path we passed), like this:

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

resources:
  - deployment.yaml
  
replacements:
- path: replacement.yaml
- path: changes.yaml

[charles-chenzz]

so we only accept the --path changes.yaml and write it to the field replacements in kustomization.yaml? do we need to handle something like kustomize build . etc? and the field replacements in kustomization.yaml is exist or not? @Gikkman

[Gikkman]

so we only accept the --path changes.yaml and write it to the field replacements in kustomization.yaml?

Yes. (This is answered earlier in this issue thread, if you read it through from the start)

do we need to handle something like kustomize build . etc?

No. The kustomize edit add ... commands only adds entries to the kustomization.yaml file, nothing else.

and the field replacements in kustomization.yaml is exist or not?

Both case should be handled. Please see my previous post that outlined the two cases with expected input and output.

[annasong20]

@charles-chenzz To piggy back off of @Gikkman's response, this issue requests the implementation of

kustomize edit add replacement --path=file.yaml

As @Gikkman notes, this is very similar to the existing

kustomize edit add patch --path=file.yaml

which you can use as reference. If the replacements field

• does not yet exist in the kustomization.yaml, add the replacements field and its 1st entry - path: file.yaml.
• already exists, check that - path: file.yaml does not already exist. If it
  • exists, throw an error. You can check this behavior with kustomize edit add patch --path
  • does not exist, add it

Context
The kustomize edit commands only serve to modify the kustomization.yaml file, unlike kustomize build which actually operates on the manifests according to the kustomization.yaml. The kustomize edit add family of commands comes into handy when, for instance,

• the content of the kustomization.yaml changes in automated pipelines
• the user considers manual edits more error-prone

In addition to the use case @Gikkman provided in his issue description, say in your automated manifest promotion pipeline you wanted to add different annotations to your manifests for the different development, staging, and production environments. It'd be ideal if you didn't need (1) a human in the middle of your pipeline to add said annotations or (2) a more complicated bash script invoking sed or grep. This is where a command like kustomize edit add annotation would help!

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted