[Mauiusers] Multiple standing reservations with TASKCOUNT mutually exclude nodes from *all* users

[Wightman]

You are correct, our testing was not complete.  However, our testing in
Moab does show correct behavior (Moab 4.2.0).

Were you testing Moab 4.0.4 or Moab 4.2.0?  The fix was rolled into
4.2.0 but not into 4.0.4 (until today).  We have run several test cases
(including the one you sent in) and they all seem to work.  The behavior
is that if the SR cannot get exclusive access to the node then it will
not get any access.  It basically is 'first-come-first-served'.

Here's a sample test running on two nodes node01 and node02:

---
moab.cfg.
---

#################################
#EXCLUSIVE STANDING RESERVATIONS#
#################################

SRCFG[sr1] PERIOD=INFINITY
SRCFG[sr1] TASKCOUNT=1 FLAGS=SPACEFLEX
SRCFG[sr1] ACCESS=DEDICATED
SRCFG[sr1] USERLIST=user1

SRCFG[sr2] PERIOD=INFINITY
SRCFG[sr2] TASKCOUNT=1 FLAGS=SPACEFLEX
SRCFG[sr2] ACCESS=DEDICATED
SRCFG[sr2] USERLIST=user2

SRCFG[sr3] PERIOD=INFINITY
SRCFG[sr3] HOSTLIST=node01
SRCFG[sr3] ACCESS=DEDICATED
SRCFG[sr3] USERLIST=user2



----
showres -n
----

$ showres -n
reservations on Fri Sep 24 11:42:09

NodeName                   Type      ReservationID   JobState Task      
Start    Duration  StartTime

node02                       User            sr2.0.2        N/A    1  
-00:00:02    INFINITE  Fri Sep 24 11:42:07
node01                      User            sr1.0.1        N/A    1  
-00:00:02    INFINITE  Fri Sep 24 11:42:07



sr1 and sr2 claimed the nodes before sr3, so sr3 gets no rsv.


----
showres
----

$ showres

ReservationID       Type S       Start         End    Duration    N/P   
StartTime

sr1.0.1             User -   -00:00:25    INFINITY    INFINITY    1/2
Fri Sep 24 11:50:57
sr2.0.2             User -   -00:00:25    INFINITY    INFINITY    1/2
Fri Sep 24 11:50:57


Notice that sr3 does not have any reservation (because it could not get
exclusive access).


----
mdiag -r
----


$ mdiag -r
Diagnosing Reservations
RsvID                      Type Par   StartTime     EndTime     Duration
Node Task Proc
-----                      ---- ---   ---------     -------     --------
---- ---- ----
sr1.0.1                    User DEF   -00:00:27    INFINITY    
INFINITY    1    0 2
    Flags: STANDINGRSV SPACEFLEX DEDICATEDRESOURCE
    ACL:   USER==user1+
    CL:    RSV==sr1.0.3
    Task Resources: PROCS: [ALL]
    Active PH: 0.00/381.18 (0.00%)
    SRAttributes (TaskCount: 1  StartTime: 00:00:00  EndTime:
1:00:00:00  Days: ALL)
    Rsv-Group: sr1

sr2.0.2                    User DEF   -00:00:27    INFINITY    
INFINITY    1    0 2
    Flags: STANDINGRSV SPACEFLEX DEDICATEDRESOURCE
    ACL:   USER==user2+
    CL:    RSV==sr2.0.3
    Task Resources: PROCS: [ALL]
    Active PH: 0.00/381.18 (0.00%)
    SRAttributes (TaskCount: 1  StartTime: 00:00:00  EndTime:
1:00:00:00  Days: ALL)
    Rsv-Group: sr2


Active Reserved Processors: 0



----
mdiag -s
----

$ mdiag -s
evaluating standing reservations
RsvID                      Type  Par   StartTime     EndTime    
Duration     Period
-----                      ----  ---   ---------     -------    
--------     ------

sr1                        User NONE    00:00:00    00:00:00    
00:00:00   INFINITY
    ACL:   USER==user1+
    Owner:  USER==user1+
    RsvList:  sr1.0.1
    HostExp=''
    rsv sr1.0.3 created
    SR reservation sr1.0.3 is partial (TC: 1 requested/0 reserved)

sr2                        User NONE    00:00:00    00:00:00    
00:00:00   INFINITY
    ACL:   USER==user2+
    Owner:  USER==user2+
    RsvList:  sr2.0.2
    HostExp=''
    rsv sr2.0.3 created
    SR reservation sr2.0.3 is partial (TC: 1 requested/0 reserved)

sr3                        User NONE    00:00:00    00:00:00    
00:00:00   INFINITY
    ACL:   USER==user2+
    Owner:  USER==user2+
ALERT:  no child reservations detected
    HostExp='keiko'


Again, sr3 could not get exclusive access so no rsv;



We'll see what it would take to backport the solution to Maui.

Please let us know if the new snapshots of Moab do not fix the problem.

Thanks,


On Thu, 2004-09-23 at 23:03, Chris Samuel wrote:
> On Fri, 24 Sep 2004 04:48 am, Wightman wrote:
> 
> > There was a bug in Maui affecting the way "DEDICATED" got processed.
> > This has been fixed.  The latest snapshot should now fix this issue.
> > Please let us know if it does not.
> 
> No luck I'm afraid with maui-3.2.6p10-snap.1095963859.tar.gz
> 
> > The fix was also applied to Moab users, although the alternate method of
> > setting FLAGS=DEDICATEDRESOURCE was still functional.
> 
> Neither the latest Moab snapshot or using FLAGS=DEDICATEDRESOURCE helps, those 
> two example standing reservations both ended up on the same node as a 
> reservation with an explicit HOSTLIST. :-(
> 
> cheers,
> Chris
-- 
Douglas
Cluster Resources, INC.