-
Notifications
You must be signed in to change notification settings - Fork 49
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: get internal representation of jobspec #5411
Comments
As a side note, a similar treatment for R might be nice once we support |
So pondering this a bit more and I see multiple approaches:
No obvious winner, pros and cons each direction. Am leaning to just create a helper function that 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 |
Problem: Internally within flux, the jobspec can be updated through jobspec-update events. When the user runs "flux job info" to get the jobspec, it is getting the jobspec stored in the KVS and it may not represent what is actually used. In addition, the jobspec returned from "flux job info" will be inconsistent to the information returned from "flux jobs". Solution: When retrieving the jobspec, also retrieve the job eventlog. Internally update the jobspec through "jobspec-update" events and output the final result to give the user a representation of what the jobspec looks like within flux. Add a --noupdate option to perform the old behavior, which is to just get the jobspec stored in the KVS. Fixes flux-framework#5411
Problem: Internally within flux, the jobspec can be updated through jobspec-update events. When the user runs "flux job info" to get the jobspec, it is getting the jobspec stored in the KVS and it may not represent what is actually used. In addition, the jobspec returned from "flux job info" will be inconsistent to the information returned from "flux jobs". Solution: When retrieving the jobspec, also retrieve the job eventlog. Internally update the jobspec through "jobspec-update" events and output the final result to give the user a representation of what the jobspec looks like within flux. Add a --base option to perform the old behavior, which is to just get the jobspec stored in the KVS. Fixes flux-framework#5411
Problem: Internally within flux, the jobspec can be updated through jobspec-update events. When the user runs "flux job info" to get the jobspec, it is getting the jobspec stored in the KVS and it may not represent what is actually used. In addition, the jobspec returned from "flux job info" will be inconsistent to the information returned from "flux jobs". Solution: When retrieving the jobspec, also retrieve the job eventlog. Internally update the jobspec through "jobspec-update" events and output the final result to give the user a representation of what the jobspec looks like within flux. Add a --base option to perform the old behavior, which is to just get the jobspec stored in the KVS. Fixes flux-framework#5411
Problem: Internally within flux, the jobspec can be updated through jobspec-update events. When the user runs "flux job info" to get the jobspec, it is getting the jobspec stored in the KVS and it may not represent what is actually used. In addition, the jobspec returned from "flux job info" will be inconsistent to the information returned from "flux jobs". Solution: When retrieving the jobspec, also retrieve the job eventlog. Internally update the jobspec through "jobspec-update" events and output the final result to give the user a representation of what the jobspec looks like within flux. Add a --base option to perform the old behavior, which is to just get the jobspec stored in the KVS. Fixes flux-framework#5411
flux job info <JOBID> jobspec
gets the jobspec from the KVS, but this may not be the jobspec used internally by thejob-manager
or is represented insidejob-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 ofjobspec
givenjobspec-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, asjobspec-update
events are sent to it via the journal. We probably don't want to create a service to retrieve the internal jobspec fromjob-manager
.Edit: I guess
job-info
could build the proper representation ofjobspec
since it has to readeventlog
for a security check anyways.The text was updated successfully, but these errors were encountered: