Hi Andrew,

I presume we will have a chance to discuss this during the meeting
today, but here is my attempt in summarizing what CDDLM has discussed
this morning.

> -----Original Message-----
> From: Milojicic, Dejan S 
> Sent: Monday, November 07, 2005 8:31 AM
> To: 'Andrew Grimshaw'; 'Andrew Grimshaw'
> Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg@ggf.org; 
> 'cddlm-wg@ggf.org'
> Subject: RE: [ogsa-wg] RE: One paragraph describing your 
> expectations from the deployment component
> 
> Thanks Andrew,
> 
> We will get back to you before the meeting on Wednesday and 
> we can discuss it in more detail at the meeting. Thank you 
> very much for taking the time to summarize your expectations, 
> it will go a long way towards clarifying how CDDLM can 
> contribute to EMS. I am forwarding your email to the CDDLM 
> mailing list.
> 
> Best regards,
> 
> Dejan
> 
> > -----Original Message-----
> > From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] 
> On Behalf 
> > Of Andrew Grimshaw
> > Sent: Monday, November 07, 2005 8:21 AM
> > To: Milojicic, Dejan S; 'Andrew Grimshaw'
> > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg@ggf.org
> > Subject: [ogsa-wg] RE: One paragraph describing your 
> expectations from 
> > the deployment component
> > 
> > Dejan, et al,
> > 
> > There are two basic things that EMS needs (in my opinion):
> > 1) The ability to identify on which hosts an activity can execute 
> > because either the executable for the activity is installed 
> - or CAN 
> > BE installed.
> > 2) The ability to direct that the necessary components for 
> an activity 
> > be installed and configured in/on a container - whether that means 
> > binaries and libraries, licenses, databases, whatever.
> > 
> > In both cases I do not want the activity started.
> > 
> > Let me dive a bit deeper into both:
> > 1) The information needed to determine where an activity 
> can execute - 
> > either directly, or after some deployment step is needed by RSS so 
> > that it can make scheduling decisions. While it is not sufficient 
> > information to make scheduling decisions, it is necessary. 
> (Other info 
> > could include load, whether a particular user has privileges or the 
> > necessary currency, etc.)

By definition, CDDLM is not primarily intended to support this
functionality. We think that some sort of information service should
provide this information. Having said that, CDDLM can still provide some
support in this direction (which is maybe 20% of what you need if not
less): a) CDL can capture dependencies of deployed components on certain
resources which can compared against what is supported on nodes
(information provided by other means) and used to decide if/where you
can deploy components, and b) CDDLM engines can return information on
what has been deployed on them (this is not something that we have
specified so far, but it naturally falls under CDDLM).
 
> > 2) Once a placement decision has been made then we must ensure that 
> > the application/activity is ready to run on the selected container 
> > resource. In the current JSDL model - all of the information is 
> > carried in the executable information.
> > For more interesting, non-legacy, components latter, it is 
> likely that 
> > the mechanism in JSDL will not suffice. Thus, something like:
> > Deploy("name of application/component", "name of container 
> resource")
> > 
> > Where each of the "names" are either path names in a 
> directory based 
> > service or EPR's of some sort.

CDDLM is primarily focused on deliverying the functionality you have
described above. You can take a look at how we utilize it using our
deployment APIs, submission language, and component model. One should be
able easily to wrap up our functionality to accomplish the interfaces
and support requierment you outline in 2) above.
 
Thanks,

Dejan.

> > Andrew