Hi all, I'd second this request - I learned that we are supposed to provide middleware-specific use cases (which sounds a bit odd for me), and I couldn't find out what is the status of requirements, and how do the use cases relate to them. Regarding use cases: in my experience, they are provided by *users* (surprise, surprise ;-) ), and every middleware should be able to address the same use case(s). The proposed split of use cases per middleware suggests that middlewares are inherently non-interoperable because they address different use cases. Is this the new approach (no interoperability needed), or is the goal to find overlapping use cases? Cheers, Oxana 01.07.2010 14:38, Balazs Konya пишет:

Hi PGI,

I heard from the nordugrid people that many things had happened during the productive OGF29 sessions. I was wondering if meeting notes containing decisions are available somewhere? Or the decisions are implicitly contained in the google document?

bye, Balazs _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

Hi Balazs, all, below the notes from the sessions and the workshop (day 1) in Chicago. I have been to Italy for another meeting the last days. Morris has taken notes from the second day - I was editing the document. Best, Johannes PGI session 1, OGF29, Chicago participants: Morris, Johannes, Kazushige, Etienne, Aleksandr, Michaela, Mark, Wolfgang Ziegler, Andre indtroduction round poster by Etienne starting with requirements list 1: Andrew disagreed XML rendering before GLUE Alexander: bring to GLUE Morris: lack of people in the GLUE group talking with them about timelies agreement ### 3: Etienne: related to GLUE Mark: control heterogehous resources Etienne: differenece betwee execution service and endpoint which is just a queue Aleksandr: numerous endpoints Mark: endpoint GLUE specific? Aleksandr: no Mark: endpoint means epr? then completely disagree Etienne: if you have one WS-addressing Alex: why do we want to bind ourselves to an addressing service? Mark: just an example Etienne: GLUE totally agnostic about the transport mechanism XML description of the endpoint Aleksandr: no accessity for this requirement Morris, all: refining the requirement; depicting structure of requirement to make clearer discussion about GLUE endpoint homogenous vs. heterogenous changing to: A GLUE endpoint can describe only one job submission interface (e.g. BES). Job submission interfaces which have different properties must be captured by separate GLUE computing endpoints. agreement ### 9: Mark: why prohibit anonymous execution Aleksandr: every service should require encrypted connection personally vote no changing to X.509 on TLS (mandatory option, allowing others) Alex: not seeing why it is necessary agreement ### 10: Mark: why limit to IGTF Aleksandr: out of scope Morris: out of scope out of scope ### 11: proceed with 12 ### 12: Morris: would drop it out (too general) ### 13,14,15,16: out (just options) ### 17: Etienne: can we propose that it must accept one of the X.509 proxies, Full X.509) Morris: difficult to agree on in that sense Aleksandr: should note that SAML is just a syntax Etienne: who really requires SAML? SAML out of scope because of its complexity agreement ### 18: out (it is a policy) ### 24: Aleksandr: out because its up to the implementation postponed, no agreement ### 25: postponed ### 26: postponed ### 27: out (practically impossible) ### 33: Morris: meta model always contact them first not defined, assumed Aleksandr: deep negative impact on interoperability Etienne: either must be an information service providing security information for endpoints or endpoint must provide its own security info through public interface postponed ################################################# Session 2: 38-41: Etienne: do not agree with current title requirement for security audits Mark: logging must be kept Morris: rename to logging information must be kept and must be made available out of scope (remotely logging is out of scope) Mark: make statement: logging is out of scope of PGI efforts in JSDL activity instance ### 42: Mark: implementation detail strongly disagree Morris: out Etienne: relationship with the GLUE model out (too strict) ### 47: Mark: out out (not in accordance in distributed systems design) ### 48-54: Etienne: execution service must stay always the same rename Mark: why requiring? Etienne: implication on what is a job id Mark: what job id is is a specification postponed ### 55: Mark: it is a definition not a requirement renaming PGI does not deal with job workflows, job collections agreement ### 56,57: agreement ### 58: Morris: out bacause collcetions are out of scope Wolfgang: how do you define collections Morris: jobs with one common id change to "should not" agreement ### 59: Aleksandr: think we do not need this requirement Etienne: we must state what is in and out of scope of PGI ### 60: duplicate to 55 ### 69: postponed #################################################### session 3: 70: no, don't need filters ### 71: out (complementary efforts in JSDL activity) ### 72: Aleksandr: about extensible state Morris: one mandatory state model - PGI model but other models based on this Mark: not going to do state model substating like BES does? Aleksandr: parallel stating, not substating Morris: not the intetion in this requirement Mark: reword it yes ### 73: Etienne: complex queries, vote no execution service should be as simple as possible Morris: not needed out (not needed) ### 74: Morris: could rephrase it Mark: talking about getting the list of activities yes ### 75: Etienne: execution of the job can be completely opaque to the user user never interacts with the job out (manual data staging required) ### 76: Aleksandr: just opposite of 75 Etienne: if I am only one, then yes. don't want to block group agreement yes ### 77: out (implied in 76) ### 78: Morris: different understanding of the states Mark: definitely agree with this requirement Etienne: propose to rephrase the requirement Aleksandr: should we have this in requirements yes ### 79: yes ### 80: Aleksandr: would vote yes rephrase to suspend yes ### 82: Aleksandr: some elements should be allowed to be ignored Mark: create optional requirement within JSDL yes ### 83: yes ### 84: Mark: we disagree part of original BES spec, common use case for us you could just not use it rephrase Mark: potential value add for GENESIS yes ### 85: Etienne, Kazushige: no, because of complexity Morris, Mark: should be optional Aleksandr: how define finished state? rephrase yes ### 87-89: postponed ##################################### PGI Workshop after OGF29, Chicago participants: Morris, Aleksandr, Michaela, Kazushige, Johannes, Mark, John, Giuseppe, Andre 90: Morris: who voted no? yes 91: Michaela: contradiction to 90? Mark: 91 you have to do it before you create activity Aleksandr: you cannot return id Mark, Morris: like 92 more execution service should have control over it Morris: 92 is on top of 90 91,92 out ### 93: rephrase Mark: requirement is out, should be downgraded to may or can Etienne: if we want this requirmenet we have to describe it vote, majority needs it Aleksandr: could implement it as an extension ### 95: Mark: implementation details Morris: out, because non-functional ### 96: Etienne: related to the model of stability of the endpoint Morris: get an idetifier back that points to the second Mark: if activity migrates around you don't have to track WS-naming is the answer Etienne: sequence diagram Morris: does not need to be an epr Aleksandr: if you migrate different services may choose different ways to create eprs postponed ### 97: postponed ### 98: Morris: seems to also go into this direction Etienne: still vote no in order to keep the client simple Morris: no postponed ### 99: Morris, Etienne: duplicate to 84 ### 103: Morris: would say yes Etienne: would vote no agreement on yes ### 104: Aleksandr: don't know if it is a requirement Etienne: would like to change some into any yes ### 105: Aleksandr: 101 duplicate/subset of 105 yes ### 106: skip, postponed ### 109: Morris: structure needs to be somehow more GLUE John: equivalent of cleaning up BES yes ### 110: Mark: what is the real requirement here? Aleksandr: ranges of JSDL better description or simpler structure Mark: we should not go too far away from JSDL this would break compatibility Giuseppe: how would PGI effect JSDL Mark: official response from JSDL: they welcome extensions Morris: it is our task currently we are only at the ranges Aleksandr: ranges are most confusing structure in JSDL we should do it in order to avoid confusion later Etienne: current sentence is a statement not a requirement Morris: rephrase who says yes? two yes who says no? two no postponed ### 111: Etienne: more precise understanding? out, softwareengineering design principle ### 112: Morris: who is voting no? yes ### 113: postponed ### 115: postponed ### 117: Mark: seems a little out of scope out (not required) ### 126: Aleksandr: we have in ARC but nobody really uses it Etienne: not require it strongly, but some users need it yes ### 127: Etienne: my interpretation logs of activity must be kept to permit security audits Mark: execution service cannot keep logs forever Aleksandr: if service wants to purge job it should keep some intermediate state remembering only the id Mark: yesterday decided logging and bookkeeping is out of scope Morris: rephrase it Etienne: would vote no Morris: who is saying yes postpone ### 129: out ### 130: out (implementation specific) ### 132: Mark: rephrase, default state should not be hold Morris: targetting the time after creating activity yes ### 133: Morris: someone saying no? Etienne: yes, because much too complicated yes ### 134: agreement - yes ### 135: out (too vague) ### 136: Mark: reword duplicate ### 137: Etienne: if you request hold points then the execution service should say if holdpoints are accepted or not 137,138,139,140: out ### 141: Morris: duplicate? John: 141, 142 seem already be handled duplicate ### 143: Mark: maybe listed as discussion starting point we should agree on some subset protocols Morris: rephrase keep as an example ### 151: out (already agreed) ### 153: postponed ### 155: out (non-functional) ### 157: Etienne: would vote no becaus XML specific Mark: should use global Grid namespace out ### 161: out ### 162: out (too specific) ### 163: out, duplicate ### 164: out, duplicate ### 167,168: out (too specific) ### 170: andre: can be different ways, also state out agreement on: no more reproposals ####################################################### afternoon session participants: Joel, Etienne, Aleksandr, Mark, Andre, Johannes, Morris, John, Kazushige Morris: how to proceed? Etienne: go for the problem of stability of service endpoint and activity id Morris, Mark: activity id too complex to discuss Morris: dedicate person to requirment Mark: everybody should have the chance to prepare and look over the others 11: Etienne: everybody has to agree on GLUE let us use the type use GLUE as foundation discussed agreed to yes ### 24: Mark: we must have a common way for clients to authorize agreed upon not to use one of x,y,z Morris: we would need a security expert can try to talk to EMI experts is Duane available, made good work Mark: not any more question makes sense to list the options 24,25,26: Morris writes 1 page Etienne: currently European providers not use SOAP ### 33: Morris,Mark: assumed is a bit weak agreement: out (not in scope) ### 48-54: Morris: volunteers? different understandings Etienne: 3 ways initial endpoint is also responsible to manage it until the activity is finished and forgotten disadvantage: the single endpoint for whole activity duration becomes a bottleneck Aleksandr: no Etienne: advantage: activity id can be completely opaque Aleksandr: we don't have activity id defined Morris: my proposal would be Etienne prepares a one page document Etienne: look at the diagrams to undestand Aleksandr: was already discussed on the mailing list we have different approaches doing things the spec we are going to produce should accept all the ways Etienne: already sent input Expert input - Etienne cover also 168 ### 69: out (implementation specific) ### 87: Expert 1 page (Luigi) ### 88,89: Morris: routing and forwarding completely different drawn 3 or 4 pictures already Etienne: do not understand these two and why they are different must be completely transparent to the client Aleksandr: don't see requirement here Etienne: publish through different computing endpoints Aleksandr: just statements Morris: we should have these request routing capabilities Expert 1 page (Morris) Aleksandr, Etienne: deployment question ### 96,97,98: 96: Expert 1 page (Etienne) 97,98: Expert 1 page (Morris) andre: understand the options why is it a requirement why user should be able to contact end of the path? ### 196: Morris: Mark? John: who needs it? Aleksandr Expert 1 page (Aleksandr) ### 110: Expert 1 page (Mark) ### 113: Etienne: executable is defined by the path propose to replace arguments by list of arguments Expert 1 page (Aleksandr) ### 115: Expert 1 page (Aleksandr) Mark: remember the discussion on the telecon couple of things it was extremly clear some people disagre strongly Etienne: what means scalable time? Mark: which benchmarks? Andre: your backend understands what benchmarks mean, Aleksandr? Aleksandr: yes, if benchmark published then in can John: mandatory? Etienne: there is some mail exchange by Etienne and Oxana Morris: point Aleksandr to these mails Joel: least common denominator musts and mays andre: could go to JSDL and post extension point Morris: change BES, JSDL,... Joel: strong desire of Etienne. Is it an absolute must? Morris: list mixed musts and mays Joel: it is always a good idea to do the absolute musts first ### 127: Expert (Aleksandr) ### 153: Mark will do it ### 168: already assigned to Etienne ### Morris: go into the mays and musts Joel: maybe some musts could be changed to shoulds each of the production Grids implement Morris: too many mays the spec will be useless andre: right, but otherwise maybe hard to implement Morris: go through to priorize ### 1: Morris: merge 1 and 2 2 is duplicate of 1 extend 1 Andre: you will update PGI profile when new version of GLUE comes out? Morris: get rid with "most recent" rephrase 1 ### Etienne: first must define terminology, state model Andre: cannot define a state model out of the blue Mark: iterative process Joel: planned output several options: one doc several docs? Morris: one PGI profile several specs that will come out? Joel: show use cases that you would like to address show me the PGI use cases with separate document with use cases easier to agree easier to iterate on Morris, Andre: not really time to create use case document Joel: would make sense to have it, but lack of time and manpower Mark: we are not time bound Joel: if each production Grid infrastructure provide their top use cases and then share with each other and take half of a phone call what's trying to be solved Mark: explain where did the requirements come from Andre,Johannes: requirements come from use cases Mark: many requirements go with one use case let everybody produce use cases bring together Joel, Mark: ist there a use case for the requirement? Morris: use cases Joel: having the mapping use case - requirment would help bringing in the other players Morris: tomorrow? Etienne: go through vocabulary wiki Mark: benefit referencing the OGSA glossary GFD 120 Am 01.07.10 12:38, schrieb Balazs Konya:

Hi PGI,

I heard from the nordugrid people that many things had happened during the productive OGF29 sessions. I was wondering if meeting notes containing decisions are available somewhere? Or the decisions are implicitly contained in the google document?

bye, Balazs _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

-- _ _ _ _ _ _ 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