OGSA Teleconference - 22 June 2006 ================================== * Participants Michel Drescher (Fujitsu) Hiro Kishimoto (Fujitsu) Takuya Mori (NEC) Darren Pulsipher (EMC) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Marvin Theimer (Microsoft) Jem Treadwell (HP) Pete Ziu (Northrop Grumman) Minutes: Andreas Savva * June 12 minutes approved with no changes * June 15 minutes approved with no changes * Action items review - Andreas will categorize OGSA 1.5 issues and send the list to Dave Snelling. - Done, waiting for response. - Review at next "OGSA 1.5" call. - Andreas and Hiro to talk offline about how to start sending ical invitations. - Done. - Andreas will send an email to the list explaining where the calendar is and what invitations will be sent out. - Jun will correct the CDL XML examples written by Hiro. - No update. - Hiro will probably move the review teleconference to another day. - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) (postpone until June 22) - Andreas has read it. - Bring to people's attention again at the next EMS call. - Add sequence diagrams to the scenarios: (postpone until June 22) -- Andreas will do the "Install application" scenario (3.1) -- Mike will do the "Install application using ACS" scenario (3.3) -- Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas has started doing the sequence diagrams in RSM - Darren volunteered to help out - Review again at the next EMS call - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 22) - Review again at the next EMS call. * Roadmap (postponed) * Authorization (postponed) * BSP Public Comments Reviewed public comments and Takuya's proposed replies 1. Add text explaining that the Secure Channel profile is not required by all ogsa services. The introduction is probably a good place for this. 2. [Basic-Security-Profile] usage. The term is defined in the document. Takuya to check whether such special terms are used consistently and that they stand out. Refer to the WSRF BP for a similar example. 3. Ciphersuites: Agreed that it important to list acceptable ciphers. - As a first step Takuya will list up available ones (from the WS-I BSP); select the ones that are in common use; and then select the ones that are considered sufficiently safe. - Review the list at the next BSP teleconf 4. Multiple keys in keyinfo field? - Takuya to talk to Von in order to understand the use case for multiple keys; and will propose a resolution at the next BSP teleconf. The next BSP review is set for the June 29 teleconference. * Information Model rendering discussion Started with the question of whether a rendering discussion is the right discussion to have. Concluded that talking only about the rendering overlooks more important issues: what the intermediate model should be and how it should be derived. One question is whether it is possible to define tags with semantics sufficiently pinned down to offer users the guarantee that a correct choice will be made when placing a job. For example, what does the system guarantee the user when a job requesting a box with "OS=Linux" (possibly of a specific version). There is enough variance to match with a box that advertises itself in this way but will not be able to run the job for other reasons (configuration etc). And vice versa other boxes that could potentially run the job may be missed. There was some discussion on various lists (BES, JSDL) already about the feasibility of defining equivalence classes but it is unlikely that anything like that can be done in the near term. The best that can be done is to define such terms while leaving some of the details unsaid (in the manner of JSDL). There is a tension between trying to describe something precisely while allowing the necessary looseness. Another issue is how to define the set of terms that people will actually want to use. There are many successful systems that are based mainly on user defined tags (or, equivalently, pre-configured queues that guarantee some kind of resource configuration) that are mainly site specific. It may not be possible to define these tags normatively however. So one key decision for the intermediate model is whether it should be driven by site-specific/defined information; or whether it should be driven from precise definitions like CIM. - There has been success for both sides (noting that Condor successes are often linked to also providing concrete specifications) - Informal definitions might not work across sites and this is a big issue for interoperability. - One community driven way forward would be to set up a framework to define combinations of capabilities; but this is likely to take a long time. GGF has published work with JSDL 1.0. The model is known to have deficiencies but captures a small set of common resource descriptions. The terms & concepts are a distillation of terms already in use at a number of sites running Globus, Unicore, (and to some extent Condor). - There is a compliance issue. For example, what does it really mean to say that a system is JSDL 1.0 compliant? What should the users expectation be and can the vendor deliver accordingly? - CIM has some experience in this area. It precisely enumerates known features (but there is no notion of (algorithmic) equivalence classes). Tentative consensus that both approaches are needed. It is important to be careful not to promise more than can be done with JSDL style resource descriptions. And that keeping these fuzzy to some extent does that. Also that user defined tags are needed. Since JSDL already allows the inclusion of user defined tags (xsd:any) the next question is whether there is a need to also define a framework for users to define their tags or to leave this completely open. Tentative consensus that defining a (or some) generic element with associated well defined matching semantics to allow users to add their own tags is a good idea. Marvin is working on a proposal for such an element and will post it to the relevant list(s). - Jay is also probably thinking along these lines so some offline discussion between Jay and Marvin might be good. - The proposal should be sent mainly to the OGSA Information Modeling team since they are the drivers of this work. And also to JSDL and BES; the other stakeholders in this process.