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.