Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exec function working dir is the kustomization that referenced it #4125

Merged
merged 5 commits into from
Aug 20, 2021

Conversation

natasha41575
Copy link
Contributor

@natasha41575 natasha41575 commented Aug 18, 2021

As discussed in #4117, this PR changes the working directory of exec functions to be the directory of the kustomization that referenced it.

@yuwenma

ALLOW_MODULE_SPAN

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Aug 18, 2021
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: natasha41575

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 18, 2021
@natasha41575
Copy link
Contributor Author

/retest

kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
kyaml/fn/runtime/exec/exec.go Outdated Show resolved Hide resolved
api/internal/target/kusttarget.go Outdated Show resolved Hide resolved
kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
@k8s-ci-robot
Copy link
Contributor

@natasha41575: This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

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 natasha41575 added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label Aug 18, 2021
@@ -507,7 +507,16 @@ func (r *RunFns) ffp(spec runtimeutil.FunctionSpec, api *yaml.RNode, currentUser
}

if r.EnableExec && spec.Exec.Path != "" {
ef := &exec.Filter{Path: spec.Exec.Path}
annotations := api.GetAnnotations()
wd, ok := annotations[kioutil.WorkingDirAnnotation]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It occurs to me that this annotation could be set by the user, in theory. We should be overwriting it in all cases, but should we validate it just in case? i.e. throw an error if it doesn't "look like" a value we set--it's relative, or root. Or would it be an option to use an unserialized field on the FunctionSpec to more definitively prevent it from being settable by the user?

Not caused by this PR, but I'm surprised to notice that we're not doing any validation of the exec path at all. There are several restrictions on the Starlark path above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added some validation to make sure its an absolute path, and not the root

use an unserialized field on the FunctionSpec to more definitively prevent it from being settable by the user

Do we need to definitively prevent the user from setting it? If the user really wants to change the working directory when running kustomize fn run, should we let them?

If so, what would that look like in the code? I may need some guidance as I've never seen that or tried to do that before.

Also, please see the above comment for why kustomize fn run needs to fall back on the current directory when this annotation is missing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't honor a user set value here. The file path annotation should be set only by kustomize as it reads.

That's what AnnotateAll does, so lgtm.

Regardless, sanity checks are always a good idea, because down the road someone will change the code.

Makes sense to fall back to cwd.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting that AnnotateAll will overwrite anything the user put in, so we're good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting that AnnotateAll will overwrite anything the user put in, so we're good.

Unless there's a code path that doesn't run that, which as Natasha pointed out, is true of kustomize fn run--if I'm understanding correctly, the annotation would currently be honored in that code path, which we don't want.

If so, what would that look like in the code? I may need some guidance as I've never seen that or tried to do that before.

I think it would necessarily mean not using an annotation for this, but instead setting the root as a field on one of the function-related structs that are used for configuration. I'm not confident in my understanding of these code paths, but maybe the current kustomization root could be an option passed to loader creation in NewLoader within (b *Kustomizer) Run, then loadPlugin could set it on a FunctionSpec.WorkingDir field?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How important is it that kustomize fn run does not honor the annotation? What are the consequences of allowing the user to set the working dir for this case?

In any case I am looking into seeing how we might be able to do without annotations now. The solution you've proposed is probably viable; I'll push the change soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@monopole @KnVerey the most recent commit takes the suggested approach, and passes down the working directory through parameters and fields so that we don't have to worry about the user ever being able to set it themselves. PTAL

kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
api/krusty/fnplugin_test.go Outdated Show resolved Hide resolved
api/krusty/fnplugin_test.go Outdated Show resolved Hide resolved
api/resmap/reswrangler.go Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 19, 2021
@natasha41575 natasha41575 removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 19, 2021
Copy link
Contributor

@KnVerey KnVerey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I like this approach better. Exec plugins carry inherent risk, so the more predictable and constrained we can make their invocation the better, IMO.

kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
api/internal/plugins/fnplugin/fnplugin.go Outdated Show resolved Hide resolved
kyaml/runfn/runfn.go Outdated Show resolved Hide resolved
@natasha41575 natasha41575 force-pushed the ExecFnWorkingDir branch 3 times, most recently from 88fd52a to b9183a3 Compare August 19, 2021 22:20
Copy link
Contributor

@monopole monopole left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

thanks! holding this in the ldr smells right

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 20, 2021
@k8s-ci-robot k8s-ci-robot merged commit 1e1b9b4 into kubernetes-sigs:master Aug 20, 2021
@@ -32,5 +38,16 @@ func (c *Filter) Run(reader io.Reader, writer io.Writer) error {
cmd.Stdin = reader
cmd.Stdout = writer
cmd.Stderr = os.Stderr
if c.WorkingDir != "" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the logic for having the path validations be here, right before we run the command, should the "working directory must be set" validation also go here Instead of in runfun.go?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other entry point to the exec filter is the container runtime code, which uses the exec filter to run docker run. To do this validation here, we would have to set the working directory there was well.

Currently, the place in runfn.go, where I have the "working directory must be set" validation, is only used when running exec functions.

I will defer to your opinion on whether the container runtime code should set the working directory for exec filters as well. The PR to do so is here: #4132

@@ -40,11 +40,13 @@ func NewKustTarget(
validator ifc.Validator,
rFactory *resmap.Factory,
pLdr *loader.Loader) *KustTarget {
pLdrCopy := *pLdr
pLdrCopy.SetWorkDir(ldr.Root())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #4350 for why this directory may not be the right choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants