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

Re: [Pgi-wg] Gridiron, or standardization gone backwards
by David Wallom 22 Jul '10

22 Jul '10

Hello Oxana, Though I agree in the most parts with your analogy this does seem to be in one way or another the technologists again not getting what the user community want. Take for example Structural Biologists, they are collaborating across continental Europe, UK and US by at the moment having themselves to devise the translators/metalayers necessary to bridge across different infrastructures. We need to move beyond the 'my technical solution is better than yours' and realise that if we are not careful the user communities will just see that we are infighting and go their own way (or tell our funders that we are inefficient and not worth continuing). We must move towards standards and 'give' a little on all sides. The research community in the UK sees US collaboration as increasingly important with small amounts of EU collaboration because of funding. If we are not careful they will go their own way totally and we will not get them back. To go back to your analogy, If the user community wants to play gridiron you can shout until you are blue in the face about soccer but they will ignore you, it isn't suitable for them. David On 18/07/2010 01:39, "Oxana Smirnova" <oxana.smirnova(a)hep.lu.se> wrote: > Hi all, > > I intended to comment on use cases, but feel like commenting on the very fact > of their appearance. > > When the PGI founders first met in September 2008 (yes, 2008), they produced a > very advanced draft, almost a ready-made specification. The only reason they > could not call it a specification was that they were nobody - that is, OGF did > not know of them. > > They didn't have to waste time on formalizing use cases and requirements, > because all these were in their heads. > > In football terms, they played by similar rules, and didn't have to explain to > each other the gory details. They were driven by the desire to produce common > rules of the game for themselves, such that they can play in the same league. > > Then OGF kindly adopted the team, but at the cost of putting forward formal > requirements. No forward movement happened since. First step backwards was to > trim the specs to a "strawman". Second step backwards was to drop the strawman > and collect requirements. The third step backwards was to go back to use > cases. I dread to think what will be the next PGI decision? To create itself? > > In September 2008 we thought that by December same year we'll have the core > specs. Two years later we are discussing what is the best template for use > cases and which teleconferencing tool to use. This is, well, unbelievable. > > And Ithink I know the reason. We try to compare incomparable things. > > Imagine an international football federation that brings together association > football, American football, rugby, Australian rules football and all such > things. And imagine this federation introducing common rules. What would this > rule be? Right, "the game is played on a large field by two teams". Is there > any practical use of this rule? No, every league will have to keep own > "extensions". > > Despite often looking brain-damaged, footballers are clever enough not to > invent common football rules. They realize that the term is overloaded, and > they manage to disambiguate it. > > Grids brought together by PGI are as different as gridiron is different from > soccer. Let's face it. They still can be played on the same pitch - meaning, > they can use same hardware - but attempts to device common > rules/specifications so far lead nowhere. It is as if gridiron guys would be > keeping insisting that soccer has to be played with a ball that doesn't even > look like a ball, and rugby folks would be agreeing, and soccer guys would be > scratching their heads and meekly saying that their use case is actually to > kick it with feet, not carry in armpits. > > The analogy is probably not exactly accurate, but I am quite frustrated, as I > can see no progress whatsoever. Of the original PGI "creators" only three are > still attending the meetings - Johannes, Aleksandr and myself. > > Any suggestions are welcomed. > > Cheers, > Oxana > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg -- =================================== Dr David Wallom Technical Manager Oxford e-Research Centre University of Oxford Rm 160, 7 Keble Road Oxford OX1 3QG +44(0)1865 610601 ===================================

3 2

Re: [Pgi-wg] Professional Software Engineering (was Gridiron, or standardization gone backwards)
by Etienne URBAH 21 Jul '10

21 Jul '10

