Use GlobalJobId as unique job identifier

[drebatto]

Instead of making up a custom LRMS job identifier, use the Condor-defined GlobalJobId.
This doesn't introduce arbitrary convention on the JobId format.
It also allows using the field directly in condor_history constraints.

[brianhlin]

Hi @drebatto thanks for the contribution! I'll have to admit that I'm not familiar with all of the APEL accounting rules. Are # characters valid in APEL records? Also, IIRC, the blah lrmsID needs to match the batch job ID to create the combined APEL record so I think you'd need to make a similar change to condor_blah.sh

[maxfischer2781]

The same ID is generated in condor_blah.sh indeed:

htcondor-ce/contrib/apelscripts/condor_blah.sh

Lines 42 to 43 in 1b3cec2

	-format "\"lrmsID=%v" clusterId \
	-format ".%v_${BATCH_HOST}\" " ProcId \

Both need to match, since APEL joins based on these:

    INNER JOIN BlahdRecords ON BlahdRecords.ValidFrom <= EventRecords.EndTime AND
                             BlahdRecords.ValidUntil > EventRecords.EndTime AND
                             EventRecords.SiteID = BlahdRecords.SiteID AND EventRecords.JobName = BlahdRecords.LrmsId
                             AND SpecRecords.SiteID = BlahdRecords.SiteID AND SpecRecords.CEID = BlahdRecords.CEID

[drebatto]

Yes, you are right. I modified condor_blah.sh too.
By the way, I implemented this patch because this is how we accounted for jobs with CREAM in the last six or seven years, and I wanted historical data to look consistent. For the same reason, I'll understand if you don't want to merge the patch and change the job id format for existing instances.

[maxfischer2781]

I think this is a good change, even if it conflicts with the earlier format. The current format is not unique if a machine is re-installed, thereby resetting the clusterId counter. Since the GlobalJobId includes the QDate, it stays unique in this case.

[brianhlin]

LGTM, thanks!