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

[Feature Request] Allow passing user arguments to nomad actions #24143

Open
Freddo3000 opened this issue Oct 7, 2024 · 3 comments
Open

[Feature Request] Allow passing user arguments to nomad actions #24143

Freddo3000 opened this issue Oct 7, 2024 · 3 comments

Comments

@Freddo3000
Copy link

Proposal

Add the ability to pass parameters to nomad actions, similar to how you can pass arguments to parameterized jobs.

Use-cases

I have a user system running as a nomad service, and I want to add a new user to that system. Instead of launching a copy of the system to only perform that one action as a parameterized job, I would like to be able to just trigger a action on the running service job.

Attempted Solutions

Using a parameterized copy of the job in question.

@philrenaud
Copy link
Contributor

Hi @Freddo3000 , thanks for filing this issue. I think it's a great idea, and one we've considered strongly, but we decided against it because actions are designed to feel "locked down" by the jobspec author, and letting another operator change the context of an action at runtime feels like it goes against that a bit.

I think we'll probably still come around to doing this, but we probably have to make a few changes along the way (including, most likely, an ACL policy rule for something like run-action etc.), and possibly syntax for limiting the scope of args that could be passed to an action in the jobspec configuration.

For now, tagging this for future consideration.

@Freddo3000
Copy link
Author

Hi @Freddo3000 , thanks for filing this issue. I think it's a great idea, and one we've considered strongly, but we decided against it because actions are designed to feel "locked down" by the jobspec author, and letting another operator change the context of an action at runtime feels like it goes against that a bit.

I think we'll probably still come around to doing this, but we probably have to make a few changes along the way (including, most likely, an ACL policy rule for something like run-action etc.), and possibly syntax for limiting the scope of args that could be passed to an action in the jobspec configuration.

For now, tagging this for future consideration.

I came to think of that aspect as well, though I feel that it should be the responsibility of the jobspec author to ensure that whatever parameters are allowed are properly sanitized before being executed as part of the action (perhaps with some appropriate warnings in the documentation). That feels like it wouldn't be particularly different compared to parameterized nomad jobs, which depending on their design may run arbitrary code.

On that note, if you're going to add rules/policies for actions, then I'd like to suggest that you add it for parameterized jobs as well.

@philrenaud
Copy link
Contributor

add it for parameterized jobs
Wanted to note that we do have a dispatch-job capability that is separate from the submit-job one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants