Bug 732528

Summary: Would like a way to produce GlobalJobId (classad) value from aviary JobID type [RFE]
Product: Red Hat Enterprise MRG Reporter: Trevor McKay <tmckay>
Component: condor-aviaryAssignee: Pete MacKinnon <pmackinn>
Status: CLOSED WONTFIX QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 2.0CC: matt, mkudlej
Target Milestone: 2.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-12 15:28:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Trevor McKay 2011-08-22 19:40:29 UTC 
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.
Comment 1 Trevor McKay 2011-09-09 15:17:30 UTC 
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.
Comment 2 Trevor McKay 2011-09-12 15:28:52 UTC 
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.