Conference call - June 29th - 19:00 UTC
Dear all, the next DRMAA conf call is scheduled for June 29th, 19:00 UTC. We meet on Skype, please find me as user "potsdam_pit". This is the last phone conference before the official "last call" on the mailing list. Please prepare for an open end session. Preliminary meeting agenda: 1. Meeting secretary for this meeting? 2. Solving remaining issues in DRMAAv2 Draft 7 (see attachment) The Draft 7 document considers both the F2F meeting result, and all mailing list discussions until today. Best regards, Peter.
Participants: Roger, Mariusz, Daniel G, Andre Merzcy, Peter
This is the last phone conference before the official "last call" on the mailing list. Please prepare for an open end session.
Preliminary meeting agenda:
1. Meeting secretary for this meeting? 2. Solving remaining issues in DRMAAv2 Draft 7 (see attachment)
Line 280: - Wallclock time is the same for all participating processes - CPU time is meant to be accumulated for all processes of the job Line 511: - Possibility for checking the validity of the incoming struct is implementation-specific - Solution: SHOULD becomes MAY Line 870: - add jobCategory description text for ReservationTemplate, same argumentation as with JobTemplate - for maxSLots > 1 in the ReservationTemplate, the job category only MAY be requested Line 1073: - ok Line 1091: - Replace with "If a session with such name already exists" - Implies both inactive and active sessions Line 1094: - Keep it as it is, since the unique string comes from the implementation anyway Line 1097: - Rename to "openMonitoringSession" - keep closing function for ordered shutdown of monitoring connection to the DRMS Line 1108: - Make that possible for the language binding Line 1042: - Rename to "getJobSessionNames" and "getReservationSessionNames" Line 1401 / 1334: - Make reference to session name, instead of object - Keeps consistent approach that instantiated session objects represent a live 'connection' to the DRMS - connecting to the referenced session is then a separate explicit step in the application Line 1417: - Just an implementation detail, most functions have this problem Line 1411 / 1412: - Checking for an inappropriate state does not work always if the library implements the job array function - Decision to either relax the error condition detection, or to remove JobArrays completely - Decision: Change state checking condition to MAY SlotInfo discussion: - similar to ReservationInfo, SlotInfo should also be used in JobInfo for reporting the utilized machines - For filtering, the slot information should be treated as minimum value Relation between job status and job exit code: - There is intentionally no relation - makes this explicit This was the last phone conference about remaining DRMAA2 issues. The upcoming Draft 8 will go to the mailing list as part of the official "last call."
participants (1)
-
Peter Tröger