October 2005 - cddlm-wg - lists.ogf.org

Last call for Application Contents Service Specification 1.0
by Keisuke Fukui 08 Mar '06

08 Mar '06

Folks in ogsa-wg, cddlm-wg and acs-wg, We, acs-wg, has come to completion of the ACS Specification 1.0 after discussions and reviews. This is the last call for comments before submission to the GGF Editor for publication. If you have comments, please get them to me by 9 am Japan time on Monday November 7. If there are no significant comments I plan to submit the document on Monday afternoon. Below is the link for the document: https://forge.gridforum.org/projects/acs-wg/document/draft-ggf-acs-spec-1.0… Regards, Keisuke Fukui ACS-WG co-chair

1 1

Notes from the meeting
by Milojicic, Dejan S 26 Oct '05

26 Oct '05

Attendees: Stuart, Steve, Ayla, Dejan. Notes taker Dejan. We discussed how to demonstrate that something constitutes a reference implementation. We suggested the following steps: 1. Individual components tests (every owner will contribute one). 2. Use cases: a) Single app b) Multi-tier, one machine c) Multi-tier, multi-machine 3. Optional: Grid computing apps (Blast, Globus) 4. Optional: Scale experiments Steve suggested that he will write a draft of the test components by next week, a more complete suggestion in two weeks. Everyone will write a dependency list that they have on other components so that we create a roadmap from now until next GGF. One good example of dependencies is component tests that should be available as early as possible so that reference implementations can test their compatibility. We do not want to track detailed plan of individual reference implementations although we want to have some sense of the overall progress we are making and whether we shall have reference implementations completed for the next GGF. Dejan will talk to Hiro today to find out about the proofs for interoperability and compatibility (if any). Thanks, Dejan.

1 0

CDDLM meeting tomorrow, Wed 10/26/2006, at 6am PST
by Milojicic, Dejan S 25 Oct '05

25 Oct '05

Hi Team, We shall have our weekly meeting tomorrow. The primary agenda item is creating a roadmap from now until next GGF, with the main objective of coming up with the reference implementations. Please be prepared to contribute to this roadmap. As usual, we shall use the following conference number: +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

deployment JAR changes
by Steve Loughran 25 Oct '05

25 Oct '05

I'm starting to make some changes to the JAR that gets built from the sourceforge repository 1. the constants we generate all use javax.xml.QName rather than a home rolled version. This will still build on java1.4 even though the class isnt built in till java1.5 provided you have one of the following on your classpath -something in apache xml-commons that implements this -xmlbeans itself This makes the generated stuff much easier to integrate with both xmlbeans and java1.5 code 2. I'm going to switch xmlbean generation off by default. Although the idea "common types" seems good for testing, in practise XMLBeans is not a good way to work with flexible XML datastructures, and it takes a long time to build them all. I will leave a way to turn this back on if you were using the beans that I was generating; I will myself be migrating away from them in the next couple of days. I've been giving the WS-A people a hard time about their lack of tests, apparently they have at least twelve now. If we can have more test data on XML-addresses that dont interop, send them to me and I will forward them with the appropriatly acerbic commentary, something like "life would be simpler if we stick to URIs" I've also been looking at the OGSA basic profile. What is our plan to adhere to that. I think an implementation can implement all of it alongside the spec itself, just by adding some more properties and implementing all the required operations. So we dont need to explicitly do it in our spec. This would stop us chasing a moving target. -steve

1 0

test
by Milojicic, Dejan S 19 Oct '05

19 Oct '05

1 0

FW: Meeting tomorrow cancelled
by Milojicic, Dejan S 19 Oct '05

19 Oct '05

Hi, I have not received this email that I posted at about the same time I posted the other one about deployment APIs entering public comment period. I wondered if it failed? I received the other one. Anyways, there will not be the meeting this morning. Thanks, Dejan. -----Original Message----- From: Milojicic, Dejan S Sent: Tuesday, October 18, 2005 9:29 PM To: 'cddlm-wg(a)ggf.org' Subject: Meeting tomorrow cancelled Hi Team, I have to cancel the meeting tomorrow because of the travel. I plan to have the meeting next week. If there is anything urgent, can you please hold the meeting without me. As a reminder, we discussed at GGF15 posting the tests for some of the remaining specs. Thanks, Dejan.

1 0

FW: CDDLM Deployment APIs in public review period
by Milojicic, Dejan S 19 Oct '05

19 Oct '05

