Hi, 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 also added the new file staging attribute, and (even more important) deleted the crappy DRMAAv1 file transfer idea. So long, FileTransferMode enumeration ... Best, Peter.
2010/2/15 Peter Tröger <peter@troeger.eu>:
Hi,
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 masterMachine/slaveMachines in the JobInfo interface. I would suggest one of the following: 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). 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) In both cases we can request that the first host in list is the "masterMachine"
I also added the new file staging attribute, and (even more important) deleted the crappy DRMAAv1 file transfer idea. So long, FileTransferMode enumeration ...
Best, Peter.
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- Mariusz
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.
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
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.
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. 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@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
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#Managi... 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. 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@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Hi, 2010/3/15 Peter Tröger <peter@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#Managi...
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* reservation.
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@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- Mariusz
My conclusion of this discussion thread is that the current layout is ok. Reservation details, such as start and end time, are static attributes of the reservation instance. A ReservationSession allows to get the list of active reservations. Further filtering must be done by the application itself. Best, Peter. Am 15.03.2010 um 17:25 schrieb Mariusz Mamoński:
Hi,
2010/3/15 Peter Tröger <peter@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#Managi...
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* reservation.
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@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- Mariusz
participants (3)
-
Daniel Templeton -
Mariusz Mamoński -
Peter Tröger