Morris, Oxana, David and all Lot of thanks to Morris for his general leadership and his positive mail oriented toward future success. I fully understand that many PGI-WG members are frustrated by the non-achievements and internal struggles, and I try to present below some explanations and proposals. 'Very advanced draft' produced by the PGI founders in September 2008 -------------------------------------------------------------------- Did this 'Very advanced draft' ever exist ? Inside GridForge PGI documents, the 'Input_Documents/Pre-OGF_material' contains various little files, some of which containing only some fragments of requirements or specifications. Only on 11 May 2009 did Balazs KONYA upload the first version of the 'Rendering of the GES strawman' in GridForge at http://forge.gridforum.org/sf/go/doc15628?nav=1 with comment 'initial rather incomplete draft'. NONE of the previous files clearly describes : - the context : - Distributed resources managed inside separate administrative domains, - Local and Grid-level credentials, - Computing resources forbidden (or authorized) to have internet access, - Input files available inside the Grid or only available on the local machine of the Submitter of the Activity, - ... - the problem(s) to be solved (AUTHN, AUTHZ, Delegation, Automatic / Manual Data Staging, ...), - a summary of the solution(s) proposed to solve the problem(s), - the interactions between the software components used in the solution(s), - the semantics and syntax of the data that the software components have to exchange, - the sequence of the exchanged messages, and their relationships with states of the software components. Only on 31 July 2009 did Moreno MARZOLLA upload the 'Strawman functionality' in GridForge at http://forge.gridforum.org/sf/go/doc15736?nav=1 At that time, PGI should have worked to validate this foundational document, which contains at least some hints about the above topics. But instead of working on the validation of this foundational 'Strawman functionality' document, PGI regrettably continued struggling on the 'Rendering of the GES strawman'. This document regrettably dives directly into Port-Types, which are details of communication protocol totally irrelevant at this stage. They didn't have to waste time on formalizing use cases and requirements, because all these were in their heads. ----------------------------------------------------------- That is the main cause of FAILURE for most projects : Founders ERRONEOUSLY think that the use cases and requirements are clear in their heads, but in most projects, this proves FALSE, and misunderstanding pops up everywhere. In particular, I is clear that the founders do NOT agree on what an Activity ID should be, and do NOT understand even now the relationships of this issue with the stability of the Endpoint of the Execution Service (Single Endpoint, Factory + Manager, Transient Endpoints). This is the reason why I have published the 3 corresponding Sequence Diagrams inside the 'Input Documents / Execution Service' folder. Using the lessons of dozens of years of bad organization and thousands of projects with bad software design, the most talented researchers (Booch, Jacobson, Rumbaugh, ...) have gathered best practices and propose methods permitting stakeholders to : - understand the problems, - write them down in a manner understandable for others, - begin their work with foundations which will not collapse too quickly. Just like Alchemy used the rules of science to evolve into Chemistry : Computing is using methods like CMMI or ITIL, and languages like UML, to evolve into professional Software Engineering and Operation. In particular, we have to consider : - Use Cases, - Requirements, - Use Case Diagrams, - Class Diagrams, - Collaboration Diagrams, - Sequence Diagrams, - State Diagrams, - Deployment Diagrams, - Flow Charts, - ... Professionals preferably begin with Use Cases. Therefore, Use Cases are often the foundation of the whole Software Engineering work. In order that these foundations are good, it is absolutely necessary that the Use Cases correctly describe the System, the Actors, the Preconditions, the Interactions between the Actors and the System, ... This is the reason why I strongly reject a bad Use Case Template. Analogies with 'Gridiron' and with 'Foreign people driving foreign cars' ------------------------------------------------------------------------ I am afraid that one of the main problem is that 'Gridiron' is an appropriate analogy for simple computing with different programs on different machines, which is far simpler that our real problem. Though, 'Gridiron' can still propose some useful foundation rules, such as : - Players must respect each other, - In order to accommodate variations in 'Gridiron' rules, the whole playground must be large enough, the detailed surfaces of play should be delimited with washable or removable paint, and there must be an available assortment of balls of different forms and sizes. - ... But 'providing middleware for a distributed infrastructure managed locally by separate administrative domains and authorizing users to submit activities on remote resources' is VERY FAR from simple computing. This is a completely different story, of much higher complexity, having analogy with 'Foreign people driving foreign cars' : - In each country, traffic is managed by the local police, which has the right to stop any car and/or any driver. - In order to be allowed in a given country : - A driver must have a valid driver license, - A car must have a valid plate number and a valid insurance. - Generally, countries trust each other, so that - A driver license issued in one country is valid in all other countries, - An insurance issued in one country is valid in all other countries. (But currently, my own car insurance is NOT valid for Irak and North Korea) - In order to ease driving and prevent accidents : - Traffic is everywhere on the right side of the road (except in the United Kingdom !) - All indications, and especially warnings, should be given with commonly agreed pictograms (Do you all understand what 'Pont effondré' means ?) - Street names should be indicated using street plates (But street plates are parallel to the street in France, and as far as I remember, perpendicular to the street in the USA) - If necessary, street plates should display a commonly agreed Latin transliteration (Ever tried to find 'Avenue Croutchef', who is a former Soviet Union leader ?) *** use cases must be provided by users --------------------------------------- Theoretically, yes. But computing scientists can only provide 'computing' use case. And our problem is NOT 'computing', but 'providing middleware for a distributed infrastructure managed locally by separate administrative domains and authorizing users to submit activities on remote resources'. Who are able to understand this problem, and write down relevant Use Cases ? - Surely the members of the teams having designed and now operating WLCG, - Perhaps the members of OGF PGI-WG, if we accept professional Software Engineering. Therefore, I suggest that each member of PGI-WG : - carefully studies the 2 Use Case Templates and the 9 Use Case documents published, - if necessary seeks advise of professionals working daily on Use Case capture, - makes his/her own mind, - presents his/her position. use case where these different systems must be brought together --------------------------------------------------------------- 1) http://forge.gridforum.org/sf/go/doc16010?nav=1 'Enforce Security of a Production Service Grid' 2) http://forge.gridforum.org/sf/go/doc16022?nav=1 'from Service Grid to Desktop Grid' The EDGI project will implement this Use Case for : - gLite, ARC and Unicore as Service Grid middleware, - BOINC, XtremWeb-HEP and perhaps also OurGrid as Desktop Grid middleware 3) If absolutely necessary, the EDGI project is also able to implement following Use Case : 'Marshal Activities between gLite, ARC and Unicore' But we hope that this will NOT be necessary. Let's work with enthusiasm and professionalism ! 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 ----------------------------------------------------- On Tue, 20/07/2010 16:10, Morris Riedel wrote: > Dear Oxana, > > thanks for your summary. > > > (1) > In fact, I can deeply understand your sadness of what the path for PGI - initially was - and now finally became. > > > > (2) > Nevertheless, PGI was created with participation of a small community (only EU) but since then it was a constant struggle in process because of numerous reasons that I don't want to list all. > > Examples include that we at least doubled the initial three involved technologies to six and beyond that are currently involved in PGI thus extending to Asia and US. This leads to a huge increase in time required for the agreement processes and discussions, but also significantly increase the impact of PGI. > > Another example, is the initial lack of funding leading to best-efforts-only and the proposal process in Europe, then US, that in turn was limiting our time to work with PGI with the necessary enthusiasm. > > > > (3) > But instead of complaining - important is that we agreed at OGF to move back to the use cases process because of numerous reasons! > > Like a graph algorithm in a complex graph, it might be sometimes necessary to perform one or more 'back steps' in order to achieve a solution and to find 'the path'. > > > > (4) > More importantly, the first time the very major technology providers of our distributed computing community actually 'sit on the same table' together to produce something useful t o g e t h e r. > > I therefore still believe that we can achieve something in PGI, although partly struggling, we managed to get the right players on board to hopefully have a much higher impact of PGI than initially aimed for. > > > > (5) > So, let's don't give up so quickly. > > We already have a much better mutual understanding in PGI as before - let's build on this and keep on working little by little achieving something. > > > Your co-chair, > Morris On Tue, 20/07/2010 14:43, Oxana Smirnova wrote: > Hi David, > > you actually bring me back to my first post about use cases, which said: > > *** use cases must be provided by users > > I still stand by it. Indeed, if we have a community that plays gridiron, they'll never agree to twist the existing rules in order to make it looking a bit like soccer. Yet, we are trying to do exactly this. > > I never claim that one technological solution is better than another, just like I never will dare to claim that soccer is better than gridiron :-) What I say, is that they are *different*. > > If anybody has a use case where these different systems must be brought together, I'd like to have *this* use case, described in details, what exactly is needed, what exactly has to be unified and standardised. > > Cheers, > Oxana > > > On 20.07.2010 11:52, David Wallom wrote: >> Hello Oxana, >> >> Though I agree in the most parts with your analogy this does seem to be in >> one way or another the technologists again not getting what the user >> community want. Take for example Structural Biologists, they are >> collaborating across continental Europe, UK and US by at the moment having >> themselves to devise the translators/metalayers necessary to bridge across >> different infrastructures. >> >> We need to move beyond the 'my technical solution is better than yours' and >> realise that if we are not careful the user communities will just see that >> we are infighting and go their own way (or tell our funders that we are >> inefficient and not worth continuing). We must move towards standards and >> 'give' a little on all sides. >> >> The research community in the UK sees US collaboration as increasingly >> important with small amounts of EU collaboration because of funding. If we >> are not careful they will go their own way totally and we will not get them >> back. To go back to your analogy, If the user community wants to play >> gridiron you can shout until you are blue in the face about soccer but they >> will ignore you, it isn't suitable for them. >> >> David >> >> >> On 18/07/2010 01:39, "Oxana Smirnova"<oxana.smirnova(a)hep.lu.se> wrote: >> >>> Hi all, >>> >>> I intended to comment on use cases, but feel like commenting on the very fact >>> of their appearance. >>> >>> When the PGI founders first met in September 2008 (yes, 2008), they produced a >>> very advanced draft, almost a ready-made specification. The only reason they >>> could not call it a specification was that they were nobody - that is, OGF did >>> not know of them. >>> >>> They didn't have to waste time on formalizing use cases and requirements, >>> because all these were in their heads. >>> >>> In football terms, they played by similar rules, and didn't have to explain to >>> each other the gory details. They were driven by the desire to produce common >>> rules of the game for themselves, such that they can play in the same league. >>> >>> Then OGF kindly adopted the team, but at the cost of putting forward formal >>> requirements. No forward movement happened since. First step backwards was to >>> trim the specs to a "strawman". Second step backwards was to drop the strawman >>> and collect requirements. The third step backwards was to go back to use >>> cases. I dread to think what will be the next PGI decision? To create itself? >>> >>> In September 2008 we thought that by December same year we'll have the core >>> specs. Two years later we are discussing what is the best template for use >>> cases and which teleconferencing tool to use. This is, well, unbelievable. >>> >>> And Ithink I know the reason. We try to compare incomparable things. >>> >>> Imagine an international football federation that brings together association >>> football, American football, rugby, Australian rules football and all such >>> things. And imagine this federation introducing common rules. What would this >>> rule be? Right, "the game is played on a large field by two teams". Is there >>> any practical use of this rule? No, every league will have to keep own >>> "extensions". >>> >>> Despite often looking brain-damaged, footballers are clever enough not to >>> invent common football rules. They realize that the term is overloaded, and >>> they manage to disambiguate it. >>> >>> Grids brought together by PGI are as different as gridiron is different from >>> soccer. Let's face it. They still can be played on the same pitch - meaning, >>> they can use same hardware - but attempts to device common >>> rules/specifications so far lead nowhere. It is as if gridiron guys would be >>> keeping insisting that soccer has to be played with a ball that doesn't even >>> look like a ball, and rugby folks would be agreeing, and soccer guys would be >>> scratching their heads and meekly saying that their use case is actually to >>> kick it with feet, not carry in armpits. >>> >>> The analogy is probably not exactly accurate, but I am quite frustrated, as I >>> can see no progress whatsoever. Of the original PGI "creators" only three are >>> still attending the meetings - Johannes, Aleksandr and myself. >>> >>> Any suggestions are welcomed. >>> >>> Cheers, >>> Oxana > > Oxana Smirnova <oxana.smirnova(a)hep.lu.se> > Lund University / NDGF

