[DRMAA-WG] Latest changes
peter at troeger.eu
Mon Mar 15 10:59:38 CDT 2010
> The SGE qrstat command also just gives a list of the current
> reservations. The only filtering you can do is by user, not by host.
This page below shows me that you can fetch all AR's and then, per AR, fetch the list of allocated slots resp. hosts:
You cannot ask the DRM for all AR's on a machine, but you can figure it out programmatically by fetching all information for all AR's, right ? Sounds like a task for the application itself, not the library. In this case, returning a list of Reservation objects in DRMAA monitoring seems to be really enough.
We now need to decide if the Reservation interface members are really attributes (filled at object creation), or methods. In the latter case, the list of hosts would be fetched from the DRM if somebody asks for it. Things like startTime and endTime should be always static.
> On 03/15/10 04:08, Peter Tröger wrote:
>>> 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.
>> Ah, so this is not about getting the machines for a reservation, but
>> getting the reservation for a machine. I wonder of all DRM system
>> support this kind of machine-level monitoring information in an explicit
>> way, or if this is just derived information from the list of all
>> reservations in the system. In this case, we could just add
>> sequence<Reservation> activeReservations;
>> to the MonitoringSession interface. This allows for fetching all active
>> reservations in the DRM system. Each Reservation object then contains
>> the list of assigned hosts, and the application could derive the graph
>> you showed as example.
>> I found the "pbs_rstat" command as a good example for the command-line
>> equivalent of this API design.
>>>> The usedSlots attribute still seems to fit better in the
>>>> 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)
>> Completely agreed. I would vote for leaving that one out.
>>> maybe we should discuss it during the OGF. For me beauty is in simplicity.
>> Mee to. Let's clarify this on Wednesday in Munich.
>> drmaa-wg mailing list
>> drmaa-wg at ogf.org
> drmaa-wg mailing list
> drmaa-wg at ogf.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2208 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/drmaa-wg/attachments/20100315/e44652de/attachment.bin
More information about the drmaa-wg