[ogsa-wg] Meeting notes from the CDDLM meeting, Wed 10/12/2006, at 6am PST

[Milojicic, Dejan S]

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.