November 2005 - cddlm-wg

RE: [ogsa-wg] RE: One paragraph describing your expectations from the deployment component
by Milojicic, Dejan S 09 Nov '05

09 Nov '05

Hi Andrew, I presume we will have a chance to discuss this during the meeting today, but here is my attempt in summarizing what CDDLM has discussed this morning. > -----Original Message----- > From: Milojicic, Dejan S > Sent: Monday, November 07, 2005 8:31 AM > To: 'Andrew Grimshaw'; 'Andrew Grimshaw' > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org; > 'cddlm-wg(a)ggf.org' > Subject: RE: [ogsa-wg] RE: One paragraph describing your > expectations from the deployment component > > Thanks Andrew, > > We will get back to you before the meeting on Wednesday and > we can discuss it in more detail at the meeting. Thank you > very much for taking the time to summarize your expectations, > it will go a long way towards clarifying how CDDLM can > contribute to EMS. I am forwarding your email to the CDDLM > mailing list. > > Best regards, > > Dejan > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > On Behalf > > Of Andrew Grimshaw > > Sent: Monday, November 07, 2005 8:21 AM > > To: Milojicic, Dejan S; 'Andrew Grimshaw' > > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org > > Subject: [ogsa-wg] RE: One paragraph describing your > expectations from > > the deployment component > > > > Dejan, et al, > > > > There are two basic things that EMS needs (in my opinion): > > 1) The ability to identify on which hosts an activity can execute > > because either the executable for the activity is installed > - or CAN > > BE installed. > > 2) The ability to direct that the necessary components for > an activity > > be installed and configured in/on a container - whether that means > > binaries and libraries, licenses, databases, whatever. > > > > In both cases I do not want the activity started. > > > > Let me dive a bit deeper into both: > > 1) The information needed to determine where an activity > can execute - > > either directly, or after some deployment step is needed by RSS so > > that it can make scheduling decisions. While it is not sufficient > > information to make scheduling decisions, it is necessary. > (Other info > > could include load, whether a particular user has privileges or the > > necessary currency, etc.) By definition, CDDLM is not primarily intended to support this functionality. We think that some sort of information service should provide this information. Having said that, CDDLM can still provide some support in this direction (which is maybe 20% of what you need if not less): a) CDL can capture dependencies of deployed components on certain resources which can compared against what is supported on nodes (information provided by other means) and used to decide if/where you can deploy components, and b) CDDLM engines can return information on what has been deployed on them (this is not something that we have specified so far, but it naturally falls under CDDLM). > > 2) Once a placement decision has been made then we must ensure that > > the application/activity is ready to run on the selected container > > resource. In the current JSDL model - all of the information is > > carried in the executable information. > > For more interesting, non-legacy, components latter, it is > likely that > > the mechanism in JSDL will not suffice. Thus, something like: > > Deploy("name of application/component", "name of container > resource") > > > > Where each of the "names" are either path names in a > directory based > > service or EPR's of some sort. CDDLM is primarily focused on deliverying the functionality you have described above. You can take a look at how we utilize it using our deployment APIs, submission language, and component model. One should be able easily to wrap up our functionality to accomplish the interfaces and support requierment you outline in 2) above. Thanks, Dejan. > > Andrew

1 0

Notes from the Meeting on 11/9, 6am PST
by Milojicic, Dejan S 09 Nov '05

09 Nov '05

Attendees: Ayla, Jun, Steve, Stuart, and Dejan > 1. Update on the testing First, Jun presented his document on testing CDL. Jun suggested that he will provide the first version of tests by next week. Then Ayla updated us on UFCG testing. They are using existing tests, they also translate deployment APIs and component model tests into assertions. Ayla had some questions for Stuart that he will follow-up this afternoon. Next Steve discussed his testing. He suggested what testing they will do with SF as well a what kind of testing he would prefer (with assertions). He also mentioned AntUnit. Finally Stuart, is implementing test cases. He will not do assertion based tests. > 2. OGSA meeting in the afternoon (see attached agenda). We agreed on Q1 that we can draw the line anywhere; the answer to Q2 (deployment time), that this is a red herring, that we can provide some sort of support in subsequent versions of specs, but we it is not possible to give the 100% accurate answer. > 3. Andrew's email on EMS expectations from CDDLM (see > attached email by Andrew). We can do requirement 2 from Andrew's email, we can only fulfill small part of requirement 1. Dejan will follow-up by email to Andrew's questions. > 4. Even if early, planning next GGF (hotel reservations, what > do we plan to do at GGF, etc.) Hotel should be reserved before > 5. Continued discussions on interoperability. Dejan provided quick update on how it was done in IETF. Thanks, Dejan. > Please use our usual phone numbers: > > +1 866-639-4732 (toll free while in US) > Code 2362906 (followed by a '#' sign) > +1 574-948-0379 (toll & international) > > Thanks, > > Dejan. >