3 3

OGF PGI telephone conference on 2010-07-08 : Notes of Etienne
by Etienne URBAH 21 Jul '10

21 Jul '10

Johannes and Morris, Please find below my notes for the OGF PGI telephone conference on 2010-07-08. As I already explained about my way of taking notes, these notes are written in English with context hints in order to be easily understandable, but are surely not complete. 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 ----------------------------------------------------- OGF PGI telephone conference on 2010-07-08 ------------------------------------------ Participants: Morris, Johannes, Aleksander, Emmanouil, Etienne, Luigi, Mark (+ perhaps Michael), Michaela From 15h30 to 16h00 CET, notes were taken by Johannes. From 16h00 CET, notes were taken by Etienne. Actions ------- Chairs (Morris and Johannes): - Find a 3rd co-chair - Find a secretary - For the Requirements Spreadsheet : Check if GridForge contains the latest version. If not, then upload the latest version to GridForge - Give write access on GridForge to Emmanouil and Luigi so that they can upload documents - Next PGI telephone conference : Discussion not only on Use Cases, but also on the whole document process : Which documents should OGF PGI produce, in which order, in which time frame, ... Everyone can add comments to the template for Use Cases http://forge.gridforum.org/sf/go/doc16013?nav=1 - Etienne will add some comments Following people should upload their Use Cases following the template to GridForge http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docma… : - Emmanouil for Globus - Luigi for gLite - Morris for Unicore Following people should convert their Use Cases according to the provided template : - Etienne for EDGI - Aleksandr for ARC Next OGF PGI telephone conference on Thursday 2010-07-15 at 15h30 CET Review process for the Use Cases -------------------------------- Each member of OGF PGI may add comments to each Use Case. Options: # 1 - Compile one single draft document containing all Use Cases, everybody can comment this single document Vote YES by Morris, Mark Vote NO by Etienne : In order to enforce traceability when many people simultaneously add comments to the same document, only a simple text document under SVN is suitable, NOT a MS-WORD or OpenOffice document # 2 - For a while, keep 1 separate document for each Use Case in order to receive comments, later compile all of them into a single document Vote YES by Etienne, Aleksandr In order to manage modifications of a document by several people : - GridForge permits to put a separate lock on each document, - It is more efficient to manage a separate lock for each one of several separate documents than 1 single lock on 1 single big document. # 3 - Google Docs Vote NO by Etienne : That is NOT OGF groupware. Agreed process: Option # 2 Assume each Use Case document is on GridForge 1) Using GridForge, lock the document, then download it 2) Using a document editor (MS-Word, OpenOffice, ...), turn the 'track changes' option on, perform the changes, save the document 3) Using GridForge, upload the document, then unlock it 4) Inform the group via e-mail that there have been changes Deadlines : 2010-07-15 for everyone to make comments on each separate Use Case 2010-07-22 for the initial author to integrate comments on each separate Use Case

