June 2010 - pgi-wg - lists.ogf.org

OGF PGI Requirements - Flexibility and clarity versus Rigidity and confusion
by Etienne URBAH 19 Jul '10

19 Jul '10

Balazs, Morris, Luigi, Johannes and all, Concerning the capture and discussion of the requirements : I think that the main problem is NOT the large number of requirements, but the fact that many original requirements were formulated in a very confusing manner. In particular, many original requirements simultaneously present : A) mainly, the WAY the Execution Service would perform a desired functionality, B) sometimes, the INTERFACE which a Client would use to access this functionality, C) implicitly, the NEED for this functionality. This causes us to lose much time in useless discussions, because this requires to use following process : - First, focus on C) to precisely define the functionality, and assess its usefulness, - Second, focus on B) to define the Client interface, - Third, verify that there is no garbage from A) left anymore. Working on the original explicit, implicit or hidden requirements found inside the documents, this is exactly the process which I personally followed, splitting complex confusing requirements into simpler and clearer ones. This permitted that requirements which I personally wrote down could be often quickly understood, discussed, and even sometimes quickly labeled YES (positively agreed) or NO (No agreement yet). For the many requirements which are still unclear, I therefore urge you to accept that I split them into simpler smaller requirements : - Apparently, it will increase the total number of requirements, - But in fact, after an easy work, that will increase the percentage of requirements labeled YES and diminish the percentage of requirements labeled UNCLEAR. As example, please study following requirement, labeled 'Still UNCLEAR after 10 mn discussion' : - JD20 (115) Job Description document should offer a new re-usable structure to define 'scalabletime' requests optionally depending on benchmark results. I will split it into the 4 following requirements : - Description of the needed functionality : JD20.1 For 'Wall clock time' and 'CPU time' limits, the Execution Service SHOULD accept Client requirements independently of the speed of the Computing Resource on which the Activity will run - Description of the conceptual Client interface : JD20.2 For 'Wall clock time' and 'CPU time' limits, the Job Description document SHOULD offer a new re-usable structure permitting to describe requirements independently of the speed of the Computing Resource on which the Activity will run - First option for a precise description of the Client interface : JD20.3 For 'Wall clock time' and 'CPU time' limits, the re-usable structure permitting to describe requirements independently of the speed of the computing resource on which the Activity will run SHOULD be the ordered pair (Value, Unit) where : - 'Value' is the max number of operations allowed for the Activity, - 'Unit' is as unit suitable for a total number of operations, from a closed list to be refined (such as 'Specint2006 * hours' or 'Billions of floating point operations') This method is already used by BOINC and has proved it robustness. - Second option for a precise description of the Client interface : JD20.4 For 'Wall clock time' and 'CPU time' limits, the re-usable structure permitting to describe requirements independently of the speed of the computing resource on which the Activity will run SHOULD be a 'scalabletime' specified by a (Value, BenchmarkType, BenchmarkValue) triplet as described in chapter 7.2 of the Specification Draft I am absolutely certain that these 4 simple requirements will be quickly understood. I am quite sure that we will immediately obtain a YES for JD20.1 and JD20.2, and perhaps quickly a YES to either JD20.3 or JD20.4 (and a NO to the other one). In the same way of thinking, I will re-propose following dropped requirements. With sometimes an improved title, they describe the NEED for a precise Client interface, WITHOUT specifying the precise component which will implement them : - IS10 For requests querying Status of finished Activity, the Information functionality MUST accept, as input parameter, 1 Activity ID - IS12 For requests querying Activity Status, the Information functionality MUST accept, as input parameter, complex queries on Activities expressed according to the GLUE2 model without explicit specification of the Activity IDs. The Information functionality MAY support multiple query languages in addition to the mandatory one. - LB4 For all requests, the Query functionality for Activity Logs MUST accept, as input parameter, 1 Activity ID - LB6 For all requests, the Query functionality for Activity Logs MUST accept, as input parameter, complex queries on Activities expressed according to the GLUE model without explicit specification of the Activity IDs. The Logging and Bookkeeping functionality MAY support multiple query languages in addition to the mandatory one. Besides, I just detected that we forgot to study following requirement, which was mentioned in my mail dated 26 April 2010. Is it possible to associate spreadsheet ID 172 to it ? - IS14 In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Information functionality SHOULD be separated from the Execution Service Thank you in advance for accepting that, when starting with original confusion : - rigidity prevents improvement and favors endless confusion, - flexibility favors improvement and then clarity. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------

