some more comments inline... 2010/3/9 Peter Tröger <peter@troeger.eu>:
the advanced reservation proposal from Mariusz is now part of the DRMAAv2 spec draft:
http://wikis.sun.com/display/DRMAAv2/DRMAAv2+API
I only omitted the separate ReservationInfo interface - the machine specific part (such as used slot count) became part of the (anyway existing) MachineMonitoring interface.
I will insist on keeping this information part of the ReservationInfo
interface. User (or other consuming system) may wish to know which exactly hosts were reserved (with information how many slots/processes were reserved on given host). This is similar concept to the
This is already possible with the actual approach - however, you need to open a separate monitoring session to get the information. I understand your i should said "wish to know which exactly hosts were reserved FOR GIVEN RESERVATION" (e.g. i have attached screenshot of one of our application that provides such information to users - we found it very useful). With monitoring session approach it would be impossible (please correct me if i'm wrong) to determine which resrvation/user occupies particular machine.
argument in the way that people ALWAYS want to have the reservation for each single host, whenever they perform an advanced reservation. So let's adopt your original proposal, by defining a new value type and put a sequence of it as attribute into the Reservation structure: valuetype ReservedHost { string machineName; long reservedSlots; }
interface Reservation { readonly attribute string reservationId; readonly attribute sequence <ReservedHost> reservedHosts; readonly attribute long startTime; readonly attribute long endTime; readonly attribute string comment; void terminate(); };
The usedSlots attribute still seems to fit better in the MonitoringSession interface. I would expect to have all information in the Reservation interface to be available before the first job starts, which is not the case for usedSlots. We can fight about making usedSlots a part of JobInfo. Actually for me usedSlots is not a vital information (user should be able in most cases determine this by counting how many jobs it has already submitted into this reservation)
1. define interface AllocatedHostInfo with two attributes machineName (String) numberOfProc (long) and use it in the executionMachines (aggregation of masterMachine/slaveMachine) in JobInfo interface and in the reservedMachines (part of the ReservationInfo interface).
This somehow implies that the list of allocated hosts can change after job submission. Isn't this supposed to be static from the point of successful reservation ? let me clarify on this by showing 3 example scenario:
1.: user submits a parallel job requesting 12 slots (procs). No candidate hosts were given so the DRMS allocate appropriate hosts, e.g.: 4 procs on hostA, 8 procs on hostB. This information is usually available upon job startup not submission. 2.: user creates an advance reservation for 12 slots, No candidate hosts were given so the DRMS reserve free hosts that matches the other user criteria. 3.: user submits a parallel job into the previously created reservation: here we have again to possibilities: a) the job requests all resources reserved (12 procs) - then the execution hosts would be identical with reserved hosts b) the job requests part of the reserved resources (e.g. 4 procs) - then the execution hosts would be a subset of reserved hosts. My idea was simply to have one type for ReservedHost and ExecutionHosts (i.e. masterMachine/slaveMachines in the current draft)
2. keep the executionMachines and reservedMachines as simple ordered String list and repeat each hostname as many times as number of procs allocated on each host (so we have something similar to plain machinefile known from MPI)
I think we can do better than this, since we anyway started with an OO-like description.
maybe we should discuss it during the OGF. For me beauty is in simplicity.
Best, Peter.
Cheers, -- Mariusz