4 5

Re: [Pgi-wg] Gridiron, or standardization gone backwards
by Steven Newhouse 20 Jul '10

20 Jul '10

> If anybody has a use case where these different systems must be brought > together, I'd like to have *this* use case, described in details, what exactly is > needed, what exactly has to be unified and standardised. EGI. Different NGIs wish to deploy different software and for their user communities to be able to access resources in different NGIs without worrying the software stack that is being run on the remote resources. This applies as much within Europe as between Europe and the USA and elsewhere in the world. Standards provides the solution. Steven -- Steven Newhouse EGI-InSPIRE Project Director EGI.eu Director Tel: +31 20 592 2206 Mob: +31 6 3037 2845

2 1

Re: [Pgi-wg] Gridiron, or standardization gone backwards
by Oxana Smirnova 20 Jul '10

20 Jul '10

Hi Morris, all, I definitely don't give up - otherwise I wouldn't have been writing these mails ;-) I try to understand what made the initially rapid process stale. And I do believe that substantial differences between different technologies do create obstacles. If the technologies would have been sufficiently similar, like soccer played in Scotland and England, it would have been straightforward to create common standards. Let's sit back and have a look at the crowd flocked to PGI, and ask ourselves, what exactly do we all want to achieve? Morris, I know you like low-hanging fruits :-) Next time you're in Lund, I'll show you an odd pear tree in the neighborhood: it was not pruned for hundred years or so, and is as tall as a pine now. Imagine where are low-hanging pears ;-) PGI keeps growing, fruits are getting out of reach. A tall pear tree certainly will create a large impact when felled, but is pretty much useless fruit-wise. It is easy to understand why so many technology providers are in PGI: the original PGI proclaimed that we'll create *the* reference standards, and everybody got worried that their favorite requirement won't be taken into account. No wonder we collected 237 or so *contradictory* requirements. The high-level use case we tried to address 2 years ago was: "A computing infrastructure is created using services provided by gLite, ARC and UNICORE" Then, going into details of what is a "computing infrastructure", we came with requirements that: 1. job description must be common (common JSDL flavour) 2. resource discovery and monitoring must be common (common GLUE2 schema) 3. execution interfaces must be common (common BES) Of course, authorisation and data management interfaces also must be common, but they were already largely unified thanks to GSI and SRM, so the task was easy and the goal was clearly in sight. Too bad it was never achieved - even though the impact wold have been limited, still quite many users would have benefited. Now, what is the new PGI use case? "Create a worldwide computing infrastructure using all possible technologies"? I hope not. It will be a bit like creating a common NFL+FIFA championship ;-) Cheers, Oxana

