Dear all, please see below the revised meeting notes from 18 Dec 2009. Best, Johannes Participants: Luigi, Balazs, Balazs, Morris, Aleksander, Etienne, Emmanouil Paisos, Oxana Emmanouil Paisos short introduction: working at LRZ in the group of Helmut Heller Globus, Grid services, ... debrief the minutes (updated version by Etienne) state model from Etienne - agreed submitted state - incoming, validated? Validation aspects preprocessing -> next year Luigi: please explain why we need the hold state? Etienne: Why do we need to add the hold substate? Inside the submitted state the ARC middleware can send back not only id but also staging information Balazs: in the draft the submitted hold is explained Luigi: If I put the job state in hold, I have to unlock to assume. Morris: Only if a hold point is set in AGU-JSDL document Balazs: for manual changes Morris: next point in the agenda go through action items some administrative things agreed on changing the title of the strawman document to PGI Execution Service Draft Specification filename: PGI_ExecutionService_Draft.doc joint session at OGF28? session request for interoperability day 3 PGI, 2 GIN open floor for presentations action tracking on the mailing list Luigi: discussion about the job lease in CREAM awaiting more email answers for discussion Morris: please resend OGF28 Morris: is there from gLite at OGF28? Luigi: can participate Morris: someone from ARC? Balazs: yes the interoperability day is this also at the OGF? Morris: at OGF action for Morris: ask Nils about the date of the interoperability day discuss the submitted state going through the animation "step-wise animation submitted" Balazs: only if the JSDL is correct, a jobid is created Morris: if JSDL description is wrong, then there is no job everybody agrees? -> yes Etienne: would like at this moment there is an error from the execution service to the scientific gateway Balazs: how long does it take to go through the createActivity operation? Morris: XML evaluation is very fast can throw back a fault as a SOAP response Balazs: vector operation? Etienne: some statistics about jobs sent 5 to 10 seconds for a job to be accepted by the execution service 1 min before the brokering Luigi: we can provide the same interface to the WMS Morris: can we do that? Etienne: the job is in the accepted status with its job id which is matched to the computing element Morris: should we/can we do a brokering interface here Etienne: brokering should be possible but is out of scope match requirements described in the JSDL to a computing element Balazs: we should try to keep this interface open enough that a broker is possible Morris: early enough? could be a long time thinking of 2-3 sec/JSDL Balazs: job id and data staging information Oxana: why worry about how long it takes? Morris: the only appearence after the validation steps -> chance to respond something adding responses Etienne: if we have to wait for an hour to get the job ids for 100 jobs we have to accept that or we have to reduce the number of JSDLs sent together or use completely other method (parameter sweep?) if there are a lot of jobs we have to wait long Luigi: if http connection breaks, SOAP breaks Morris: produces ghost JSDLs Aleksander: the service will detect, that the respose was not submitted to the client Etienne: this has a great impact - should take care of it Aleksander: responses are sent after JSDL processing no cancelling involved Morris: question if we can have here a job id creation before the validation steps Aleksander: job ide could be assigned by the client Luigi: no because it cannot be unique -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room E 005, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl@nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl