Opened 14 years ago
Last modified 10 years ago
#382 new enhancement
IZ2113: qselect not useful if forced variables are used
Reported by: | olle | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | sge | Version: | 6.0u8 |
Severity: | Keywords: | clients | |
Cc: |
Description
[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.
Note: See
TracTickets for help on using
tickets.