GGF Session #1 Notes
Note
taker: Stuart Schaefer [Sschaefer@softricity.com]
Agenda Bashing - Dejan
-
Review specs, today foundation,
tomorrow SmartFrog, Friday XML
-
What are required changes
-
Make commitments to formally submit
-
Tomorrow do a demo of SmartFrog
-
Friday address relationship of CDDLM to
other WGs (OGSA, CGS, DAIS, DMTF Utility Computing, DCML, DMTF CIM)
-
Other specs
o
Basic services
o
Component model
-
Prototype implementations
-
Contributions to OGSA
Foundation Specification Review
-
Two external representatives have
reviewed the document thus far
-
Peter G. ask to ensure we review for
newbies what the spec is about
-
Purpose is to show other groups what we
are about
-
Kojo – process – thus is not a
normative document, it is an informative document, but we will still go through
the formal GGF process. We expect to
update it as we go along, though.
-
CDDLM is about three things – config
description, deployment, lifecycle management
o
Configuration is limited to the
deployment description only
§
WSDM is general purpose config
management
o
All functionality is in support of
deployment including lifecycle
-
Q: How do we draw the line between
applications and infrastructure?
o
Services vs. Resources
-
Q: Should we change Figure 2 to meet
OGSA definition within PE?
-
Functionality Requirements – One basic
service deployment with 3 requirements
o
Q: What about runtime change
requirements?
§
Presumed to be handled by WSDM
o
Q: Who is doing the description? Who is the beneficiary?
§
Operator has provided? SP or Developer.
§
Not clear who are the players
§
Need to add information from the slides
to clarify
o
Q: Supply and Demand of
services/resources. Will we make
recommendations of how to do this at runtime/dynamically?
§
The line will be split us vs. PE
-
Will we need to relax security
requirement as we are a privileged service?
-
Q: Give an example of services that
might be deployed through this?
-
GSI is not a ratified standard for
security yet, is careful on using it in our documents. Should be Grid Security.
-
Program Execution will be above us, but
we will be interdependent, so deploying PE will be non-trivial
-
Q: What about JXTA compatibility?
o
Do we need to bridge to these
interfaces?
o
The general move to WSRF will be
covering the differences in Web Services
o
Hiro: Change all Grid Services
references to Web Services
o
Be neutral to avoid needed to refactor
document
-
Use Cases
o
o
IT implies non-data center use
o
Utility Computing implies more frequent
changes
o
Complex Business Case implies heterogeneous
environment and requirements
o
Web Service deployment covers
development use – deployment is integral to the development process
-
Q: How we described functional
requirements differs from other groups
-
Q: Sufficient level of detail?
o
Be more specific on figure 6
o
Related specs: Drama(?), JSDL, GRAAP
o
Emphasize ability to handle large,
generalized systems – maybe mention other types of resources that we can handle
to clarify how generalized the problem we can solve is
-
Plans for formal submission
o
Make changes from GGF
o
Put to mailing list/GridForge
o
Submit to GGF
o
Q: Is the document self-standing
without SmartFrog?
o
Q: Are you only focusing on OGSA
things?
§
Yes and no – yes this is GGF, but there
are multiple reference implementations coming or in existence
§
Document seems too focused on OGSA
§
Dejan: Can we mention in the document
that its use is broader?
·
We don’t build shoes. We build tools to build shoes.
Jem Treadwell defines Provisioning
-
Owns the OGSA glossary
-
The CDDLM team will define these terms
-
Q: Do we need brokering to make
scheduling/allocation? No, it is part of scheduling.
-
Stuart: Would want to make sure that we
provide interfaces for lifecycle management even if we are not ultimately
responsible
-
Dejan: Does the OGSA Glossary imply
source and responsible party for a term/system?
GGF Session #2
Note
taker: Stuart Schaefer [Sschaefer@softricity.com]
SmartFrog system review
-
Deployment descriptor leaves hard
decisions to end by using lazy binding
-
Dejan: this spec has implications on
the underlying basic services specification?
Do we need any more information in the spec to cover?
o
Security
o
Generic needs vs. implementation
specific
o
Runtime mapping from language to
service needed
-
Dejan: Once we identify these
requirements, what is the delta of SmartFrog to the Grid model?
-
Dejan: What is missing? What could be improved?
-
Nakata-San: How do I deal with
discoverable or runtime arbitrary numbers/config?
o
An implementation detail of the
component, but the framework can handle it
-
Sun: How about moving files around as
part of deployment?
o
Contained in the configuration data,
but not necessarily in the spec
-
Dejan: Should basic services and
runtime cover these issues?
o
Under the covers they support, where
does it go
o
Language spec is sufficiently narrow
-
Q: Modify the examples to take on Grid
services flavor to show how the spec should be used more clearly
-
Relationship between syntax and
semantics
-
Once we do the XML spec, we should find
dependencies
-
Keep the separate specifications to
keep the size of the document down
-
Q: How tied is SmartFrog to some
configuration assumptions? Can it be
used for non-deployment needs?
o
Yes, but you are deep in the runtime
o
At the moment, you can use the Open
Source Linux system for whatever you want
o
Language is independent of the
deployment system
CDDLM-WG, Minutes,
Note
taker: Daniel Templeton, don.templeton@sva.com
Takashi Kojo, kojo@bk.jp.nec.com
SmartFrog Language Spec., Peter Toft
SmartFrog is in use for 7, 8 years at HP. Its CDL provides
way to
describe how to deploy applications. CDDLM needs descriptive
Language and SF is just an option.
Peter described the language along with the Language Spec.
Document.
2. Purpose of the document
To present one
language specification
3. Notion
Component model of
the CDL does not depend on the language.
Component is just
generic attribute set.
4. Requirement of the language
To provide
description of components, support for
Parameterized attribute, inherit template.
5. Syntax
Component is a
collection of attributes
SF language allows
hierarchical attribute definitions
Attribute pairs are
ordered.
Uses inheritance
semantics
Scope of References
PARENT,
ATTRIB, ROOT, THIS
Q: How important is this structure?
A: It's very useful in practice. Composability is very
important.
Q: Is inheritance critical? Is it doable in XML?
A: It's very useful, and feasible to do in XML.
Supports references
among elements/attributes
Attributes are
addressable using a path-like notation
LAZY references are
not resoled at compile-time
Q: Who decide timing of resolution?
A: It is resolved when the tool find it during deployment
phases.
Q: How natural is it to support SF language constructs in
XLM?
A: We will generate a document.
Parameterization
can be used to simplify initialization of complex structures.
Allows #include
which can be assigned context.
Top level attribute
set is called "main".
Language Semantics
Transformation
is 3 steps:
Type,
placement, link resolution
Functions
Q: Is there way to generate system unique names?
A: Use next
Q: System unique name space across deployments is difficult.
A: Names are only for installation, configuration.
Multi-systems
are not an issue.
Configuration Definition Example
Steve Loughran
described an Example of configuration definition.
Q: What are the implications for the underlying services?
A: The current spec. is less implementation specific than
before.
A: This spec. has no implications on the underlying systems.
Q: LAZY has implications on deployment systems, for example.
A: That is a general implication, independent of this spec.
Q: What is the delta between SF and final language spec.?
A: <No Answer>
Q: Can SF describe arbitrary containers, such as 2 or more
services?
A: Yes. It's really an implementation detail of the
component.
Q: How to describe how to move installation files around
A: Not a part of the language spec. It's part of the
runtime/deployment spec.
Q: Shouldn’t the example be about grid instead of web
services?
A: Let's do the grid example as an additional example.
Q: How to handle various language spec relationships?
A: Single ref doc with several binding docs?
Q: Can I just take this language and use it independently?
A: Yes, except the things like LAZY binding.
A: Yes. There's an open source version available that only
needs a JVM.
A: The open source version can give back a fully resolved
document or
a set of Java
objects.
Q: Is the document sufficient enough? Is there any missing
piece?
A: Description about provisioning.
A: Semantics regarding with deployment service and run time.
A: After taking all the feedback today, we would like to
submit
the document.
GGF Session #3
Note
taker: Stuart Schaefer [Sschaefer@softricity.com]
Agenda Bashing
-
Review previous meetings
-
Inform group about afternoon meeting
concerning relationship of CDDLM to other WGs
Main Topic – CDL XML
-
Introduction to CDL and CDDLM for SOA
-
Design alternative for attribute sets –
[Alt-1] verbose is easier to implement
-
Some discussion on schema validation –
alternative is to not require any schema, and allow xsd:any to rule the day
-
Q: Why not just use XML Schemas? Did schemas make things too complicated?
o
Stuart votes for anything which allows
the full extent of XML and XSLT and other tools to be used
o
Steve votes for doing paper testing on
usability of 1 vs. 2
o
Jun will write up some examples based
on SmartFrog examples
-
Talk to JSDL team about how they are
defining content locations
-
Q: Where are we defining the security
credentials of a service to logon under?
Is JSDL doing this?
-
Q: With lazy references, why do P2P
resolve references?
o
Do not need to define at language level
-
Q: What about redefinition or
re-configuration of system structure at runtime?
-
Q: Are we putting deployment semantics
into the language?
-
Q: What are we responsible for?
-
Q: What about order dependencies?
o
Does it need to be encoded in component
description?
o
Do we let users tinker with state?
o
All that is relevant to this group is
exist/non-exist, bound or unbound
-
Whatever language we end up with should
be easier to use than WSDL
-
Q: What is the relevance of this? Isn’t there anything else out there that does
this?
More Agenda Bashing
Note
taker: Peter Toft peter.toft@hp.com
CDDLM Notes: GGF11, Session 3,
Discussion of the XML-based language
Also see the slides that were
presented by Jun.
Introduction: this is a
discussion, rather than a finalised spec.
Setting the scene: background
about components and component services: the notion of resource can be
hierarchical. A Linux server can be a resource, and app server running on a
Linux server can also be a resource.
Each resource provides a
component service which allows the resource to be configured and controlled,
and an accompanying component template. Component templates are combined and
specialised to create complete deployment requests. When a deployment is
requested, resources are allocated, then the deployment proceeds using the
component services.
Language discussion: XML
alternative codings:
Rather like WSDL. Import and
include are like SmartFrog’s but may need to be more specific.
Q. The scope of the uniqueness
of QNames is the nominated namespace.
There are two alternatives to
attribute encoding presented (Alt-1 and Alt-2) – basically one generic schema,
versus schemas for each component. One is easier to implement, but harder to
use – the other is the opposite. It was observed that this is the same as the
choices in SOAP section 5 encoding.
A drawback of Alt-2 is the
requirement for defining schemas, though we could escape to admitting arbitrary
XML (and hence make schemas effectively optional).
Jun’s opinion is that we
should focus on Alt-2, maybe including Alt-1 as an alternative.
Q. The obvious question is why
not just use standard XML schema – why can’t you just use XML for this. We need
justification for why we take this approach that makes the case for not just
using XML. After all, XML is fairly extensible. [Inheritance and variable
linking needed?]
We need to think about who
will write these documents? Will tools generate this code or humans? WSDL is
unreadable but useful.
Jun will write some examples
that help us compare the alternatives.
Mapping to the component
model:
Comment: There is an interface
to the JSDL group in terms of how we specify how to identify the file/application
content.
Discussion of deployment
ordering, and startup processing (start, deploy, …).
Comment: how are circular LAZY
references resolved?
There is an issue around
redeployment – how can we restart one component in a system, without affecting
the complete system?
Security: who owns component
services? Are the components our own, or are they considered to be
infrastructure. There are different security considerations. We believe that
both models should be supported, but we’re not sure how to do this yet. We need
to understand how what we are doing maps onto the underlying security models.
How does JSDL do this? JSDL
does not support any specific mapping to security models.
Attribute constraints for
consistency. Discussion about whether semantics of deployment should be
reflected in the language (e.g. lifetime and requirement for the presence of
certain attributes).
Discussion of encroachment of
our scope on the management domain, also overlap / potential to use OGSA
services for status monitoring/recovery (so we should map onto this).
Discussion of whether to
include pre-conditions / ordering of lifecycle management operations in the
language level: do we incorporate / delegate this to policy management
services, or do we build components that embody this dependency management in a
deployment component. Comment that we should leave this out for now, maybe
address in a later phase.
Dependencies and assertions.
Actions:
◊
Put more of
background materials up on GridForge
◊
Generate
more content around motivation and alternatives: e.g. Peter to put some more
detail about alternative data description languages
GGF Session #4
Note
taker: Stuart Schaefer [Sschaefer@softricity.com]
Agenda Bashing
Any Groups missing from our invited list
-
CMM is now WSDM and CMM
-
CIM is the product of DMTF, there is no
DMTF CIM group
Our relation can be administrative or
architectural/interface
Q: How much are you thinking about the networking, such as
path provisioning?
-
Dejan: Not. As a group it is not our primary objective. It can be added later.
Q: Are any of the group related to workflow management
-
Dejan: Just need to relate to others to
make sure there is no confusion
-
WFM-RG, EG-RG
Q (CMM) : What is the work that is required?
-
What are the interfaces involved?
-
How do we manage resources?
Q: What is DMTF Utility Computing doing?
-
Creating a UML Model repository of
configuration management information
-
All DMTF groups are working on the MOF
and profiles for CIM classes
Dejan introduces what the group is doing…..
Q: We should do everything in CIM? Anything missing from CIM should be sent to
the DMTF?
-
Jen: There are alternate ways. CIM does not contain all of the attributes
that this group might need.
Q: What about JSDL or PE?
-
Both are early and we are hoping to
work with them?
Volunteers to work with groups
What kind of timeline do we want? 4 weeks to interact and come back with a
report
-
Relationship summary
-
Conflicts, overlaps, holes, different
views
-
Synergies
-
Plans of action, if any
Q: What kind of resources are you thinking of deploying
-
GT3, services, something simple to
start and then move on from there
Q: Do you see the group going wider to provisioning
bandwidth and other things?
-
We would like to complete this issue
first.
Dejan: What do you think about the overall process? PE is
going slow; we are hoping to be aggressive?
-
Should find
-
PE seems to be crystallizing
-
SmartFrog is almost complete, XML spec
is coming along
Q: How is this used to deploy services? A Web Service or just its infrastructure?
-
Both
Q: You mentioned under-provisioning. How are you going to be responsible for this?
-
We are not. Just a conduit to decision making authorities
-
However, we often have best local
information
Q: How are we going to interact with PE?
-
Don’t know. PE is all over the place.
Q: What is the focus of the group? How does it overlap with DAIS?
-
No overlap seems to be here
Q: CGS – CIM Grid Working Schema – extending CIM to meet
Grid needs
DMTF – CIM model and interface with the Open Group
-
Have a model to look at lifecycle of
applications. The Applications Working
Group is looking at this. That group has
SAP, Oracle, etc….
-
This seems very valid to what we are
doing. Can we work with this group? It seems very relevant. Where do we liaise?
-
Can we make sure that this is a
two-way. There are weekly phone calls on
Tuesday and Thursday. Ask Andrea
Westerinen. Follow up with Karl
Schopmeyer
CMM
-
You are talking about deploying
services
-
WSRF is taking over a good bit of what
WSDM is doing
-
What is the model of managing a live
web service?
What about WSRF liaison?