-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
exec function working dir is the kustomization that referenced it #4125
Conversation
[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 |
/retest |
@natasha41575: This PR has multiple commits, and the default merge method is: merge. 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. |
34ba6f7
to
8569269
Compare
8569269
to
62077c3
Compare
kyaml/runfn/runfn.go
Outdated
@@ -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] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
c9b622b
to
3d2354f
Compare
3d2354f
to
b85a648
Compare
b85a648
to
246c54a
Compare
122d708
to
b7936cc
Compare
b7936cc
to
54613b9
Compare
54613b9
to
16482c9
Compare
There was a problem hiding this 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.
88fd52a
to
b9183a3
Compare
b9183a3
to
05228bb
Compare
There was a problem hiding this 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
@@ -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 != "" { |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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()) |
There was a problem hiding this comment.
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.
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