1 0

Testing
by Steve Loughran 09 Nov '05

09 Nov '05

This is my thinking on test-components. The advanced SFUnit stuff is just an idea right now; I need some more experience with AntUnit before designing it.

1 0

XML representation of CDL tests
by Jun Tatemura 09 Nov '05

09 Nov '05

Hi, Please find the attached slides for discussion on CDL tests in XML format. Thanks, Jun Tatemura NEC Laboratories America

1 0

Meeting tomorrow, 11/9, 6am PST
by Milojicic, Dejan S 09 Nov '05

09 Nov '05

Hi, There will be our usual meeting tomorrow. The following is tentative agenda, please let me know if you want to address anything else: 1. Update on the testing 2. OGSA meeting in the afternoon (see attached agenda). 3. Andrew's email on EMS expectations from CDDLM (see attached email by Andrew). 4. Even if early, planning next GGF (hotel reservations, what do we plan to do at GGF, etc.) 5. Continued discussions on interoperability. Please use our usual phone numbers: +1 866-639-4732 (toll free while in US) Code 2362906 (followed by a '#' sign) +1 574-948-0379 (toll & international) Thanks, Dejan.

1 0

[ogsa-wg] Proposed agenda for Nov. 9th call (CDDLM/ACS/GRAAP joint call)
by Hiro Kishimoto 09 Nov '05

09 Nov '05

Hi all, Apologies for cross-posting *ATTENTION* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST OGSA-WG revised charter draft has been accepted by GFSG with no change. Congratulations! https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-Charter-2005/… The following is a proposed agenda for OGSA-WG telecon on Nov. 9th Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1109 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (Nov. 7th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 Since SC05 is next week, can we have a quorum next week? Agenda bashing 2) CDDLM/ACS/GRAAP joint EMS discussion (60 min) > From F2F minutes; > - Action: Agreed on two-pronged approach for CDDLM(+ACS) on one > side and EMS on the other to describe their approaches in > more detail and to then unify those approaches. (Note > these are 3 separate actions.) > - Action(1): CDDLM team volunteered to look into two issues that > were identified as requirements and report back in an > OGSA call > 1. Where to draw the line in the (CDL) provisioning tree > (see above) > 2. How to provide the cost of configuration Dejan already sent out their discussion summary to the list; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/10/msg00026.html OGSA-WG has already reviewed their summary (see Nov. 7 minutes) and will give these feedbacks to them. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 > - Action (2): Andrew provide one paragraph describing his > expectations from the deployment component. (done) > Using this paragraph, CDDLM-WG provides a feedback on > how they match his expectations. Andrew's description; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00013.html > Actions(3): > - RSS-WG to produce abstract interface (and responsibilities) of EPS > and CSG. > - Clarify responsibilities/functionality of JM > - Andreas to send detailed EMS draft (pre OGSA 1.0) document to > Steven N. EMS team is working on "composition roadmap" https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/ > Action(4): Set up a team to explore WS_Agreements issues more, > especially relating to allocation and QoS assurance. And > come back to OGSA-WG on how to use WS-Agreement (possibly > evolved) with EMS. Clarify > - How WS-Agreement possibly needs to change to fit in OGSA > EMS > - Set the first review after 30 days; check what can be > done. > - Volunteers: Steven Newhouse (to lead), Dave Berry, Chris > Smith, (Jim Pruyne; not present >GRAAP-WG to confirm) 3) OGSA naming policy discussion (30 min) Tom will have the written proposal (agreed on the previous call) 4) Information model discussion (20 min) > Action: Andrew to review and point out what is needed for the > BES container > - Goal: A preliminary set of attributes that are > needed for the BES container 5) Common UML tool review (if time permit) > - Mike Behrens has some experience with a number of the listed > tools. He volunteered to check out the rest and give an > evaluation next week > - export/import as one required feature > > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 6) OGSA workshop at Israel Grid Alliance (if time permit) Steve Crumb ask us to send a rep to Tel Aviv before or after GGF16. > In my continued efforts to get an OGSA expert to Israel to discuss > the architecture to a primarily technical audience, Avner and I have > settled on the proposal of having an OGSA half-day workshop > immediately after (or before) the Athens event. This would allow for > someone to be roughly in the same geographic area making a quick, > one-day hop to Tel Aviv much more doable. 7) Wrap up AOB <NEXT CALL> Nov. 14 (Mon) OGSA-AuthZ joint call Basic Security Profile document review, Architecture & Glossary 1.5 Nov. 16 (Wed) EMS architecture, information model & CIM profile Nov. 21 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Component Model Test Plan - v.01
by Stuart Schaefer 08 Nov '05

