[DRMAA-WG] Latest changes

[Mariusz Mamoński]

some more comments inline...

2010/3/9 Peter Tröger <peter at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReservationGui.png
Type: image/png
Size: 53488 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/drmaa-wg/attachments/20100309/fa89346b/attachment-0001.png