1 0

Gridiron, or standardization gone backwards
by Oxana Smirnova 20 Jul '10

20 Jul '10

Hi all, I intended to comment on use cases, but feel like commenting on the very fact of their appearance. When the PGI founders first met in September 2008 (yes, 2008), they produced a very advanced draft, almost a ready-made specification. The only reason they could not call it a specification was that they were nobody - that is, OGF did not know of them. They didn't have to waste time on formalizing use cases and requirements, because all these were in their heads. In football terms, they played by similar rules, and didn't have to explain to each other the gory details. They were driven by the desire to produce common rules of the game for themselves, such that they can play in the same league. Then OGF kindly adopted the team, but at the cost of putting forward formal requirements. No forward movement happened since. First step backwards was to trim the specs to a "strawman". Second step backwards was to drop the strawman and collect requirements. The third step backwards was to go back to use cases. I dread to think what will be the next PGI decision? To create itself? In September 2008 we thought that by December same year we'll have the core specs. Two years later we are discussing what is the best template for use cases and which teleconferencing tool to use. This is, well, unbelievable. And Ithink I know the reason. We try to compare incomparable things. Imagine an international football federation that brings together association football, American football, rugby, Australian rules football and all such things. And imagine this federation introducing common rules. What would this rule be? Right, "the game is played on a large field by two teams". Is there any practical use of this rule? No, every league will have to keep own "extensions". Despite often looking brain-damaged, footballers are clever enough not to invent common football rules. They realize that the term is overloaded, and they manage to disambiguate it. Grids brought together by PGI are as different as gridiron is different from soccer. Let's face it. They still can be played on the same pitch - meaning, they can use same hardware - but attempts to device common rules/specifications so far lead nowhere. It is as if gridiron guys would be keeping insisting that soccer has to be played with a ball that doesn't even look like a ball, and rugby folks would be agreeing, and soccer guys would be scratching their heads and meekly saying that their use case is actually to kick it with feet, not carry in armpits. The analogy is probably not exactly accurate, but I am quite frustrated, as I can see no progress whatsoever. Of the original PGI "creators" only three are still attending the meetings - Johannes, Aleksandr and myself. Any suggestions are welcomed. Cheers, Oxana

