support update of job begin-time
Problem: The begin-time dependencies of jobs can't be modified post-submission, though this seems like it would at least be possible to support an update callback for begin-time.
In general, dependencies can't be updated. I wonder if there's a more holistic way to enable updates of the dependencies section of jobspec.
Unfortunately job dependencies are not going to be easy to support with the current job update method.
The RFC 21 jobspec-update event uses a period-delimited key, e.g. attributes.system.duration, but this won't work well for job dependencies, which are specified in an array of scheme, value dependency objects (See RFC 26).
Dependencies are nominally requested in the same way, with a dotted path for the key. This triggers a job.update.KEY callback in the job manager to authorize the request, the updated jobspec is then optionally re-validated, then the update is posted to the eventlog (and thereby applied to jobspec).
We may need to special-case dependencies (and potentially other attribtues that do not fit the single-key model) somehow.
The first thing that went through my mind on this is we could use json patch formatted content. Jansson doesn't support it natively, but there are examples around the internet for supporting it with anything that has a json_pointer_set or similar. There are a number of tools that can work with or produce it, like a diff output for json in general, so it would likely end up useful other places too.
Yeah, this is pretty promising. We could have a new jobspec-patch event that supports this format possibly.
For updating a dependency, that json patch object could first delete the existing array member, then append a new one.
Currently, jobspec updates are allowed only if there is a jobtap plugin registered for job.update.KEY, where KEY is the location of the update. The update service in the job manager may need to offer some magic here to translate an update to, e.g. a begin-time dependency, into a job.update.dependency.begin-time callback which, if permitted by the plugin, then is reformed into a jobspec-patch event that deletes the correct array member and adds the permitted new begin-time.
I'd have to dig into the code for a bit to determine if this is a workable approach.
That sounds right, we could probably get away with a replace op for this one. Maybe allow updates to job.update.<json-patch-path-root> so you could do (I forget the exact path, but something like) job.update./attributes/dependencies to allow updates to it. Depending on how granular we want the control to be that might not be quite right but it would make it easy to allow updates to specific roots of the jobspec, or even restrict it to specific array members if we ever needed to.