[torquedev] [torqueusers] Resource attributes expected functionality using qsub

John Rosenquist jrosenquist at adaptivecomputing.com
Tue Mar 22 13:48:23 MDT 2011


Oops, html should now be turned off.


Thank you for the feedback.

 From what I can tell there are 7 possible entry points for job data.
1.) environment
2.) command line
3.) code logic
4.) static defaults in the code
5.) config file
6.) script
7.) pbs_filter

According to what I'm reading in the code, this is the order of priority 
in which the arguments are processed, with higher priority taking 
precedence over lower.

3 - code logic (This will take an existing value and modify it. For 
example, expanding a hostname to a FQDN)
2 - command line
7 - pbs_filter
6 - script
5 - config file
1 - environment
4 - static default

Does this also match the community expectation?

In terms of argument functionality, we've been talking about that and 
were thinking about modifications along the following lines.

If an identical flag is passed along the commandline in multiple 
locations, the job would be rejected. (Along the lines of the direct 
feedback)
After that, the list above would be followed, with pbs_filter having the 
ability to reject the job as well.

i.e. The following would generate errors.
1.) qsub -m fjr,jur,hud -m juk,kil,hud script.sh
2.) qsub -l nodes=3,mem=2Gb -l nodes=2 script.sh

1 would be rejected for two -m entries.
2 would be rejected for duplicate nodes entries.

But the follow would not be rejected.
qsub -l nodes=2 -l mem=2GB script.sh
As each entry in the resource set is unique.

As part of the debugging output the code would print out the list of job 
attributes and their sources before the pbs_submit call.

Based on the current usage in the community, how does this sound?


On 03/20/2011 07:47 PM, Gareth.Williams at csiro.au wrote:
>> The question is, if someone used this mixture of locations to add resource information (and/or had multiple duplicate -l flags on the command line), what it the current expected functionality?
>
> Hi and welcome John,
>
> I suspect the community would appreciate it if you could send plain text (rather than html) to the list - I know I would.
>
> The behaviour is broadly what I would expect. Later options over-ride earlier options and command line options override embedded options.  I've also worked with this behaviour in NEC's implementation of NQSII.
>
> It might be valuable to provide warnings when options are duplicated, perhaps with a further option to treat such conditions as errors.  After all, it is nice to get direct feedback in an error message rather than having to figure out later why things did not work as you hoped/expected.
>
> Cheers,
>
> Gareth
> _______________________________________________
> torquedev mailing list
> torquedev at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torquedev

-- 
John Rosenquist | Torque Developer
Direct Line: 801.717.3--- | Fax: 801.717.3738
1656 S. East Bay Blvd. Suite #300 | Provo, Utah 84601 | USA
Adaptive Computing, Ent.
File:Sig.png <File:Sig.png>



More information about the torquedev mailing list