[gridengine users] qstat XML output: resource requests: submission time values vs qaltered values (GE 6.2u5)

[Reuti]

Hi,

Am 29.02.2012 um 03:31 schrieb Kevin Buckley:

> was recently trying to get some info from the XML output from a "qstat -j" and
> noticed that for two running jobs, the s_rt value that had been supplied in two
> different ways, appeared within two different "XPaths"
> 
> A job that had supplied the s_rt limit as a submission request sees
> the XML place the
> value at a "path" identifiable as
> 
> <detailed_job_info><djob_info><element><JB_hard_resource_list><qstat_l_requests><CE_name>s_rt
> 
> whereas a job which had had the s_rt limit added in, via a qalter
> whilst still in the queue, saw it turn up as
> 
> <detailed_job_info><djob_info><element><JB_hard_resource_list><element>CE_name>s_rt
> 
> I can see why the two would be different (because they are!) but, once
> I had discovered
> that there were two paths to the "same info", wondered if, once a job
> was running and
> so limits such as s_rt had become immutable, they would be better
> represented by the
> second form, ALONG with the first, if values had been specified that way.
> 
> Do the internal structures of the GE code maintain both "submitted"
> and "allocated" values,
> so that this might be possible ?

I would say no. There are some traces in the sources that it might be available later, but for now these are dummy entries:

   handler->job_handler.report_soft_resources_started = qstat_xml_dummy_started;
   handler->job_handler.report_soft_resource = qstat_xml_job_soft_resource;
   handler->job_handler.report_soft_resources_finished = qstat_xml_dummy_finished;

It's of course interesting, that by changing the request the name in the XML output changes. In the normal `qstat -j <job_id>` output an additional entry "version:" will reflect that there was a change.

The accouting file only records the last known values too.

If you want to have a way to check the original values: a JSV could copy the original supplied values into a job context (-ac ...). I don't know, whether this would be suitable for you, as the user could also change the values in the job context. And after the job the job context is gone too.

===

I use the job context to store some other stuff, and send it with the usual job email to the user by extending it in a email-wrapper. You could output in the email both: job context values (supposing they werent changed), and the last known values. Please let me know if you want to use it, as there are some pitfalls to note (mainly: the email is set after the job left the node already).

-- Reuti


> Kevin Buckley
> ECS, VUW, NZ.
> _______________________________________________
> users mailing list
> users at gridengine.org
> https://gridengine.org/mailman/listinfo/users