-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
job-list: support jobspec-update event #5408
job-list: support jobspec-update event #5408
Conversation
Actually might be nice to have this merged so the #4844 implementation could be more easily tested (afaik, there's no way to fetch the redacted jobspec via an RPC at this point). So, I'll try to review this and predecessor sooner rather than later. |
Problem: The internal processing of job data uses a list of "state transition" structs to manage the reading/updating of job data throughout a job's lifecycle. Presently, this is the only way that job data can be updated/changed. In the future, job data can be updated through other means such as the "jobspec-update" event. The current "state transition" struct doesn't support these other means. Solution: Refactor the "state transition" structs to be more flexible for other job data update mechanisms. Rename "struct state_transition" to "struct job_update" and add a type field indicating what type of update is occurring. Currently "state transitions" are the only supported update type. Update all functions and related variables for this change. Most notably the "next_states" list is now "updates" and the "st" variable is now "updt" everywhere.
Problem: In the near future we may need to parse the jobspec tasks list multiple times. Even though it can never be altered, it would be parsed multiple times from the jobspec. Cache the jobspec tasks list in the job data structure.
Problem: In the near future, the jobspec attributes dictionary may need to be parsed multiple times. The jobspec attributes parsing currently sits in a function that is called only when the jobspec is initially loaded. Split out the jobspec attributes parsing into a new internal function.
Problem: In the near future we would like to update the jobspec with new information. Add a new helper function job_jobspec_update() to update the jobspec. Also add an optional "updates" object to job_parse_jobspec() that will add those updates to the jobspec that has just been parsed. Add unit tests.
Problem: In the near future jobs may be able to move from one queue to another. There is no way to adjust queue specific stats when this happens. Support a new stats function job_stats_remove_queue(). Along with job_stats_add_queue(), stats can be migrated from one queue to another when the queue changes.
Problem: jobspec-update events will allow users to update the internally viewed jobspec. Job-list does not handle these events and therefore the jobspec data returned by job-list may not represent what is used by the job-manager and other parts of flux. Support the jobspec-update event in job-list. Fixes flux-framework#4404
Problem: There is no coverage to ensure the job-list module handles jobspec-update events. Add coverage in t2260-job-list.t.
858d632
to
a5c6c88
Compare
Codecov Report
@@ Coverage Diff @@
## master #5408 +/- ##
=======================================
Coverage 83.55% 83.55%
=======================================
Files 470 470
Lines 78582 78669 +87
=======================================
+ Hits 65657 65734 +77
- Misses 12925 12935 +10
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good to me! Nothing stood out and I tested it along with my WIP job update service and everything seemed to just work. 👍
Per #4404, built on top of #5407
There were some tricky parts that took me awhile to refactor through, but overall, the commit series shouldn't look too strange.
I didn't list this as WIP as I think this could go in as is. But perhaps we want to wait until work on #4844 is further along so we can test in tandem??