IZ2113: qselect not useful if forced variables are used

[olle]

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=2113]

        Issue #:      2113             Platform:     All           Reporter: olle (olle)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.0u8            CC:    None defined
        Status:       STARTED          Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     roland
          URL:
       * Summary:     qselect not useful if forced variables are used
   Status whiteboard:
      Attachments:

     Issue 2113 blocks:
   Votes for issue 2113:


   Opened: Fri Nov 17 06:05:00 -0700 2006 
------------------------


The users must have a way to list the queues that potentially could run
their jobs. qselect is not regarding the special meaning of forced variables
and is thefore not much help when forced variables are used in a cluster.

I consider this to be a bug in qselect that needs to be fixed.


In the following example I would not expect the message:
"Your "qrsh" request could not be scheduled, try again later."


1. Define f1 and f2 as forced complex variables:
f1 f1 BOOL == FORCED NO FALSE 0
f2 f2 BOOL == FORCED NO FALSE 0


2. Create queues q1, q2, q3, ... and assign some variable settings
% qconf -aattr queue complex_values f1=true q2
% qconf -aattr queue complex_values f1=false q3
% qconf -aattr queue complex_values f2=true q4
% qconf -aattr queue complex_values f2=false q5
% qconf -aattr queue complex_values f1=false,f2=false q6
% qconf -aattr queue complex_values f1=false,f2=true q7
% qconf -aattr queue complex_values f1=true,f2=false q8
% qconf -aattr queue complex_values f1=true,f2=true q9


3. Use qselect to find queues and submit a job to each found queue:

% for q in `qselect -l f1=true`; do qrsh -l f1=true -q $q echo \$QUEUE; done
q2
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.


% for q in `qselect`; do qrsh -q $q echo \$QUEUE; done
q1
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.
Your "qrsh" request could not be scheduled, try again later.

   ------- Additional comments from roland Mon Nov 20 05:01:38 -0700 2006 -------
I consider this also as a bug

   ------- Additional comments from ernst Thu Dec 21 06:43:35 -0700 2006 -------
Due to discussions with Roland, Joachim, Andreas and Andy
this is more an enhancement than a bug:

A fix of this this misbehaviour should be introduced in
sge_select_queue() so that forced attributes will receive
attention. This would not only change the behaviour of qselect but also
qstat and qhost where this is not wanted.

In priciple there are 2 different scenarios what a user might do with
such a -l selection:

Either resources should be filtered for the output or possible locations
should be identified where a certain job should run.

This applies to all 3 client commands. Therefore the user should be
able to select the wanted behaviour. This is not possible in the moment
and whould only be possible if additional switched would be introduced.

Therefore I change the issue type to RFE.