2 1

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

OGF PGI Use Cases - EDGI
by Etienne URBAH 16 Jul '10

16 Jul '10

Johannes, Morris and all, Concerning PGI Use Cases : I have improved and reformatted the 2 EDGI Use Cases with the 'PGI Software Engineering Use Case' template available at http://forge.gridforum.org/sf/go/doc16024?nav=1 : - 'Enforce Security of a Production Service Grid' is available at http://forge.gridforum.org/sf/go/doc16010?nav=1 - 'Marshal Activities from Service Grid to Desktop Grid' is available at http://forge.gridforum.org/sf/go/doc16022?nav=1 Comments and suggestions for improvement are welcome. 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

PGI Call today Agenda, Dial in information
by Johannes Watzl 15 Jul '10

15 Jul '10

PGI call today, Thursday 15 July 2010, 15:30 (CET): Agenda: (a) Discuss Use Cases and Use Case Template (b) Discussion of the whole document process : Which documents should OGF PGI produce, in which order, in which time frame, ... (c) Co-chair, Secretary positions (d) AOB Dial in information: https://www1.gotomeeting.com/join/890872960 Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. Austria: +43 (0) 7 20881407 Belgium: +32 (0) 28 08 4297 Switzerland: +41 (0) 225 3314 55 Germany: +49 (0) 898 7806 6464 Denmark: +45 69 91 88 70 Spain: +34 955329911 Finland: +358 942 599 697 France: +33 (0) 182 880 463 United Kingdom: +44 (0) 203 318 4725 Ireland: +353 (0) 14 845 983 Italy: +39 0553989569 Netherlands: +31 (0) 208 080 385 Norway: +47 21 04 29 13 Sweden: +46 (0) 313 613 559 Access Code: 890-872-960 Audio PIN: Shown after joining the meeting Meeting ID: 890-872-960 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

