Conference call - Aug 25th - 19:00 UTC
Dear all, the next DRMAA phone conference is scheduled on Aug 25th, at 19:00 UTC. The phone conference line is sponsored by Oracle. Please consult the following page for dial-in numbers from your country: http://www.intercall.com/oracle/access_numbers.htm The conference code is 6513037. The security code is DRMAA (37622). Preliminary meeting agenda: 1. Meeting secretary ? 2. eMail on job start / termination - follow-up of mail discussion 3. New JT attribute for re-runnable jobs 4. JobInfo::jobTemplate vs. job monitoring attributes (check Google spreadsheet) 5. Sanity check for OS type description (check http://tinyurl.com/25cy9u7 ) 6. Proposal for new JobInfo attributes: priority and memory consumption (check Google spreadsheet) 7. Is SGE really not able to distinguish between user mode CPU time and system mode CPU time ? (check Google spreadsheet) 8. Collaborative editing of Google spreadsheet Google spreadsheet: http://spreadsheets.google.com/ccc?key=0AqyvnBscJNqxcnJBSUs5dXRrU29EUVhGOGth... Best regards, Peter.
Participants: Roger, Dan, Mariusz, Peter
> 1. Meeting secretary ?
Peter.
> 2. eMail on job start / termination - follow-up of mail discussion
- Don't use multiple attributes that contain the same addresses
- Enumeration of flag combinations would not be extensible by the
implementation, and does not scale for future DRMAA versions
- Decision to have one address attribute, plus a set of boolean flag
attributes for the time of email sending
> 3. New JT attribute for re-runnable jobs
- Re-runnability is different from checkpointability in the majority of
systems
- Different default settings in the DRM systems
- General agreement on adding the boolean attribute
- Raised new issue: What are the default values for JobTemplate
atrtributes ?
- So far, DRM system defaults are implicitely used when not setting
an attribute
- Worked with getter / setter - based attribute change, how to
realize with JT struct ?
- Two options: Notion of "invalid value", default for all
attributes OR setting system defaults as struct value defaults
- Second option not implementable in all cases, example working
directory
- First option might mandate explicit error checking in DRMAA
applications, which was not mandatory with setter function exceptions
- Problem identified as not big enough to roll-back data struct approach
- Decision: Defining "invalid value" for data types is task of the
language binding
- Boolean in C: Use custom enumeration (TRUE, FALSE, INVALID) or
pointer to static values
- Numerical in C: Use magic number; since all long attributes are
unsigned, it could be MIN_INT
- Implementation strategy for Java exists
- With Python, just use NONE
> 4. JobInfo::jobTemplate vs. job monitoring attributes (check Google
> spreadsheet)
> 5. Sanity check for OS type description (check
> http://tinyurl.com/25cy9u7 )
> 6. Proposal for new JobInfo attributes: priority and memory
> consumption (check Google spreadsheet)
> 7. Is SGE really not able to distinguish between user mode CPU time
> and system mode CPU time ? (check Google spreadsheet)
> 8. Collaborative editing of Google spreadsheet
>
> Google spreadsheet:
> http://spreadsheets.google.com/ccc?key=0AqyvnBscJNqxcnJBSUs5dXRrU29EUVhGOGthc1lDTFE
Not covered due to time constraints.
/Peter.
Hi all, Quoting [Peter Tr?ger] (Aug 25 2010):
- Raised new issue: What are the default values for JobTemplate atrtributes ? - So far, DRM system defaults are implicitely used when not setting an attribute - Worked with getter / setter - based attribute change, how to realize with JT struct ? - Two options: Notion of "invalid value", default for all attributes OR setting system defaults as struct value defaults - Second option not implementable in all cases, example working directory
sorry for jumping in sideways again, I did not follow the complete discussion I am afraid. But isn't the first option also very difficult to *use*? Again for example for the working directory: an 'invalid value' as default would likely trigger the backend to decline the job request. So, the DRMAA user would need to set all required values explicitely. So, IMHO, a third option would be to allow for empty values, which are then interpreted as 'unspecified', and set by the backend as needed (e.g. with the system default working directory). My $0.02, Andre.
- First option might mandate explicit error checking in DRMAA applications, which was not mandatory with setter function exceptions - Problem identified as not big enough to roll-back data struct approach - Decision: Defining "invalid value" for data types is task of the language binding - Boolean in C: Use custom enumeration (TRUE, FALSE, INVALID) or pointer to static values - Numerical in C: Use magic number; since all long attributes are unsigned, it could be MIN_INT - Implementation strategy for Java exists - With Python, just use NONE
4. JobInfo::jobTemplate vs. job monitoring attributes (check Google spreadsheet) 5. Sanity check for OS type description (check http://tinyurl.com/25cy9u7 ) 6. Proposal for new JobInfo attributes: priority and memory consumption (check Google spreadsheet) 7. Is SGE really not able to distinguish between user mode CPU time and system mode CPU time ? (check Google spreadsheet) 8. Collaborative editing of Google spreadsheet
Google spreadsheet: http://spreadsheets.google.com/ccc?key=0AqyvnBscJNqxcnJBSUs5dXRrU29EUVhGOGth...
Not covered due to time constraints.
/Peter. -- Nothing is ever easy.
Hi,
- Raised new issue: What are the default values for JobTemplate atrtributes ? - So far, DRM system defaults are implicitely used when not setting an attribute - Worked with getter / setter - based attribute change, how to realize with JT struct ? - Two options: Notion of "invalid value", default for all attributes OR setting system defaults as struct value defaults - Second option not implementable in all cases, example working directory
sorry for jumping in sideways again, I did not follow the complete discussion I am afraid. But isn't the first option also very difficult to *use*? Again for example for the working directory: an 'invalid value' as default would likely trigger the backend to decline the job request. So, the DRMAA user would need to set all required values explicitely.
So, IMHO, a third option would be to allow for empty values, which are then interpreted as 'unspecified', and set by the backend as needed (e.g. with the system default working directory).
Our "invalid value" and your "empty value" are the same idea, the wording is a little bit weak. Roger called them "magic number" for the numerical case. Your second paragraph precisely describes our current idea. /Peter.
Quoting [Peter Tr?ger] (Aug 26 2010):
Hi,
- Raised new issue: What are the default values for JobTemplate atrtributes ? - So far, DRM system defaults are implicitely used when not setting an attribute - Worked with getter / setter - based attribute change, how to realize with JT struct ? - Two options: Notion of "invalid value", default for all attributes OR setting system defaults as struct value defaults - Second option not implementable in all cases, example working directory
sorry for jumping in sideways again, I did not follow the complete discussion I am afraid. But isn't the first option also very difficult to *use*? Again for example for the working directory: an 'invalid value' as default would likely trigger the backend to decline the job request. So, the DRMAA user would need to set all required values explicitely.
So, IMHO, a third option would be to allow for empty values, which are then interpreted as 'unspecified', and set by the backend as needed (e.g. with the system default working directory).
Our "invalid value" and your "empty value" are the same idea, the wording is a little bit weak. Roger called them "magic number" for the numerical case. Your second paragraph precisely describes our current idea.
thanks for the clarification! :-) But yes, your wording is not really fitting IMHO. Like, the boolean triplet proposed for the C binding would be better expressed as 'TRUE, FALSE, UNDEFINED' IMHO. Best, Andre.
/Peter.
-- Nothing is ever easy.
participants (2)
-
Andre Merzky -
Peter Tröger