[DRMAA-WG] Latest changes

Mariusz Mamoński mamonski at man.poznan.pl
Mon Mar 15 11:25:56 CDT 2010


2010/3/15 Peter Tröger <peter at troeger.eu>:
> Hi,
>> 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:
> http://wikis.sun.com/display/GridEngine/Managing+Advance+Reservations#ManagingAdvanceReservations-qrstat
> 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.
i also fully agree on this, in the previous e-mails i just insisted on
having some means to determine which hosts where allocated for *given*

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

Actually there is at least one DRM system that supports altering time
window of an existing reservation, so it could happen that
startTime/endTime had changed (if someone issued modify reservation
request outside the DRMAA), but this is, in my opinion, such kind of
situation that DRMAA is not obligated to handle correctly. However i
wish to emphasis that startTime/endTime although static may be
different from ones given in ReservationTemplate (e.g. if endTime -
startTime > duration)
> Peter.
>> Daniel
>> On 03/15/10 04:08, Peter Tröger wrote:
>>> Hi,
>>>> 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
>>>>> 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)
>>> 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.
>>> Best,
>>> Peter.
>>> --
>>>   drmaa-wg mailing list
>>>   drmaa-wg at ogf.org
>>>   http://www.ogf.org/mailman/listinfo/drmaa-wg
>> --
>>  drmaa-wg mailing list
>>  drmaa-wg at ogf.org
>>  http://www.ogf.org/mailman/listinfo/drmaa-wg
> --
>  drmaa-wg mailing list
>  drmaa-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/drmaa-wg


More information about the drmaa-wg mailing list