[DRMAA-WG] other IDL issues

[Daniel Gruber]

Hi all,

I've following findings:

* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
source code portability requires it.

* latex format error in line 364

* 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations
accessible for the user running the DRMAA-based application."

Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible"
is a better wording.

* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments).
Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate
this is made *very* explicit, that one might need request a job category this is not mentioned
in the ReservationTemplate. Therefore I propose to add

string JobCategory;

in the ReservationTemplate in order to be consistent with the multiple slots request
approach. The JobCategory in the spec could be renamed to Category if needed.

Anyhow it would be good to add multiple category strings - but this is going to be an
implementation specific enhancement if needed.

Cheers,

Daniel

[Mariusz Mamoński]

Post by Daniel Gruber
Hi all,
* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
?source code portability requires it.
* latex format error in line 364
* 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations
?accessible for the user running the DRMAA-based application."
?Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible"
?is a better wording.
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments).
?Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate
?this is made *very* explicit, that one might need request a job category this is not mentioned
?in the ReservationTemplate. Therefore I propose to add
? ? ?string JobCategory;
?in the ReservationTemplate in order to be consistent with the multiple slots request
?approach. The JobCategory in the spec could be renamed to Category if needed.

this is fine with me, but lets call it ReservationCategory or
Category, not JobCategory.

Post by Daniel Gruber
?Anyhow it would be good to add multiple category strings - but this is going to be an
?implementation specific enhancement if needed.

i'm not sure if i understood you correctly but i don't think that any
implementation can change this attribute from scalar to vector, as
this would brake binary compatibility. We should decide globally if we
want the jobCategory to be string or vector of strings.

Post by Daniel Gruber
Cheers,
Daniel
--
?drmaa-wg mailing list
?drmaa-wg at ogf.org
?http://www.ogf.org/mailman/listinfo/drmaa-wg

Cheers,

[Daniel Gruber]

Post by Mariusz Mamoński

Post by Daniel Gruber
Hi all,
* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
source code portability requires it.
* latex format error in line 364
* 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations
accessible for the user running the DRMAA-based application."
Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible"
is a better wording.
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments).
Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate
this is made *very* explicit, that one might need request a job category this is not mentioned
in the ReservationTemplate. Therefore I propose to add
string JobCategory;
in the ReservationTemplate in order to be consistent with the multiple slots request
approach. The JobCategory in the spec could be renamed to Category if needed.

this is fine with me, but lets call it ReservationCategory or
Category, not JobCategory.

I also thought on ReservationCategory but this needs to add it as a different
new concept in the spec and also requires new functions (for retrieving
all ReservationCategories).

Since both (ReservationCategory and JobCategory) are just strings and in
Univa Grid Engine for example both categories maps to the same concept
(additional resource requests, which are appended). I would rather change
"JobCategory" to "Category" as a generic category name for job or reservation
requests.

Post by Mariusz Mamoński

Post by Daniel Gruber
Anyhow it would be good to add multiple category strings - but this is going to be an
implementation specific enhancement if needed.

i'm not sure if i understood you correctly but i don't think that any
implementation can change this attribute from scalar to vector, as
this would brake binary compatibility. We should decide globally if we
want the jobCategory to be string or vector of strings.

No, not changing the method itself. I thought about introducing a completely
new implementation specific function, which is not aligned to the standard.

I think we already discussed adding a vector type but I AFAIR it was rejected
because we then have to handle mutually problems like exclusive resource
requests. But for simplicity one way would be the make this again transparent
for the standard (i.e. how merging of resource requests is done, it up to the
DRMAA implementation).

Cheers,

Daniel

Post by Mariusz Mamoński

Post by Daniel Gruber
Cheers,
Daniel
--
drmaa-wg mailing list
drmaa-wg at ogf.org
http://www.ogf.org/mailman/listinfo/drmaa-wg

Cheers,
--
Mariusz

[Peter Tröger]