08 Nov '05

Attached is a draft of the Component Model Test plan. Feedback is appreciated. Stuart

2 1

RE: [ogsa-wg] RE: One paragraph describing your expectations from the deployment component
by Milojicic, Dejan S 07 Nov '05

07 Nov '05

Thanks Ansdrew, We will get back to you before the meeting on Wednesday and we can discuss it in more detail at the meeting. Thank you very much for taking the time to summarize your expectations, it will go a long way towards clarifying how CDDLM can contribute to EMS. I am forwarding your email to the CDDLM mailing list. Best regards, Dejan > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Andrew Grimshaw > Sent: Monday, November 07, 2005 8:21 AM > To: Milojicic, Dejan S; 'Andrew Grimshaw' > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org > Subject: [ogsa-wg] RE: One paragraph describing your > expectations from the deployment component > > Dejan, et al, > > There are two basic things that EMS needs (in my opinion): > 1) The ability to identify on which hosts an activity can > execute because either the executable for the activity is > installed - or CAN BE installed. > 2) The ability to direct that the necessary components for an > activity be installed and configured in/on a container - > whether that means binaries and libraries, licenses, > databases, whatever. > > In both cases I do not want the activity started. > > Let me dive a bit deeper into both: > 1) The information needed to determine where an activity can > execute - either directly, or after some deployment step is > needed by RSS so that it can make scheduling decisions. While > it is not sufficient information to make scheduling > decisions, it is necessary. (Other info could include load, > whether a particular user has privileges or the necessary > currency, etc.) > > 2) Once a placement decision has been made then we must > ensure that the application/activity is ready to run on the > selected container resource. In the current JSDL model - all > of the information is carried in the executable information. > For more interesting, non-legacy, components latter, it is > likely that the mechanism in JSDL will not suffice. Thus, > something like: > Deploy("name of application/component", "name of container resource") > > Where each of the "names" are either path names in a > directory based service or EPR's of some sort. > > Andrew > > -----Original Message----- > From: Milojicic, Dejan S [mailto:dejan.milojicic@hp.com] > Sent: Wednesday, November 02, 2005 10:35 AM > To: Andrew Grimshaw > Cc: Hiro Kishimoto; Stuart Schaefer > Subject: One paragraph describing your expectations from the > deployment component > > Hi Andrew, > > At Boston, you agreed to provide one paragraph describing > your expectations from the deployment component. You have > articulated it at that time. Using this paragraph, we'll > provide a feedback on how we match your expectations. > > Can you please provide this paragraph to us? This is in > preparation for the OGSA meeting on 11/9 which CDDLM > participants will join. > > Thanks, > > Dejan. > >

1 0

CDL Testcase Presentation
by Stuart Schaefer 04 Nov '05

04 Nov '05

I did not receive Jun's document in my email, so I apologize for not having read it before our meeting. Here are my thoughts as discussed at today's meeting. 1) Use the RDF approach. CDL test documents should be specified as pairs. Pre and post parsing. Each of our DOM/XOM engines can spit out the final results of parsing as a CDL. 2) I don't think it is worth the time to create an automated "equivalence" tester for comparing the CDL provided in the test case output with the output of our own parser. We should be able to spot check results for compliance easily enough. Just my opinion. Document equivalence is more of an XML problem than a CDL one. 3) Is it possible to defer the lazy reference tests to the Component Model test phase? In CDL you need to simply verify that the document is properly formed, not that the value turned out as expected. That is the responsibility of the Deployment API and Component Model. Stuart

3 4

CDL test cases plan
by Jun Tatemura 02 Nov '05

02 Nov '05

Hi, Here is my current plan on CDL test case development: By Nov 9 meeting: - design of XML representation of CDL tests By Nov 16 meeting: - an initial version of XML representation of CDL test cases - a JUnit implementation that handles the test XML - an initial set of test cases -- failure cases; success cases matched with expected resolution -- a single CDL document for each test; no lazy resolution By the end of Nov we will adress: - how to treat multiple CDL documents (i.e. how to treat references in import) - how to treat lazy resolution (i.e. how to represent partially resolved documents) Thanks, Jun

2 1