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
add --conf
option for registering instance config in flux-batch
and flux-alloc
#5232
Conversation
ebc67f3
to
7df2401
Compare
# flux: --conf=""" | ||
# flux: [resource] | ||
# flux: noverify = true | ||
# flux: """ |
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 just noticed that noverify is not documented. Perhaps should pick something else for the user facing docs?
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.
Oh, yeah, I probably meant to use norestrict
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.
Went with resource.exclude
which might actually be useful. 🤷
I'm addressing some of the issues caught by CodeQL and will do a force-push shortly... |
c2ef085
to
3773025
Compare
Problem: There is no way to easily create a subinstance jobspec with an embedded alternate config file via the from_nest_command() or from_batch_command() constructors. Add a `conf` parameter to these two Jobspec class factory methods. If present, this argument will place a `conf.json` entry in the RFC 37 `files` dictionary of the resulting jobspec, and will append -c {{tmpdir}}/conf.json To the broker command line.
Problem: There are no options to specify a config file for subinstances created by `flux-batch(1)` and `flux-alloc(1)`, but it would be extremely useful to be able to do so. Add a `--conf=CONF` option to these commands. The option supports several types of arguments, and may be specified multiple times to update the built configuration: - If `CONF` is a multiline string, then parse `CONF` as JSON or TOML and update config. - If `CONF` contains an `=`, then parse `CONF` as config `KEY`=`VAL` and update config `KEY` with `VAL`, where `VAL` is parsed as JSON. - If `CONF` ends in `.json` or `.toml`, then treat `CONF` as a path to a config file to load as JSON or TOML. - Future extension: Otherwise, load a "named configuration" file from a local repository of config files. The config is built iteratively using a new BatchConfig class in cli/base.py
It was actually straightforward to add the "named" config support, so I've tentatively done that here. (Still need to document it, but thought I'd see what reviewers thought first). The named config support allows a set of The intent is that cluster admins could put, for example, a node-exclusive config in |
Hm, github isn't displaying the new commits perhaps there is an issue b/c I swear I've pushed the latest... |
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 played with this a bit manually and I'm not spotting anything in a (admittedly cursory) review of the code, so tentatively approving! Perhaps @chu11 could give the python a look before merging.
Just pushed updated documentation for the |
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 noticed a few small things
t/t2716-python-cli-batch-conf.t
Outdated
test_expect_success 'flux-batch --conf=FILE detects invalid syntax' ' | ||
cat <<-EOF >conf-bad.toml && | ||
[resource] | ||
noverify = foo | ||
EOF | ||
test_must_fail flux batch --conf=conf-bad.toml -n1 --dry-run \ | ||
--wrap hostname >parse-error.out 2>&1 && | ||
test_debug "cat parse-error.out" && | ||
grep "parse error" parse-error.out | ||
' |
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.
should test invalid json syntax too?
src/bindings/python/flux/cli/base.py
Outdated
# Take the first matching filename preferring TOML: | ||
for ext in (".toml", ".json"): | ||
filename = f"{path}/{name}{ext}" | ||
print(f"checking path {filename}", file=sys.stderr) |
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 want to make sure if this is not left over debugging? sort of feels like it could be.
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.
Yes, thanks for catching that!
@@ -388,6 +388,8 @@ class BatchConfig: | |||
Iteratively build a "config" dict from successive updates. | |||
""" |
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.
commit message "useful to users under /etc/xdg/flux/config/*.toml" should be {*.toml, *.json}
?
Problem: There are no tests that excercise the flux-batch/alloc --conf option. Add a new sharness test, t2716-python-cli-batch-conf.t, to test operation of this option and its various supported arguments.
Problem: The --conf option is undocumented. Add documentation for this option to man1/common/submit-other-options.rst.
Problem: Creation of a search path based on the XDG standard may be useful in multiple places, but the code to do this is currently embedded in the UtilConfig class. Move the construction of the XDG search path to its own function for reusability. Add an optional `subdir` parameter to the function so that callers which need to build a set of paths in a subdir of the XDG search path need not do this manually.
Problem: There is currently no way to register a set of named config files for use with the --conf=NAME job submission option. Add support for named configuration files which are loaded from a searchpath following the XDG specification. This allows system administrators to register a set of standard configurations that would be most useful to users under /etc/xdg/flux/config/*.{toml,json}, and users can easily select one by name with the --conf option. Users can also place their own configs uner ~/.config/flux/config and use those as named configs as well.
Problem: The tests in t2716-python-cli-batch-conf.t do not test named config file support. Add a set of tests to exercise this functionality.
Problem: The flux-jobs(1) CONFIGURATION section specifies that /etc/flux/xdg is the default search path when XDG_CONFIG_DIRS is not set, but it should be /etc/xdg/flux. Fix the incorrect path.
Problem: The use of "named" configuration with the submission command --conf option is not documented. Document the operation and use of the --conf=NAME option for flux submission commands.
Thanks @chu11! Made the suggested changes and forced a push. |
Codecov Report
@@ Coverage Diff @@
## master #5232 +/- ##
==========================================
- Coverage 83.79% 83.77% -0.02%
==========================================
Files 448 448
Lines 75855 75940 +85
==========================================
+ Hits 63559 63618 +59
- Misses 12296 12322 +26
|
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!
This PR adds a
--conf
option toflux-alloc
andflux-batch
which allows users to iteratively build a JSON config file in the jobspec file archive (i.e..attributes.system.files["conf.json"].data
). If this option is used once, then-c{{tmpdir}}/conf.json
is appended to the broker options so that the config becomes the child instance config. The--conf=ARG
option takes several possible types of arguments:ARG
contains a newline, then it is assume to be a multiline configuration and is parsed as JSON or TOML. This allows config to be embedded directly in a batch directiveARG
contains a=
, the argument is assumed to bekey=value
wherekey
can be dotted to set hierarchical values, and value is parsed as JSON -- e.g.--conf=resource.noverify=true
ARG
ends in.json
or.toml
then the argument is assumed to be a path to a file in JSON or TOML.The
--conf
option may be used multiple times to iteratively build a config on the command line.I'm actually tempted to add the
--conf
option to all submission commands, e.g. it could be useful withflux run OPTIONS.. flux start -o,-c{{tmpdir}}/conf.json
.I also wonder if might be useful to add an argument that initializes a job's config from the enclosing instance config.