[DRMAA-WG] Latest changes

[Peter Tröger]

>> 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 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.

> 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 ?

> 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.

Best,
Peter.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/drmaa-wg/attachments/20100309/753f1472/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2208 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/drmaa-wg/attachments/20100309/753f1472/attachment.bin