Jim Garlick

Related: the shell fetches the jobspec directly but not the eventlog, yet `jobspec-update` events could be posted for things the shell should parse, like shell options. Should `job-info` take care...

Over in #4494 we came to the conclusion that, at least for the current need of assigning jobspec defaults, we would modify the jobspec before it lands in the KVS...

Should we think about a multi-phase shutdown sequence for Flux that ensure that new perilogs don't start and allows running ones to finish under a timeout? Maybe related to #3895?

> a python program that enables configurable notification for jobs. This may be a good candidate for an independent framework project? Also, it would be nice if it could be...

The eventlog update is a great idea!

I tend to like 3, if you think that would fly. Coupling the run parameters to the script with pragmas encourages making a copy of the script each time parameters...

We can almost do that now with ``` $ flux mini batch -N2 -n4 --dry-run myscript >myscript.json $ flux job submit myscript.json ``` `myscript.json` is the full jobspec in JSON...

Although a user can access R and jobspec now using `flux job info`, it seems sort of appealing to me to have the rank 0 job shell place a copy...

OK then, my vote would be for your original argparse fromfile suggestion over script pragmas, as that avoids the coupling concern I mentioned earlier. That wouldn't necessarily preclude dumping out...

While those pragmas have always seemed "wrong", the argument against them feels academic at this point. Given all the other actual problems we have to solve and the relative simplicity...