Need better validation of various plugin's options in jobspec #3819
Unanswered
SteVwonder
asked this question in
Design
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Right now we have three sets of plugins that look to the jobspec of jobs for their options:
We already have support for dependency modules to register which schemas they support. That way if a user submits a job with a dependency scheme with no corresponding module that supports the scheme, they get an error shortly after submission.
We don't have a similar setup for jobtap or job-shell plugins. As an example of why this is important, in #3802 a user submitted a job with the alloc-bypass option, but the alloc-bypass jobtap plugin was not loaded. This resulted in weird behavior (the job hung unexpectedly). It would be nice if the job could be rejected early on (either at ingestion or in the initial processing by jobtap plugins) rather than sitting in the scheduler queue. Same goes for a malformed job-shell plugin.
It would also be good to have validation for the opposite case (i.e., the user adds an option for a module/plugin that is loaded). As an example, maybe the user add
--setattr system.data-staging=foo
to theirflux mini
invocation. It would be great if thedata-staging
plugin could run a quick validation to see iffoo
is a valid value.Since we have three sets of plugins/modules that need the same functionality, might be a good opportunity to use the same abstraction to solve the problems in a consistent way.
Beta Was this translation helpful? Give feedback.
All reactions