option to specify path for kustomize edit

[andrewmclagan]

Using the CLI is very difficult as its not possible to specify an exact working path to a kustomization.yaml file.

For example:

kustomize edit set image redis:1.1.1

I HAVE to execute this inside the directory, it would be hugely useful to be able to specify the directory:

kustomize edit set image redis:1.1.1 --path /path/to/kustomization.yaml

[bittner]

We're looking for this feature, too. The kustomize edit add configmap command has a --from-file option to allow this kind of operation.

Currently, to give a concrete example, we have to do a cd into the target directory, and back again. This is not only ugly to read, but also error-prone in the execution (a known issue in shell programming when concatenating commands).

[aude]

One idea could be to use a subshell:

$ (cd overlays/dev && kustomize edit set image nginx:1.19.2)

Then you can be sure cd is temporary.

[gp42]

looking for this feature too...

[dmnemec]

Having this feature (from path or url) and another flag to output the edited file is what we're looking for, too. This would allow us to pipe it directly into kustomize build to enable easy 1-step deployments from our GitHub repo for customers.

[monopole]

Pushing back a bit -

kustomize follows a pattern used by make, git, go and other unix tools that operate with respect to some well-known file or directory name (Makefile, .git, go.mod etc.).

That's why (as @aude suggests in https://github.com/kubernetes-sigs/kustomize/issues/2803#issuecomment-676568964) it's common to see

( cd some/path; make)  # or `go mod edit`, or `git fetch`, etc

In this pattern, the current working directory is an implicit argument, like a global var. It impacts how paths appearing elsewhere are interpreted/validated. E.g. in these commands

kustomize edit add patch {filePath}
kustomize edit add component {filePath}
kustomize edit add secret my-secret --from-file=my-key={filePath}
... etc

{filePath} should be validated as a path that's contained by the kustomization root.

Adding a --path flag is more work than it appears, it's like converting a global var to something that instead is explicitly passed down to all the places it's used. Except here that's trickier since there's no explicit global var to hunt for. You have to look at file system use across the board. And make it easy for new code to use the same trick. Not impossible, since kustomize has an abstraction for the FS already, but still is bigger than just an edit flag.

@dmnemec one cannot pipe to kustomize build (for reasons similar to why one cannot pipe to make). so i don't understand https://github.com/kubernetes-sigs/kustomize/issues/2803#issuecomment-718776990

[afirth]

[edit: see my next comment for why I think this feature wouldn't align with current security design, because it would allow generating kustomization.yaml that cannot be built without load_restrictor none] @monopole I totally understand your reasoning that it's hard from an implementation perspective, however I'm not sure with your justification from a design perspective

1. make -C <dir> <target> works fine and make -f <file> <target> as well
2. My understanding is that git does not support nested gits. That is, it's not supported to have a .git folder further down the tree than another unless it's explicitly declared, so the only time this happens in my experience is when you want to work on a submodule from the parent module.
3. go mod edit <command> <dir/go.mod> also works fine. go mod init and such definitely don't :)

I think it's fine for git and go mod: the child is never referring to the parent by path. However kustomize bases/overlays are explicitly set up this way (which works great). So from the parent I want:

kustomize edit set image $image $image:sha -f clusters/$cluster
kustomize build clusters/$cluster | kubectl --context=$context apply -f -

or even

kustomize edit set image $image $image:sha -f clusters/$cluster -o - | kustomize build -f - | kubectl --context=$context apply -f -

because I don't actually want this image to go into a file forever.

of course the workaround is not too painful in this case, and the only case i can think of where it is is in "convenience" docker images - you either need to rewrite entrypoint as a bash pipe or call the image several times with different working directory

cd clusters/$cluster && kustomize edit set image $image $image:sha
cd clusters/$cluster && kustomize build | kubectl --context=$context apply -f -

Aside: you can definitely pipe to make, and I don't understand why you can't to kustomize. I assume you would be able to if/when a file is supported. | make -f - works, just like | kubectl apply -f - and | git apply -. A use case would be templating the kustomization.yaml on the fly for things you don't want in the repo (e.g. hostnames for example projects)

Thanks for all your hard work. I agree this feature has easy workarounds for now, but they can certainly get ugly and don't match the other common tools paradigms.

[afirth]

just found another use case, but this is a firm against I think, which is currently not possible as far as I can tell:

kustomize edit add secret config --from-file ../../../secrets/config.json
Error: loading KV pairs: file sources: [../../../secrets/config.json]: security; file '/xyz/config.json' is not in or below '/xyz/dir`

would become

kustomize edit add secret config --from-file secrets/config.json -f <somedir>/kustomization.yaml

You could argue that --load_restrictor=none could be used here, but that's currently not valid for this command, I assume because it would generate a kustomization that is then insecure and cannot be used without load_restrictor none. Of course, lots of people end up with kustomizations like this anyway...

Unless I'm missing something, that's a pretty firm "won't fix" if kustomize stays with the current security model, for the same reason that kustomize edit doesn't accept load_restrictor none

[lovell]

If your shell supports them, using pushd and popd provides a slightly cleaner approach than a subshell.

pushd overlays/dev
kustomize edit set image ...
popd
kustomize build ...

[bittner]

What is great about pushd and popd, cd ... and cd -? It's all custom scripting that makes execution, say, in a CI pipeline super-fragile. There is no point in defending the current implementation state. It's plain uncomfortable. This feature is missing.

[aude]

Isn't it a matter of simple vs easy?

Using cd is simple, while controlling directory inside kustomize means more lines of code; more complexity.

Like in these examples from man git archive:

• git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)
• git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz
• git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz

