Notes from
CDDLM-WG Working Session 1 @ GGF11
Date:
June 7th,
2004
Author: Peter
Toft
Introduction (Dejan):
Overview of the CDDLM meetings for this week
Advance notice of the WSDM introduction session (Fred Maciel) –
important for understanding the relationship to CDDLM. 4pm Tuesday
8th.
Presentation of
the XML CDL specification (Jun):
Jun’s
presentation:
-
Cddlm introduction /
review
-
Mapping into the provisioning
cycle
-
Model for
deployment
-
CDDLM Document Suite – foundation
document, SmartFrog-based CDL, XML-based
-
Configurable
components
-
Use of CDL for individual
configurable components
-
Systems: compositions of
components
-
Deployment
services
-
The two CDLs: SmartFrog and
XML-CDL
Note that the SF CDL is intended to
be more user-friendly / user-tractable, while the XML CDL is more standardised,
is the interop format (i.e. we can translate from various front ends into the
XML form), but is less user-friendly to use
directly.
Q. What is the “truth” of the
configuration, what is definitive? Is it SmartFrog CDL or is it the XML CDL into
which SmartFrog is translated?
A. Various front ends can be used,
output from all can be captured as XML; they are just different representations
of the same logical constructs.
Q. Is XML CDL a front-end language,
also?
A. XML CDL is intended to be a
common interop CDL, into which we can translate a number of front-end languages.
It could also be used directly as a front-end language. It is not clear that the
reverse translation is possible; probably not.
Walk through the
specification:
-
Modes of attributes (required,
automatic, …)
-
Use of the automatic keyword – note
this probably means we cannot translate from XML CDL -> SF, though there are
similarities with LAZY. This is discussed in the appendix of the
specification.
-
Inheritance
mechanisms
-
References are done using XPath –
examples are in the presentation and in the
document
-
References: using
functions
-
Import: we use generic URIs, so we
can import remotely from http servers.
-
Discussion of relationship between
CDL and Basic Services L/Cycle Management.
Q. “Cyclic” components – e.g.
retrying a component until some state is achieved – can these semantics be
accommodated?
A. Yes, if we develop deployment
components that embody these special semantics; that interpret their
configuration data in ways that give you the desired deployment
behaviour.
Comment: Note that (unlike in slide
30), in SF we actually decouple deployment sequencing from reference resolution
sequencing – so actually they are independent. We step components through their
lifecycle in an orderly fashion for this very reason – so that components can
make certain assumptions about the state of the rest of the components at
various phases in their lifecycle.
Q: Are there problems related to
time: time for deployment, handling exceptions when things don’t happen in
time?
A. Again, we can build component
deployers that embody these semantics – e.g. have a timeout which results in
component undeployment if the component has not terminated in a given time
period.
Q What are the next steps:
A. Check that we can translate from
SF to CDL XML. Create examples in the XML CDL to add to the
document.
Q: Should we be pushing out our
documentation more frequently?
A, / Comment: Put more work into the
working group; limit the number of unfinished documents we push
out.
Advance notice of our proposed
workshop at GGF12.