[DRMAA-WG] other IDL issues

[Daniel Gruber]

Am 22.06.2011 um 13:18 schrieb Mariusz Mamoński:

> On 22 June 2011 12:37, Daniel Gruber <dgruber at univa.com> wrote:
>> 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.
> 
> 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. 

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

> 
>> 
>> Cheers,
>> 
>> Daniel
>> --
>>  drmaa-wg mailing list
>>  drmaa-wg at ogf.org
>>  http://www.ogf.org/mailman/listinfo/drmaa-wg
>> 
> 
> 
> Cheers,
> -- 
> Mariusz