3 5

PGI additional co-chair election process
by Riedel, Morris 08 Jul '10

08 Jul '10

Dear PGI members, as Balazs recently stepped down as a co-chair we have now two positions vacant for these roles to support me in chairing the activities of the group. Although I'm still keen in supporting this group as co-chair, some new roles within JUELICH (e.g. becoming deputy division head) will have potentially an impact in the time I can invest in this group and thus we need urgently a backup for me - the sooner the better. The election of the new co-chairs is an open process and the group decides, but keep in mind that we have a tough time schedule and these positions should be filled as soon as possible to maintain progress. Hence, to support a faster election process, I already discussed group setups with members of OGF and PGI folks, I would therefore like to take the opportunity to recommend the group setup as follows: (1) I recommend that Johannes Watzl (LMU, Munich, Germany) would be one of the additional co-chairs. Johannes is active in GIN since years and participated in PGI since it's beginning as being an effective secretary. Furthermore, his technology-neutral position makes him even more a suitable candidate for chairing sessions/workshops with delicate decisions among the technology providers that contribute to PGI. I already discussed this with Johannes and he is willing to take this role once selected by the group. (2) The selection of Johannes would leave the secretary position as vacant. Given the past and current efforts of Etienne Urbah (LAL, Paris, France) via posters/e-mails/wiki-pages/etc., I would recommend that he should be elected for the secretary role. I already discussed with Etienne his contributions and he is keen to support the group as well in a more formal position. (3) One further additional co-chair position is still open. I'm in discussion with GIN/PGI members from outside of Europe to promote PGI as an international activity! Until these discussions will come to a fruitful state with folks that are willing to give the time required, I'm still open to receive recommendations from the community. Finally, please send me any serious objections (privately) to the proposed setup. If I do not receive significant objections until the end of next week (2010-07-02), I see this setup as being agreed by the group. Afterwards, I will be once again in contact with our area director Andrew Grimshaw to officially confirm the above recommended setup. Your co-chair, Morris ------------------------------------------------------------ Morris Riedel Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

2 1

PGI use cases
by Johannes Watzl 07 Jul '10

07 Jul '10

Dear all, in today's meeting it was suggested to collect use cases of the currently participating middlewares to make the basis for the requirements list easier to understand. The following persons have been assigned initially: ARC use case: Aleksandr EDGI use case: Etienne GENESIS-II use case: Mark GLOBUS use case: Emmanouil gLite use case: Luigi RENKEI use case: Kazushige UNICORE use case: Morris Deadline for first draft Friday, 2 July 2010. (1 page max) The template for use cases will be sent out Friday this week. Every other use case is very welcomed. Best, Johannes -- _ _ _ _ _ _ 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(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

2 2

OGF PGI Execution Service : UML Sequence Diagrams for 3 different cases of Endpoint Stability
by Etienne URBAH 07 Jul '10

07 Jul '10

Morris, Johannes and all, Inside the requirements for OGF PGI Execution Service, there are 3 different cases of stability of Execution Service Endpoints, with corresponding consequences on the Activity ID. In order to ease understanding and discussion, I have created, for each of the 3 cases, a corresponding UML Sequence Diagram showing a possible sequence of operations : - JM4.4 (48) Single Endpoint JM4.7 (50) The Activity ID may be completely opaque http://forge.gridforum.org/sf/go/doc16006?nav=1 (PNG) - JM4.5 (49) Factory and Management Endpoints JM4.8 (51) From the Activity ID, the Client must be able to extract the URL of of the Management Endpoint http://forge.gridforum.org/sf/go/doc16007?nav=1 (PNG) - JM4.6 (168) Transient Endpoints - Each Execution Service must store the Activity ID inside a Name Server JM4.9 (52) The Client must be able to query the Name Server with the Activity Name in order to get the current Activity ID http://forge.gridforum.org/sf/go/doc16008?nav=1 (PNG) The source file is 'PGI Execution Service : UML file (ArgoUML)' at http://forge.gridforum.org/sf/go/doc15878?nav=1 I hope that these 3 UML Sequence Diagrams will be useful. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------

1 1

Condensed Requirement List (v4) on GridForge & Workshop tomorrow
by Riedel, Morris 30 Jun '10