Post by Daniel Gruber

Post by Mariusz Mamoński

Post by Daniel Gruber
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments).
Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate
this is made *very* explicit, that one might need request a job category this is not mentioned
in the ReservationTemplate. Therefore I propose to add
string JobCategory;
in the ReservationTemplate in order to be consistent with the multiple slots request
approach. The JobCategory in the spec could be renamed to Category if needed.

this is fine with me, but lets call it ReservationCategory or
Category, not JobCategory.

I also thought on ReservationCategory but this needs to add it as a different
new concept in the spec and also requires new functions (for retrieving
all ReservationCategories).
Since both (ReservationCategory and JobCategory) are just strings and in
Univa Grid Engine for example both categories maps to the same concept
(additional resource requests, which are appended). I would rather change
"JobCategory" to "Category" as a generic category name for job or reservation
requests.

Since this one of the rare events were Mariusz, Daniel and me (a group majority) agrees on something, I will just do it like this.

Best regards,
Peter.

[Andre Merzky]

Hi Daniel,

Post by Daniel Gruber
Hi all,
* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
?source code portability requires it.

The spec leaves many things to the implementation - I don't think all
those degrees of freedom should be exposed for inspection, as
capabilities. That will quickly grow and becom unwieldy. For
example, optional fdeatures are: struct serialization, fetch info of
dead jobs, allow job annotations, support non-DRMAA jobs and
reservations, and many more.

Cabilities should only apply to API level features, IMHO, not to
implementation details. Those need to go into the documentation of
the implementation.

My $0.02, Andre.

[Peter Tröger]

Post by Andre Merzky
Hi Daniel,

Post by Daniel Gruber
Hi all,
* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
source code portability requires it.

The spec leaves many things to the implementation - I don't think all
those degrees of freedom should be exposed for inspection, as
capabilities. That will quickly grow and becom unwieldy. For
example, optional fdeatures are: struct serialization, fetch info of
dead jobs, allow job annotations, support non-DRMAA jobs and
reservations, and many more.
Cabilities should only apply to API level features, IMHO, not to
implementation details. Those need to go into the documentation of
the implementation.

I strongly support this argumentation, since it makes the scope of the capability feature very clear. Beside that, any promise about multithreading support (or re-entrancy) is a *lie*. Serious programmers do not promise that, since the only way to be absolutely sure is some very fat global lock. It is a pure implementation detail in the sense that it does not change API semantics.

Best regards,
Peter.

Post by Andre Merzky
My $0.02, Andre.
--
Nothing is ever easy...
--
drmaa-wg mailing list
drmaa-wg at ogf.org
http://www.ogf.org/mailman/listinfo/drmaa-wg

[Daniel Gruber]

You are both right! Let's close "MULTITHREADING safety should be a capability"

Daniel

Post by Peter Tröger

Post by Andre Merzky
Hi Daniel,

Post by Daniel Gruber
Hi all,
* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
source code portability requires it.

The spec leaves many things to the implementation - I don't think all
those degrees of freedom should be exposed for inspection, as
capabilities. That will quickly grow and becom unwieldy. For
example, optional fdeatures are: struct serialization, fetch info of
dead jobs, allow job annotations, support non-DRMAA jobs and
reservations, and many more.
Cabilities should only apply to API level features, IMHO, not to
implementation details. Those need to go into the documentation of
the implementation.

I strongly support this argumentation, since it makes the scope of the capability feature very clear. Beside that, any promise about multithreading support (or re-entrancy) is a *lie*. Serious programmers do not promise that, since the only way to be absolutely sure is some very fat global lock. It is a pure implementation detail in the sense that it does not change API semantics.
Best regards,
Peter.

Post by Andre Merzky
My $0.02, Andre.
--
Nothing is ever easy...
--
drmaa-wg mailing list
drmaa-wg at ogf.org
http://www.ogf.org/mailman/listinfo/drmaa-wg