[GE users] How to list possible queues

Reuti reuti at staff.uni-marburg.de
Tue Feb 15 13:39:46 GMT 2005


    [ The following text is in the "windows-1252" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

Hi,

for now "qstat -f" will use all queues and limit this list by the 
restrictions given. So the "qstat -f -l h=pml" will limit this list to 
queues having "h=pml" and the "build" queue(s) slip in.

What about doing it the other way round. Start with an empty list and 
get the suitable queues according to the resource request like for the 
qsub/qrsh.

To get the old behavior back, a switch "-a" (like "all", as you guessed) 
could be introduced, so "qstat -af" would be the current "qstat -f". 
When "-a" is given, no "-l" is allowed, because the output would be the 
(misleading) way we now have.

0.02? - Reuti


Andy Schwierskott wrote:
> Olle,
> 
> 
>> Andy Schwierskott wrote:
>>
>>>> 'qstat -f' will still list the build queue by default, which is 
>>>> confusing for the users. Adding '-l build=false' to the sge_qstat 
>>>> file will not work since the interpretation of conflicting resource 
>>>> requirements seems to differ between qsub and qstat. E.g. 'qsub -l 
>>>> build=false,build=true' will be equivalent to 'qsub -l build=true' 
>>>> while 'qstat -f -l build=false,build=true' will select the empty set.
>>>
>>>
>>>
>>> This is not a bug of the sge_qstat file - the same happens when you 
>>> do it in
>>> the command line:
>>>
>>>    qstat -f -l build=true,build=false
>>>
>>> or
>>>
>>>    qstat -f -l build=false,build=true
>>>
>>> always return en empty set.
>>>
>>> The same rules like for qsub need to apply.
>>>
>>> could you please file an IZ?
>>>
>>
>> I will file an IZ. Changing qstat might be a better idea than changing 
>> qsub, otherwise the possibility to override default parameters in the 
>> sge_request file will get lost. Or is it just me using this feature?
> 
> 
> The current behavior just makes no sense. With the new sge_qstat file in
> 6.0u2 this can become a practial limitation. Btw. there's a bug with
> "qselect" - "qselect" also reads reads the sge_qstat file - this is wrong
> according to the doc and is not a useful behavior. I will file an IZ for
> this.
> 
>>>> 2: Forced complex variables
>>>>
>>>> I define a forced boolean complex variable 'build' that is true for 
>>>> the build queue and undefined for the rest of the queues.
>>>>
>>>> qsub works fine.
>>>>
>>>> 'qstat -f -l build=true' will list the build queue only. 'qstat -f' 
>>>> will list all queues, including the build queue.
>>>
>>>
>>>
>>> yes, but's that's ok (or is there a setting in "sge_qstat" which 
>>> makes you
>>> expecting a different value?
>>
>>
>> The sge_qstat file is clean. If you say qstat is ok I will accept 
>> that, but I find it a bit weird. The build queue is not an option for 
>> the scheduler if it provides the forced resource 'build' and the 
>> resource is not requested. So why does qstat show this queue if the 
>> resource is not requested?
>>
>> Consider the following example. Given the output from qstat, it is 
>> hard to see why the first qrsh fails:
>>
>> % qstat -f -l h=pml
>> queuename                      qtype used/tot. load_avg arch          
>> states
>> ---------------------------------------------------------------------------- 
>>
>> build at portmoller.carmen.se     BIP   0/2       0.00     lx24-x86
>>
>> % qrsh -l h=pml hostname
>> Your "qrsh" request could not be scheduled, try again later.
>>
>> % qrsh -l h=pml,build hostname
>> portmoller
> 
> 
> Well, this a a valid point - I think we should get the opinion from other
> users and developers to come to a better conclusion.
> 
> Andy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list