cd is the guy that controls the directory. Instead of implementing cd into every tool.

[aude]

Although, while doing research for my previous reply, I was a bit surprised that kustomize build can set the kustomization root but kustomize edit can't.

Maybe it would make sense to follow make, git and tar, and change this:

$ kustomize build overlays/dev

to this:

$ kustomize -C overlays/dev build

Then one could do:

$ kustomize -C overlays/dev build
$ kustomize -C overlays/dev edit set image redis:1.1.1
$ kustomize -C overlays/dev edit add patch --path={filepath}
$ kustomize -C overlays/dev edit add component {filepath}
$ kustomize -C overlays/dev edit add secret my-secret --from-file=my-key={filepath}
...

Having the kustomization root as a global argument might mean less complexity too? Instead of local arguments like kustomize build DIR.

I don't know how easy it is to change at this stage though, it's a big interface change.

[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-contributor-experience at kubernetes/community. /lifecycle stale

[bittner]

Any chance this gets addressed?

[captainrdubb]

/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

[bittner]

/remove-lifecycle stale

The edit command is a critical feature that needs more attention.

[d3vpasha]

This feature is still expected :)

[octopop]

/remove-lifecycle stale

+1 would make our CI/CD pipelines a lot cleaner with this feature.

[troylelandshields]

The fact that I can specify a path to a kustomization file when I use kustomize build would lead me to expect the same behavior when using pretty much any other kustomize sub-command, including edit.

[mr-davidc]

I too agree that this would be a great feature to have and would help clean up some of my CI/CD pipeline steps

[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

[afirth]

/remove-lifecycle stale

came up again...

[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

[wadexu007]

looking for this feature too...

[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

[gustavovalverde]

/remove-lifecycle rotten

This is needed

[antonioua]

that would be a great feature for CI pipelines

[steeling]

If I understand this you actually can't manage this declaratively with the given API. Try the following:

mkdir myfiles
touch myfiles/file1.json myfiles/file2.json
kustomize edit add configmap my-map --files=myfiles/*.json
rm file1.json
touch file3.json

There are now no commands that let you edit the files to contain file2.json and file3.json.

The following fails since it will try to read the old contents:

kustomize edit add configmap my-map --files=myfiles/*.json

There is no subcommand for kustomize edit remove corresponding to configmaps.

Anybody know of a workaround for this?

[pedrorodrigwez]

Feature required!

[dtherhtun]

This feature is still expected :) +1