job-info: get internal representation of jobspec

[chu11]

flux job info <JOBID> jobspec gets the jobspec from the KVS, but this may not be the jobspec used internally by the job-manager or is represented inside job-list.

The jobspec can be updated via jobtap plugins (perhaps adding defaults) or users can update via the future flux update command #5409.

It would be useful if flux job info <JOBID> jobspec got the presently used / represented jobspec.

Perhaps a --kvs option could be used to get what is in the KVS, similar to the --original option (and add to the Python equivalent convenience functions).

Also, an API mechanism to get this would be useful, as the flux-update command could use such a convenience function.

Implementation note: job-list already builds an internal representation of jobspec given jobspec-update events in the eventlog. It could be used to retrieve the internal representation of a jobspec. The only minor downside is that it can be racy, as jobspec-update events are sent to it via the journal. We probably don't want to create a service to retrieve the internal jobspec from job-manager.

Edit: I guess job-info could build the proper representation of jobspec since it has to read eventlog for a security check anyways.

[grondo]

As a side note, a similar treatment for R might be nice once we support resource-update events, so that flux job info JOBID R returns any updated expiration at the time of the request.

[chu11]

So pondering this a bit more and I see multiple approaches:

• get the redacted jobspec via job-list

  • Pro: it's already in there
  • Con: we don't have guest access check in there
  • Con: minor eventual consistency raciness

• get the redacted jobspec via job-info

  • Pro: guest access checks already there
  • Pro: we already have to read the eventlog for guest access, so no extra KVS reads
  • Con: gotta build the jobspec up, putting cycles on job-info in broker

• get the redacted jobspec via job-manager

  • Pro: it's already there
  • Con: we gotta support some user facing service thingie to get it from here along w/ access checks

• create library util functions to do this for job-info / tools so we atleast have it in one place

  • Pro: no extra load on broker
  • Con: more work

No obvious winner, pros and cons each direction. Am leaning to just create a helper function that flux job info and flux update and anything in the future can all use, since it doesn't appear we need widespread use at the moment.

Edit: Thinking about this even more I'm thinking of being even lazier. Perhaps until there's a need, we should just implement something into flux job info just for flux job info. A utility function in the future can be created when needed. flux job info has the C implementation and flux update has the Python implementation for the time being.