flux-core icon indicating copy to clipboard operation
flux-core copied to clipboard

job-list: handle jobspec-update event

Open garlick opened this issue 3 years ago • 3 comments

Problem: Missing jobspec attributes may be filled in by the jobspec-update event, but job-list does not parse that event.

Edit: reference pr #4386

garlick avatar Jul 12 '22 15:07 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 of this automatically when the jobspec is fetched? E.g. return jobspec with the modifications applied?

garlick avatar Jul 12 '22 15:07 garlick

Oh, good thinking!

I had in the back of my mind that jobspec-update events would be for the instance only and would be ignored by the shell, though the default shell options use case is appealing. If we could do signed jobspec-update events, then this could be used by users to modify jobspec after submission, and in that case it would be nice if job-info could apply the updates so that a request for the jobspec would return the current version.

This reminds me, though, that we still need to address #2814

Edit: It may be obvious, but we should be clear that the reason the job shell might ignore jobspec-update events is that they invalidate the signed J submitted by the user. In an untrusted instance, we don't want the instance forcing the job shell to run something the user didn't authorize, so we shouldn't bake that into the design. Granted, at this point the job shell does fully trust the instance since it directly fetches jobspec and not J.

grondo avatar Jul 12 '22 16:07 grondo

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 or the job-manager. The original, signed jobspec would be retained in J unmodified.

In PR #4523, the job shell was modified to unwrap the original jobspec from J.

Then in #4520 it is proposed that we drop the environment from the jobspec stored in the KVS.

PR #4529 relocates the jobspec-default plugin to job-ingest.

So in summary, our design for jobspec defaults drifted a bit since this issue was opened and it is no longer urgent for that use case that we support the jobspec-update event in the tools. However, we should leave this issue open as we still may need jobspec-update for other user cases like #2799.

garlick avatar Sep 09 '22 21:09 garlick

Pinging this issue since we're looking into modifying a limited set of jobspec attributes post-submission. So I think the priority of this issue should be bumped up again.

grondo avatar Aug 12 '23 18:08 grondo

Hadn't thought about this issue in awhile, mostly b/c of the short/medium term need. But if need is super apparent given recent PRs, can obviously bump up.

chu11 avatar Aug 12 '23 20:08 chu11

The main use case for now is detailed in #4844

grondo avatar Aug 12 '23 22:08 grondo