Meeting on 2009-10-09, 16:00 (CET) Notes
Dear all, please see the notes from today's meeting below. Best, Johannes Participants: Luigi, David, Johannes, Morris, Etienne 1) Look at the minutes from last time. 2) Discussion: createActivity action createMultiplteActivity David: ordinary JSDL? - means not going to a new JSDL -> meet in the middle David: SRM, SRB ftp, gridftp? Morris: ftp, gridftp still in scope SRB partly the same approach document initial version not covering data staging overall overview, two month out. only few comments from Etienne no crucial comments need for reference implementation PGI profile on top of BES 2.0 proceed with the reference implementation and get out with the PGI writings in parallel to the implementation parts from Andrew, parts from other standards Go to document: Execution port type: Any question to the execution port type interface? Continue with 2nd chapter: Action for Balazs and Morris: GLUE 2 tunings, exectution port type Action for Balazs and Morris: fault mechanism createActivity: discussing of possible fault parameter sweep not agree to transaction approach, not wanted currently browsing all epr Morris: postpone transaction go into the vector operation Luigi: transaction is not important at the moment all jobs are single jobs, not interested in grouping jobs at the moment no reason to change transaction Etienne: out of scope Morris: it is not only grouping - it is a bit more would not call out of scope - not every partner is represented today 2) createActivity operation stresses changeability of BES, OGSA-BES2.0 how much BES has to be tweaked to move to our approach in the reference implementation epr is there some problem with this? no data staging how could data staging work? extend a little bit partly covered by PGI service extend the usage of credentials Action for Morris: security aspects for credentials in data staging typical way of doing JSDL not invent something new provide more protocols hierarchical approach to provide more functionality data push from a client perspective users from ARC, gLite mentioned this partly related to the state model Action for Etienne: how much of the createActivity operation is covered by the state model? (client initiated data staging) other side effect: hold points continue operation postpone and continue operation keep out of the question now focus on different aspects figure of the process published (Morris) Action for Morris: createActivite figure of process should be delivered Action for Morris: ask Shahbaz dataurl createActivity Requests: fearly easy AGU JSDL working title quite a long discussion what activities are valid look behind the response JSDL element is dropped - no error other implementations return an error if dropped. have a look on Job description document validation XML valid or not? next level: check document according to the schema is the sematics the same as we understand? important to check the semantic services are not really supporting parts of description should have somewhere the information what kind of data staging information is provided agreed to have this list. how this can be nailed down Action to all: what is meant by service capabilities? link to GLUE2? influence? final discussion was what is understood by match making never ignore things if we take this JSDL doc - in the past simply ignored it leading to the point -> never a fault -> user thought everything is fine consensus: not ignore things any more submit state: Action for Etienne and Luigi: have a look at submit state email with answer email discussion will go on. Question to Lugi: last tbd in createactivity: lease? Luigi: each job has an attribute for basically the time to live of the job renewed by client as long the client and the service can talk when lease expires the job is removed from both sides Action for Luigi: email: Subject createActivity operation, lease start email thread AOB? Etienne: lease? what is the relationship with the timeline of the proxy Luigi: not related, but depends on the implementation proxy can be renewed and lease can also be renewed no true relationship between lease and proxy -> include in email. Actions for Johanens: action list also on email remember people before next meeting, tasks David: push Morris comments on BES -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, 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
Many thanks Johannes! ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Johannes Watzl -Sent: Friday, October 09, 2009 5:10 PM -To: pgi -Subject: [Pgi-wg] Meeting on 2009-10-09, 16:00 (CET) Notes - -Dear all, - -please see the notes from today's meeting below. - -Best, -Johannes - - -Participants: -Luigi, David, Johannes, Morris, Etienne - -1) Look at the minutes from last time. - -2) Discussion: -createActivity action -createMultiplteActivity - -David: ordinary JSDL? - means not going to a new JSDL --> meet in the middle - -David: -SRM, SRB -ftp, gridftp? - -Morris: -ftp, gridftp still in scope -SRB partly the same approach - -document initial version not covering data staging - -overall overview, two month out. only few comments from Etienne -no crucial comments -need for reference implementation - -PGI profile on top of BES 2.0 - -proceed with the reference implementation and get out with the PGI -writings in parallel to the implementation - -parts from Andrew, parts from other standards - -Go to document: -Execution port type: - -Any question to the execution port type interface? - -Continue with 2nd chapter: -Action for Balazs and Morris: -GLUE 2 tunings, exectution port type -Action for Balazs and Morris: -fault mechanism - -createActivity: discussing of possible fault - -parameter sweep -not agree to transaction approach, not wanted currently - -browsing all epr - -Morris: -postpone transaction -go into the vector operation - -Luigi: -transaction is not important at the moment -all jobs are single jobs, not interested in grouping jobs at the moment -no reason to change transaction - -Etienne: -out of scope - -Morris: -it is not only grouping - it is a bit more -would not call out of scope - not every partner is represented today - -2) -createActivity operation -stresses changeability of BES, OGSA-BES2.0 -how much BES has to be tweaked to move to our approach - -in the reference implementation epr - -is there some problem with this? -no - -data staging -how could data staging work? -extend a little bit - -partly covered by PGI service -extend the usage of credentials - -Action for Morris: security aspects for credentials in data staging - -typical way of doing -JSDL -not invent something new -provide more protocols -hierarchical approach to provide more functionality - -data push from a client perspective -users from ARC, gLite mentioned this - -partly related to the state model - -Action for Etienne: -how much of the createActivity operation is covered by the state model? -(client initiated data staging) - -other side effect: -hold points -continue operation -postpone and continue operation -keep out of the question now - -focus on different aspects -figure of the process published (Morris) - -Action for Morris: -createActivite figure of process should be delivered - -Action for Morris: ask Shahbaz dataurl createActivity - -Requests: -fearly easy -AGU JSDL working title - -quite a long discussion what activities are valid - -look behind the response - -JSDL element is dropped - no error -other implementations return an error if dropped. - -have a look on Job description document validation - -XML valid or not? - -next level: check document according to the schema - -is the sematics the same as we understand? -important to check the semantic - -services are not really supporting parts of description -should have somewhere the information what kind of data staging -information is provided -agreed to have this list. how this can be nailed down - -Action to all: what is meant by service capabilities? -link to GLUE2? influence? - -final discussion was what is understood by match making -never ignore things - -if we take this JSDL doc - in the past simply ignored it -leading to the point -> never a fault -> user thought everything is fine - -consensus: not ignore things any more - -submit state: -Action for Etienne and Luigi: have a look at submit state -email with answer -email discussion will go on. - -Question to Lugi: -last tbd in createactivity: lease? -Luigi: -each job has an attribute for basically the time to live of the job -renewed by client as long the client and the service can talk -when lease expires the job is removed from both sides - -Action for Luigi: email: -Subject createActivity operation, lease -start email thread - -AOB? - -Etienne: lease? -what is the relationship with the timeline of the proxy - -Luigi: -not related, but depends on the implementation -proxy can be renewed and lease can also be renewed -no true relationship between lease and proxy --> include in email. - -Actions for Johanens: -action list also on email -remember people before next meeting, tasks - -David: -push Morris comments on BES - - --- - _ _ _ _ _ _ Johannes Watzl - |\/| |\ | |\/| Institut für Informatik / Dept. of CS - | | | \| | | Ludwig-Maximilians-Universität München - ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany - Room D0.5, 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 -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
participants (2)
-
Johannes Watzl -
Morris Riedel