Hi Team, Good news, the Deployment APIs are also in the public review period. Thanks, Dejan. -----Original Message----- From: sf-httpd(a)forge.gridforum.org [mailto:sf-httpd@forge.gridforum.org] On Behalf Of Sourceforge Tracker Monitor Sent: Tuesday, October 18, 2005 8:01 AM To: dejan(a)hpl.hp.com Subject: [ggf-editor | Submit GGF Draft - 1558] CDDLM Deployment APIs Greg Newby changed 1558 on 2005-10-18 07:01:19 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=1558&group _id=90 (https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=1558&grou p_id=90) Summary: CDDLM Deployment APIs Project: EDITOR Tracker: Submit GGF Draft Artifact ID: 1558 Category: Recommendations Track Group: Management Status: Public Comment Period Resolution: <None> Priority: 3 Last Modified By: Greg Newby Last Modified: 2005-10-18 07:01:19 Submitted By: Dejan Submit Date: * 2005-07-07 05:56:49 Assigned To: John Tollefsrud File(s): draft-ggf-cddlm-deploy-api2.doc, ggf-cddlm-deploy-api.doc Description: This document describes CDDLM Deployment APIs. The CDDLM framework needs a deployment API for callers to deploy services described in the component model languages. This API must support remote access for deployment, terminating existing deployed systems, and for probing their state. This document defines the WS-Resource Framework-based deployment API for performing such tasks. It is targeted at those who implement either end of the API. ---------------------------------------------------------------------- Comment By: Greg Newby (2005-10-18 07:01:19) (It will be due 60 days after it is publicly announced) ---------------------------------------------------------------------- Comment By: Greg Newby (2005-10-18 06:58:57) This is now ready for 60-day public comment. ---------------------------------------------------------------------- Comment By: John Tollefsrud (2005-10-17 21:17:41) I've read the document and recommend that it proceed to public comment. Note, there is a cut/paste repeat of several lines of text at the bottom of p.2. John ---------------------------------------------------------------------- Comment By: Greg Newby (2005-09-25 14:24:04) Thanks. This document is now in 15-day GFSG review prior to public comment. Because the GGF15 conference is next week, we will allow until October 18 for a GFSG decision. ---------------------------------------------------------------------- Comment By: Dejan (2005-09-16 16:02:54) We have adderssed all issues raised by the GGF editor. ---------------------------------------------------------------------- Comment By: Greg Newby (2005-08-30 09:02:48) Thanks for this submission. I have several items I would like to be fixed or responded to before moving this document to the next phase of the review process. First is that the header states this is an informational track document (GWD-I), but the tracker has Recommendations track submitted. Which is the intent of the working group? For these other comments, use the template in the Editor tracker, or a recently published GGF document, as an example: Second, please fill in the compete information for the 13 Editor section. Third, "12 Security" should be "12 Security Considerations." Fourth, the references nearly all need a lot of work. References need to be complete: - author (or corporate author) - title and (if applicable) volume - publication location (for online sources, the publisher/organization's location) For online materials, they may only be cited in the References section if they are persistent documents - not to Web sites or other transient content. For citation fo something like a WG's homepage or organization, use an inline reference or footnote, for example, in text: "The Global Grid Forum (http://www.ggf.org)" instead of putting the hyperlink in the References section. I don't think *any* of the references are complete, and several are simply hyperlinks that don't belong in the References section. Here is the rule of thumb for references: you need to provide sufficient information so that a future reader (say, in 10 years) can use your reference to find the exact same document you used in your authoring. If it seems unlikely the same document will be available (for example, because a Web page will have changed), then this might be a better candidate for inline citation or a footnote. Fifth, the GGF logo, copyright statement and IP notice are misplaced (see the sample documents), and you don't need to include the logo. Sixth, page footers are missing except on the first page (they don't need to be on the first page, but should be on the other pages). Email address, also page number. Seventh, the Status and Abstract headings don't match the rest of the document, or the GGF's other samples. I'm sorry for this big list of changes. As you see, none of them are focused on the content -- it's all about the presentation & formatting, consistently with the GGF standards. I did read the content, too -- to me, this appears to be a well-written document, and presents valuable information. Once you have re-submitted with the above suggestions addressed, we'll continue to advance it through the editor pipeline as specified in GFD-C.1. ---------------------------------------------------------------------- View the Submit GGF Draft : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=90&at id=414 (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=90&a tid=414) ________________________________________ Modify your monitoring preferences: https://forge.gridforum.org/monitoring/monitorPreference.php (https://forge.gridforum.org/monitoring/monitorPreference.php) Turn off monitoring for this Tracker: https://forge.gridforum.org/tracker/?group_id=90&atid=414&aid=1558&func= monitor (https://forge.gridforum.org/tracker/?group_id=90&atid=414&aid=1558&func =monitor)

1 0

Meeting notes from the CDDLM meeting, Wed 10/12/2006, at 6am PST
by Milojicic, Dejan S 12 Oct '05

12 Oct '05

Attendees: Keisuke Fukui, Jun Tatemura, Ayla De Souza, and Dejan Milojicic. Note taker: Dejan Milojicic > At the F2F meeting with OGSA, CDDLM had a couple of homework assignments. > > The first one was to sort out how does CDDLM interact with > ACS. We had some preliminary hallway discussions between > CDDLM people, Mike Behrens and Sachiko, but they suggested > that they would like to sync up with Keisuke prior to making > any decision. The options have been documented in a > presentation that Stuart prepared and gave at the F2F meeting > (either direct CDDLM-ACS interactions; through data services; > or through information services. I expect that someone from > ACS-WG can join us either tomorrow at our meeting or at some > other meeting in the near future. Keisuke presented the slides he posted earlier to the mailing list. Then we discussed which of the options of should work best for ACS, CDDLM, and other groups, such as CSG and RSS. The conclusion was that we do not need to be specific which information or services need to be combined. We defined interfaces for each services (ACS and CDDLM). As it is, the CDDLM and ACS relationship is appropriate. Options 1 and 2 does not make much difference (each spec doesn't explicitly specify I/F to be used for that). In a summary, we plan to leave the things as is, with the current specs on both sides unchanged. At the moment, they are closest to the option 2 (communication through data services). However, see also discussion below, which implies the interactions between ACS and CSG, even though it only relates to the data/information path between ACS and CSG and instead it is really about future services that CDDLM may offer. CSG interaction with ACS has not been discussed within ACS group, it is ambiguous and we believe that this was really the core of this whole controversy about the relationship between ACS, CDDLM, and CGS. It is about how CSG can obtain the information about the resource requirements and deployment time from the deployment descriptions, which is the topic of the next two items. > The second task item we had from the F2F was how can we help > provisioning services by providing an estimate of the deployment time. It is not possible, it could only be a hint. History is better source of this information. We could potentially, (from hints) resolve CDL by obtaining for each component the predicted deployment time, then from component graph calculate compound estimate (e.g. add times where components are serialized, return max where components are parallel, etc.). We will continue to explore these options. We do not plan to support this sort of functionality in the existing specs; we may want to support it in versions 2.0, or if it is urgently required, we can address it in a separate spec. This could be something called "Deployment Estimates Services" (DES). This will heavily depend on this information provided as a part of the CDL. These Deployment Estimates Services can also address the resource requirements, by having a similar run through the tree and adding up the resource required. . In addition to these offline services, we can provide the statistics about the run-time deployment time, by collecting time of the deployment of each component as well as overall time. These times can then be matched against the estimate times. Again, we do not plan to support this in the current versions of specs, but rather in the second versions or in separate specs. > The third task assignment was where do we stop in expanding > the tree (e.g. at the OS provisioning?) and how do we mark this. CDDLM (and CDL) are transparent to this. This is more matter of the policy and best practices. If further required, we can take this offline with Jay and come up with a proposal. > The last assignment was to see how we fit into Andrew > Grimshaw's view of provisioning. Andrew promised that he will > write-up a paragraph or so on his view and we will use that > to answer his concerns. We are still waiting for Andrew to provide one (or more) paragraph(s) description of how he sees deployment and we'll provide a feedback to his proposal how we match his expectations. > I expect to make progress on the first three topics tomorrow > morning PST (as well as the fourth if we receive Andrew's > paragraph in a timely fashion) and if we get some opportunity > we can present the outcome at the OGSA meeting tomorrow > afternoon (PST) or we can communicate the outcomes by email. We welcome an opportunity to go into more details on all these matters with the OGSA group. It is my understanding that we are not on the agenda for today. nor for the following meeting. Finally, we raised the issue of interoperability. It remains to be a major concern that the underlying specs that we depend on are not stable (WS-Addressing) or themselves do not have a full interoperability story in order for us to be able to demonstrate full degrees of interoperability. We expect feedback from Hiro on how IETF demonstrates interoperability so that we can best meet our target for interoperability demonstrations which is June 2006. Best regards, Dejan.

1 0

CDDLM meeting tomorrow, Wed 10/12/2006, at 6am PST
by Milojicic, Dejan S 12 Oct '05

12 Oct '05

Hi, At the F2F meeting with OGSA, CDDLM had a couple of homework assignments. The first one was to sort out how does CDDLM interact with ACS. We had some preliminary hallway discussions between CDDLM people, Mike Behrens and Sachiko, but they suggested that they would like to sync up with Keisuke prior to making any decision. The options have been documented in a presentation that Stuart prepared and gave at the F2F meeting (either direct CDDLM-ACS interactions; through data services; or through information services. I expect that someone from ACS-WG can join us either tomorrow at our meeting or at some other meeting in the near future. The second task item we had from the F2F was how can we help provisioning services by providing an estimate of the deployment time. The third task assignment was where do we stop in expanding the tree (e.g. at the OS provisioning?) and how do we mark this. The last assignment was to see how we fit into Andrew Grimshaw's view of provisioning. Andrew promised that he will write-up a paragraph or so on his view and we will use that to answer his concerns. I expect to make progress on the first three topics tomorrow morning PST (as well as the fourth if we receive Andrew's paragraph in a timely fashion) and if we get some opportunity we can present the outcome at the OGSA meeting tomorrow afternoon (PST) or we can communicate the outcomes by email. As usual, we shall use the following conference number: +1 866-639-4732 (toll free while in US) Code 2362906 (followed by a '#' sign) +1 574-948-0379 (toll & international) Thanks, Dejan.

2 1