You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the only way to specify a configuration for a subinstance run via flux mini alloc or flux mini batch is to pass a --config-path=PATH option down to the broker via the flux-mini --broker-opts option, e.g.
flux mini alloc --broker-opts="-c /home/grondo/myconf"
However, there are several drawbacks here:
the configuration under /home/grondo/myconf could be updated between job submission and job start
the configuration isn't captured along with the job record in any way, besides its path
small updates to the configuration can't be made without copying the config to a per-job directory
Instead of leaving the configuration to be read at runtime by the broker from the original filesystem path, the config should be read by flux mini batch or flux mini alloc and the resulting JSON representation placed into a well-known attribute in the jobspec. The job shell batch plugin can then write this configuration out to a temporary directory and pass it along to the brokers via the -c option.
A --setconf or similar option should also be added, which would amend the loaded (or default empty) configuration in the jobspec, allowing easy one-off updates to a more generic configuration placed on disk.
We have also previously discussed the use of "named" configuration paths. These could be specified by name on the flux mini command line, with the option of a "default" system or user provided named config that is used as a starting point when no configuration name is specified.
The system could provide a set of named configs, which could be overridden by users in a ~/.flux/configs directory or similar. As noted by @garlick, this would allow workflows to provide standard configs that could easily be selected by users.
The text was updated successfully, but these errors were encountered:
with that foundation laid, I expected to have basic support for embedding config under a well known key (may need an RFC 14 update) in jobspec, with a method for updating the config on the command line.
We then hope to add a way to established some kind of named configuration scheme (perhaps should open a separate issue on this) allowing users to easily select a starting config, e.g. --conf=node-exclusive.
From an offline discussion with @garlick:
Currently, the only way to specify a configuration for a subinstance run via
flux mini alloc
orflux mini batch
is to pass a--config-path=PATH
option down to the broker via theflux-mini --broker-opts
option, e.g.However, there are several drawbacks here:
/home/grondo/myconf
could be updated between job submission and job startInstead of leaving the configuration to be read at runtime by the broker from the original filesystem path, the config should be read by
flux mini batch
orflux mini alloc
and the resulting JSON representation placed into a well-known attribute in the jobspec. The job shellbatch
plugin can then write this configuration out to a temporary directory and pass it along to the brokers via the-c
option.A
--setconf
or similar option should also be added, which would amend the loaded (or default empty) configuration in the jobspec, allowing easy one-off updates to a more generic configuration placed on disk.We have also previously discussed the use of "named" configuration paths. These could be specified by name on the
flux mini
command line, with the option of a "default" system or user provided named config that is used as a starting point when no configuration name is specified.The system could provide a set of named configs, which could be overridden by users in a
~/.flux/configs
directory or similar. As noted by @garlick, this would allow workflows to provide standard configs that could easily be selected by users.The text was updated successfully, but these errors were encountered: