CDDLM-WG Session #2
-------------------
Basic Service Specification
(See slides)
Q: Basic Services or Basic Service
A: Bsaic Services
Q: What will they be called?
A: CDDLM Basic Services
Q: What about Basic Deployment Services
A: Save this discussion for later
O Agenda
Q: Do we want to expose what happens behind the scenes?  E.g., the fabric onto which the service is deployed
A: We want to hide the details as much as possible unless necessary, such as the fabric
O Structure of CDDLM
Q: What is the relationship between a component and a service?
A: Component is the model, service is the implementation of the model.
Q: Is the model that deployed components map to service endpoints?
A: Yes
Q: So, services are component implementation
A: Yes, but component is an implementation of the deployment service...
O Simplest Deployment
  o CDDLM assumes several external components
    * Not important how they are implemented
Q: We would like to discuss job submission with JSDL people
A: Not really JSDL's purpose, but sure.
O Simple Deployment
O Advanced Reservation
  o This is just one example from many possible approaches
O Re-provisioning
  o Assumes redeploying something already deployed and running
Q: How do we proceed when there are so many other working groups in these same spaces?
A: For the moment we can ignore everything outside of the CDDLM interface
Q: We still don't know the list of questions, such as whether CDDLM is stateless or not.  Do we plan to make a list of options and what are we going to do with the list?
A: All these other pieces of the scenarios are only for validation of CDDLM.
Q: Why does the return go through CDDLM (see slide)
A: Because CDDLM has to keep track of everything
A: This is just one possible option
A: CDDLM is not fire-and-forget.  It needs to know when things end so it can undeploy.
Q: State is optional
A: State is not optional because components can be managed through the entire component lifecycle, which requires state
Q: Job manager can maintain the state instead of CDDLM
A: That still counts as CDDLM... We'll argue about it later
  o The point here is to prevent spending several hours starting up before realizing that it can't be done
O Implementation Notes
O Relationship btw CDL and BS Lifecycle Management
  o From Jun's slides
O Relationship bwt Component Model and BS
O System Structure
  o From Jun's slides
<More of Jun's slides>
O Service Propogation Rules
  o The question is how we can identify a set of components to which a service can be applied.
Q: Which makes sense, and what do you want to move forward on?
A: Uh? No commont.
  o Many of these have already been implemented by SmartFrog
    * Not introducing complexity -- it's already there in SmartFrog
  o More sophisticated models
  o Exception handling is also a potential source of complexity
    * Mitigate by using a plugable execution handler
O Services
O Service Interfaces
O Deployment Profiles
Q: What are the basic services?  Can we agree on them?  Deploy, undeploy, maybe reconfigure...
A: Those are basic internal services
Q: I expect CDDLM basic services to be what CDDLM offers to the world.  What are those?
A: 2 services: register for deployment and deployment.  Undeployment is elsewhere
A: Deploy (with flags) and Undeploy.
A: Good if Basic Services looks like a component, we can aggregate.
A: Deploy and Undeploy are fundamental.  Others come from components
Q: What then about reconfiguration?  Is it WSDM's problem?
A: Hard to do generically.  No right answer.
Q: When we do these specs and we identify issues, what is the required level of stability for submission?
A: It's up to you.  If you declare it's done, it's done.  You can publish errata for small issues.  Big issues require resubmission.  To prevent problems, understand your scope.
Q: If we come out with a 1.0, can we then come of this a 2.0 the next year?
A: Sure.  Don't submit something you know will be out of date before end of the public comments.
Q: We need to nail down minimum required services and minimum required deployment attributes
A: That's a little more than we had planned for
A: Implementation will help with definition
Q: Can we do some kind of JSDL integration demo for next GGF?
A: JSDL has no API, but you can integrate our XML at will
Q: The purpose of the demo is to show cooperation.  Are you guys interested?
A: Sure
Q: Back to reconfigure/change.  Include it as a basic service?
A: Dangerous.  Very hard to do generically.
Q: What kind of changes do we want to allow?  More or less reprovisioning?
A: That's one category
Q: I.e. additional components to deploy
A: Yep
A: There are some change scenarios that make sense generically, but it's complicated
Q: The plan is to verify definitions through demos
A: Yes
Q: Should CDDLM be resource aware or not?  Does CDDLM parse resources?  Fundamental design decision
A: Must know what resources onto which we're deploying
Q: Can't that be pushed off to a local resource manager?  Does CDDLM need to know about things like number of processors and memory?
A: Need to know where a service is going, but beyond that, maybe not.
Q: What exactly are we asking?
A: Do we get a list of resources that CDDLM can qualify and deploy services to intelligently, or does CDDLM just get a mapping of services to resources from some other service
A: Let's assume we're given a mapping