30 Jun '10

Hi PGI team, as some of you requested I uploaded the latest greatest Google sheet excel download into gridforge: http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/do… Thanks again for participating in the decision process today. I'm looking forward to work with you together in the next 2 days in our PGI Workshop. Tomorrow, we meet at 9:00 a.m. in the lobby and go together to our workshop room on the 2nd floor. Take care, Morris ------------------------------------------------------------ Morris Riedel Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

2 1

Requirements Clarification
by Mark M. Morgan 29 Jun '10

29 Jun '10

Dear PGI Colleagues, At the face-to-face meeting last week I was tasked with "clarifying" requirements 110 and 153. Please find attached two documents which respectively attempt to do so. I fear that my clarification for 110 is insufficient as, once I looked into it, I was having trouble determining what the root unclarity of the existing JSDL specification for ranges was so please feel free to let me know if you still find JSDL ranges unclear and I can try and work with you to clarify. Thanks, Mark

1 0

Re: [Pgi-wg] PGI Use Case Template available on GridForge
by Morris Riedel 29 Jun '10

29 Jun '10

Hi again, please don't circulate your use case documents via this e-mail list and rather upload it to the same folder in GridForge. Then provide a short info via e-mail and point to its location on GridForge. Thanks! Your co-chair, Morris >-- -----Ursprüngliche Nachricht----- >-- Von: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] Im Auftrag von >-- Morris Riedel >-- Gesendet: Dienstag, 29. Juni 2010 11:24 >-- An: pgi-wg(a)ogf.org >-- Cc: gin(a)ogf.org >-- Betreff: [Pgi-wg] PGI Use Case Template available on GridForge >-- >-- Hi PGI team, >-- >-- I uploaded the requested use case template (mainly derived from the OGSA- >-- WG one) into GridForge: >-- >-- http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc >-- man.root.drafts.use_cases/doc16013 >-- >-- >-- Please use this template when you provide your PGI use case as discussed in >-- Chicago. >-- >-- >-- Your co-chair, >-- Morris >-- >-- ------------------------------------------------------------ >-- Morris Riedel >-- Distributed Systems and Grid Computing Division >-- >-- Jülich Supercomputing Centre (JSC) >-- Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel >-- >--

1 0

PGI Use Case Template available on GridForge
by Morris Riedel 29 Jun '10

29 Jun '10

Hi PGI team, I uploaded the requested use case template (mainly derived from the OGSA-WG one) into GridForge: http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc man.root.drafts.use_cases/doc16013 Please use this template when you provide your PGI use case as discussed in Chicago. Your co-chair, Morris ------------------------------------------------------------ Morris Riedel Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel

1 0

Use Cases
by Mark Morgan 28 Jun '10

28 Jun '10

I wanted to point everyone to GFD-29 which is the OGSA-WG Use Case document. The use cases in this document are pretty broad and as a result may not be directly relevant to PGI, but the document itself is well formatted and well written and might be a useful template for us to adopt. Also, Morris, can you send out the template you would like us to use for our own use cases? Thanks, Mark

1 0

PGI Workshop Chicago - Dial in information
by Johannes Watzl 23 Jun '10

23 Jun '10

Dear all, at the PGI session at OGF29 and the first day of the PGI workshop the group was working heavily on the requirements list. The new version of the requirements list can be found in GridForge and as googledoc. Tomorrow morning (9am Chicago) we will start with a session with the ability to join remotely. Best, Johannes 1. Please join my meeting, "Thursday, June 24 at 16:00 CEST". https://www1.gotomeeting.com/join/534971584 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. Austria: +43 (0) 7 20881404 Belgium: +32 (0) 42 68 0697 Switzerland: +41 (0) 435 0167 10 Germany: +49 (0) 898 7806 6463 Denmark: +45 69 91 88 66 Spain: 34 931816670 Finland: +358 942 415 782 France: +33 (0) 182 880 460 United Kingdom: +44 (0) 203 318 0627 Ireland: +353 (0) 14 845 980 Italy: +39 (0) 247 92 12 40 Netherlands: +31 (0) 208 080 383 Norway: +47 21 04 29 10 Sweden: +46 (0) 852 503 471 Access Code: 534-971-584 Audio PIN: Shown after joining the meeting Meeting ID: 534-971-584 GoToMeeting® Online Meetings Made Easy™ -- _ _ _ _ _ _ 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(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0