PGI call 2010-07-08 notes
by Johannes Watzl 12 Jul '10

12 Jul '10

Participants: Morris, Mark, Michael Saravo (new), Etienne, Johannes, Luigi, Michaela, Emmanouil notes by Etienne (16:00) and Johannes (15:30-16:00) Luigi: summarize the PGI progress -> added to the agenda (a) Johannes as new additional co-chair Morris: Secretary position vacant Requested a third co-chair (a.5) News from the OGF and workshop good progress on the requirements list somebody from gLite should look at the list because there was nobody present at OGF reorganization of glossary of terms on website (wiki) import from OGSA_BES and GLUE glossaries gone through the whole glossary on wiki and OGSA_BES action for Luigi: check requirements and glossary action for Morris: check if the document on gridforge isup to date Mark: what is the outcome? docuement of requirements? Morris: action: organize an output document (b) Debrief Use case Process and status Who send in use cases? Morris: according to usual process: we collected requirements collect use cases -> specification Actions ------- Chairs (Morris and Johannes): - Find a 3rd co-chair - Find a secretary - For the Requirements Spreadsheet : Check if GridForge contains the latest version. If not, then upload the latest version to GridForge - Give write access on GridForge to Emmanouil and Luigi so that they can upload documents - Next PGI telephone conference : Discussion not only on Use Cases, but also on the whole document process : Which documents should OGF PGI produce, in which order, in which time frame, ... Everyone can add comments to the template for Use Cases http://forge.gridforum.org/sf/go/doc16013?nav=1 - Etienne will add some comments Following people should upload their Use Cases following the template to GridForge http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docma… : - Emmanouil for Globus - Luigi for gLite - Morris for Unicore Following people should convert their Use Cases according to the provided template : - Etienne for EDGI - Aleksandr for ARC Next OGF PGI telephone conference on Thursday 2010-07-15 at 15h30 CET Review process for the Use Cases -------------------------------- Each member of OGF PGI may add comments to each Use Case. Options: # 1 - Compile one single draft document containing all Use Cases, everybody can comment this single document Vote YES by Morris, Mark Vote NO by Etienne : In order to enforce traceability when many people simultaneously add comments to the same document, only a simple text document under SVN is suitable, NOT a MS-WORD or OpenOffice document # 2 - For a while, keep 1 separate document for each Use Case in order to receive comments, later compile all of them into a single document Vote YES by Etienne, Aleksandr In order to manage modifications of a document by several people : - GridForge permits to put a separate lock on each document, - It is more efficient to manage a separate lock for each one of several separate documents than 1 single lock on 1 single big document. # 3 - Google Docs Vote NO by Etienne : That is NOT OGF groupware. Agreed process: Option # 2 Assume each Use Case document is on GridForge 1) Using GridForge, lock the document, then download it 2) Using a document editor (MS-Word, OpenOffice, ...), turn the 'track changes' option on, perform the changes, save the document 3) Using GridForge, upload the document, then unlock it 4) Inform the group via e-mail that there have been changes Deadlines : 2010-07-15 for everyone to make comments on each separate Use Case 2010-07-22 for the initial author to integrate comments on each separate Use Case -- _ _ _ _ _ _ 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