-
Notifications
You must be signed in to change notification settings - Fork 51
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-info: add JSON_DECODE & CURRENT flags, deprecate job-info.update-lookup #5633
job-info: add JSON_DECODE & CURRENT flags, deprecate job-info.update-lookup #5633
Conversation
9b3e62a
to
51c5ccd
Compare
hmmm, should I have used the term "UPDATED" vs "UPDATE" as the flag? UPDATE may imply "to update" vs "UPDATED" is "updates have been applied". |
Instead of update(d), maybe "current"? |
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.
First pass with some comments inline.
Also: we just added job-info.update-lookup
in 0.56. Would it be reasonable to just update users and remove or were you thinking that's another PR?
src/common/libjob/job.h
Outdated
enum job_lookup_flags { | ||
/* decode special fields | ||
* - for jobspec and R, value of response will be decoded (i.e. a | ||
* json object) instead of a string. | ||
*/ | ||
FLUX_JOB_LOOKUP_DECODE = 1, | ||
}; |
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 probably shouldn't be in the public header since there are no API functions that accept this flag.
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.
hmmm. Good point, but it is useful to have around instead of hard coding. Could add a private helper header, but I'm not sure the python bindings can use it if it's a non-public header?
src/modules/job-info/lookup.c
Outdated
if (json_object_set_new (o, keystr, str) < 0) { | ||
json_decref (str); | ||
if (json_object_set_new (o, keystr, val) < 0) { | ||
json_decref (o); |
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.
That should be json_decref (val)
.
src/common/libjob/job.h
Outdated
* - for jobspec and R, value of response will include updates | ||
* from the eventlog | ||
*/ | ||
FLUX_JOB_LOOKUP_UPDATE = 2, |
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.
same comment as before - inappropriate in installed header?
src/modules/job-info/lookup.c
Outdated
if (!(updated_str = json_dumps (update_object, 0))) | ||
goto error; |
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.
Since the updated object may have to be converted back to an object again depending on flags, maybe it would make sense to return this as an object instead of converting it to a string here?
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.
considered this, it is mildly annoying to return the object given the JSON_DECODE logic that later follows in the caller. I'll add as a fixup commit, lemme know what you think.
src/modules/job-info/lookup.c
Outdated
if (flux_msg_get_rolemask (l->msg, &rolemask) < 0) | ||
return -1; | ||
|
||
/* if rpc from owner, no need to do guest access check */ | ||
if (rolemask & FLUX_ROLE_OWNER) { | ||
l->allow = true; | ||
return 0; |
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.
Maybe this would be a bit simpler as
if (flux_msg_authorize (l->msg, FLUX_USERID_UNKNOWN) == 0) {
l->allow = true;
return 0;
}
src/modules/job-info/lookup.c
Outdated
if (!l->allow || (l->flags & FLUX_JOB_LOOKUP_UPDATE)) { | ||
size_t index; | ||
json_t *key; | ||
json_array_foreach(l->keys, index, key) { |
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.
add space before open paren
src/modules/job-info/lookup.c
Outdated
const char *keystr; | ||
if (!(keystr = json_string_value (key))) { | ||
errno = EINVAL; | ||
return -1; | ||
} | ||
if (streq (keystr, "eventlog")) | ||
return 0; | ||
} |
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.
It would probably be good to check that the request keys
is an array of strings right in the request handler rather than deeper in the code, for clarity and to avoid repeating the same check in several places. Then this could just be:
if (streq (json_string_value (key), "eventlog"))
return 0;
51c5ccd
to
8571c40
Compare
8571c40
to
7e77cc8
Compare
re-pushed going with JSON_DECODE and CURRENT as the flag names. |
7e77cc8
to
7cd0142
Compare
re-pushed with tweaks per comments above. There's one fixup patch that adds an update that I'm a little meh on, so I left it as a fixup for the time being so it can be reviewed as a "consideration". |
7cd0142
to
a421501
Compare
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.
I realized we should probably have merged this one before I split up flux-job.c
, so giving this a review now (and sorry this languished so long!).
My one thought is that unfortunately the job-info.update-lookup
RPC made it into released versions of flux-core, so we have to be careful about switching flux job
and other users to the new flags in case a newer flux-core is used with an older. For flux-job
however, I don't know how likely it is that there would be an issue so maybe it is fine?
* updates for those fields | ||
* - currently works for jobspec and R | ||
*/ | ||
FLUX_JOB_LOOKUP_CURRENT = 2, |
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.
A question about this commit. The comment here indicates "works for jobspec and R" but I only see R handled specifically in lookup_current
. Maybe a comment in lookup_current
as to why jobspec is not handled there would be helpful.
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.
ahh comment is probably a development history mistake, see #5635
"flags", 0)) | ||
|| flux_rpc_get_unpack (f, "{s:o}", key, &o) < 0) | ||
"keys", key, | ||
"flags", FLUX_JOB_LOOKUP_CURRENT)) |
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.
Use of this flag requires a current version of flux-core. I'm not sure if it is worth it, but should this call fall back to update-lookup
if the RPC returns EPROTO
?
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.
ugh, It ends up I didn't check "flags" in older versions b/c flags wasn't used. So I guess a caller would just get the original version.
Could just keep on calling job-info.update-lookup
? But I'm not sure the pros of that outweigh the cons. I figure most users, if they are using flux job info
, base R == updated R anyways?
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.
I figure most users, if they are using flux job info, base R == updated R anyways?
Yes, there will be an updated R only if the expiration is adjusted, which is going to pretty rare. Also, the command would have to be run against a downrev parent instance to hit the failure, and at least this would be a failure I think instead of returning wrong information. So perhaps we just keep things as is and hope for the best? Over time it won't be a problem anymore... (However, something to keep in mind when adding future interfaces)
src/modules/job-info/lookup.c
Outdated
goto error; | ||
s = current_value; | ||
/* tiny optimization, to skip unnecessary json_dumps() and | ||
* fallthrough to code below |
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.
I'd be fine dropping this optimization for now and only address performance if it becomes an issue.
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.
Given the discussion about the flux job info
change, this can probably go in as is when the fixup commit is dropped.
Problem: Some tabbing was invalid in t2233-job-info-update.t. Make tabbing consistent.
Problem: The test utility job-info/info_lookup includes a header that is unused. Remove the unused header.
Problem: Some extraneous extra spaces exist after some function parameters. Remove the extraneous extra spaces.
Problem: The internal variable "check_eventlog" is confusing because it only means to "lookup" the eventlog. Rename variable to lookup_eventlog.
Problem: Several calls to json_array_foreach are missing a space between it and the open parenthesis. This is likely a cut and paste error. Add the extra spaces.
Problem: The job-info.lookup target does not check for invalid flags. Add check for invalid flags.
Problem: Throughout lookup code there are checks if the values within the keys array are strings. It would be simpler if this check was only done once. Check that the keys array is an array and contains only strings within the primary lookup callback.
Problem: Several bad input cases are not tested agains the job-info.lookup RPC target. Add coverage in t2230-job-info-lookup.t.
Problem: On disconnect, cleaning up update-lookups was forgotten. Add cleanup update_lookups via a new update_lookup_cleanup() function.
Problem: It can be inconvenient to lookup a key and always have to convert it to a json object / python dictionary (such as a jobspec or R). Solution: Support a new FLUX_JOB_LOOKUP_JSON_DECODE flag that will treat some special keys (currently jobspec and R) as special lookups and will returned the values as decoded JSON objects instead of strings.
Problem: There is no coverage for the new job info lookup JSON_DECODE flag. Add coverage to t2230-job-info-lookup.t and add a --json-decode flag to the utility test tool job-info/info_lookup.
Problem: It is inconvenient that there is a job-info.lookup target and job-info.update-lookup target. Support the behavior of job-info.update-lookup in job-info.lookup via a new FLUX_JOB_LOOKUP_CURRENT flag.
Problem: Now that the job-info.lookup target takes the DECODE and CURRENT flags, it can behave just like the job-info.update-lookup target. Deprecate the job-info.update-lookup RPC target by simply having it call the job-info.lookup code path with the DECODE and CURRENT flags.
Problem: There is no coverage for the job-info.lookup RPC's new CURRENT flag. Add coverage in t2233-job-info-update.t.
Problem: The job-info.update-lookup RPC target has been deprecated. It would be wise to note this in some legacy tests. Add note in t/job-info/update_lookup.c.
Problem: The job-info.update-lookup target is being deprecated over the job-info.lookup target w/ the CURRENT flag. The "flux job info" command uses the job-info.update-lookup target. Update to use job-info.lookup over job-info.update-lookup. Fallback to job-info.update-lookup if necessary.
a421501
to
cf89676
Compare
just re-pushed. apologies, i began cleaning up more thinking that the split of
this PR is getting long, could split it up? |
Since splitting up If you want to split this into a separate PR that is fine with me. Thinking about each PR as a "release note entry" though, what would that be? |
It'd just be a "cleanup" PR, so I guess nothing useful. Only offering to split up if it would make reviewing easier ... but I now see that you approved the PR pre-my recent changes. So I guess that doesn't matter as much now :-) |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #5633 +/- ##
========================================
Coverage 83.48% 83.49%
========================================
Files 488 488
Lines 83310 83421 +111
========================================
+ Hits 69552 69652 +100
- Misses 13758 13769 +11
|
This PR could be split up a bit more, but for now it's one PR.
This adds several new lookup flags, and with their addition, the
job-info.update-lookup
RPC target can be deprecated.The one "tricky" part was how to grab cached data from current
update-watch
es being done. Perhaps the lookup of that "cached" info could just be dropped as it probably has minimal use.I decided to not support
job-info.update-watch
within the originaljob-info.lookup
RPC for several reasons. Most notably becauselookup
can take multiple keys as input andjob-info.update-watch
takes only one key. I could make it so a WATCH flag only works with one key. Or we could have a "re-direct to this RPC" like we do with KVS watch. But I didn't delve too much into this design yet.I then updated PR #5592 to be based on this PR.PR #5635 then follows this one upTODO RFC spec 41 which I was going to hold off on until this gets some minimal review.