Hide Forgot
Description of problem: The GlobalJobId field is available in a JobDetails record because it's in the classad but it would be nice if it were easily available from a JobID type. This would make GlobalJobId uniformly accessible from a variety of Aviary response messages. There is almost enough information in a JobID currently to produce the GlobalJobID; the only thing missing is the QDate (classad) value. QDate could be added, and the value synthesized by the receiver (scheduler+#job_id+#queuedate) or perhaps the GlobalJobId string itself could be constructed and added into the JobID type.
Note, currently cumin is thusly synthesizing the GlobalJobId field on a job summary returned from Aviary via GetSubmissionSummary with "includeJobSummaries" set: j["GlobalJobId"] = job.id.scheduler + \ "#" + job.id.job + \ "#" + str(to_int_seconds(job.queued)) The values are all contained within the job summary object, so it is self-consistent. The (small?) worry here is that cumin is synthesizing an id using explicit knowledge of how condor would construct that id -- not great practice. It would be better if the id was provided by condor and cumin was a simple consumer. So, it works, not a blocking issue, but there may be a vulnerability here. Prioritize accordingly.
It was decided Cumin doesn't really need this. Qdate has been removed from the job id value on the "Jobs" tab when Aviary is used, job id is now scheduler#cluster.proc.