[ogsa-bes-wg] [ogsa-wg] Proposed agenda for <DATE> call

Hiro Kishimoto hiro.kishimoto at jp.fujitsu.com
Mon Jan 9 00:24:57 CST 2006

Hi all,

I hope you and your family had a good holiday break and are
looking forward to the new year.

The following is a proposed agenda for OGSA-WG telecon on Jan. 9th
Monday from 4pm to 6pm (CST).

The dial-in number for Monday;
   Free: +1-866-639-4741
   Toll: +1-574-935-6703
   PIN:  8980700

Screen share service will be provided.
   URL:         http://ogsa.glance.net
   Session key: 0109
See more explanation:

1) Early discussion (10 min)
         Note taker assignment
         Roll call
         Telecon minutes approval (Dec. 19)
         Do we have Jan. 11th telecon, since several people will be at
         GFSG F2F meeting?
         Agenda bashing

2) CDDLM-WG joint call (60 min)
         Jem has uploaded the revised version to the GridForge.
         - http://tinyurl.com/aez86
         Look forward to proofread and tracker verification.

(1) Deployment and configuration section break-down
> == Proposed list of sections ==
> 3.1 Provision (Deploy) an application on an existing BES container
>     (The application can then be used to instantiate a BES activity.
>         Mostly what is now 3.2 in EMS Architecture composition.)
> 3.2 Provision a BES container
>     (What is now 3.1 in EMS Architecture composition)
> [Both 3.1 and 3.2 assume that the 'level' of the BES container is
> pre-determined and fixed. See below.]
> 3.3 Using ACS do 3.1
> 3.4 Using ACS do 3.2
> [Both 3.3 and 3.4 assume that the 'level' of the BES container is
> pre-determined and fixed. See below.]
> 3.5 Add time predictions to provision 3.1 and 3.2 by a deadline
>         Using a deployment estimation service (perhaps based on
>         historical data, etc, but how the estimation is done is
>         out-of-scope.) Possibly requiring reservations.
> [3.5 assumes that the 'level' of the BES container is pre-determined
> and fixed. See below.]
> 3.x Determine dynamically the optimal level of 'BES container' in the
>     system and provision containers appropriately depending on
>     workload etc
>         may depend on analysis of the entire application CDL (down to
>         hardware) for the entire workload of the system; use
>         deployment time predictions; etc
> <<Version 1 of the document could just cover scenarios 3.1-3.5 and
> discuss 3.x as future work. Otherwise need to breakdown 3.x further.>>
> ==

(2) - Deployment versus provisioning requirements
>      (Or, where to 'cut' the CDL tree. Above the 'cut' point is
>      deployment---assumed to be a relatively 'light' operation---and
>      below is provisioning---assumed to be more heavy-weight.)
>     - Deciding the cut point is orthogonal to CDDLM---it is policy or
>       best practices and is therefore a system choice
>     - Information (metadata) to help in making the choice could be
>       added to the CDL as mark up
>     - CDDLM implementations have walked the tree fairly far down (to
>       the hardware) for deployment
>     - CDL may be sufficient to express both deployment and
>       provisioning. But it is an open issue if these two activities
>       can, or should be unified in this way in OGSA. In particular CDL
>       may not be going to the full extent of supporting costing, etc.,
>       that maybe needed to address all requirements
>       - Resources beneath the cut point can be considered as
>         pre-provisioned: they either exist or they don't. They are not
>         going to be deployed themselves; but they can be used to
>         deploy on.
>       - Which resource to choose for deployment? It is the choice of
>         the EMS architecture (EPS, CSG) and not of CDDLM.
>       - Discussion on how CDL may be viewed as a hierarchy of scripts;
>         and that one could have a history of costs associated with
>         each node. In other words the tree could be decorated with
>         other information (cost, etc, as metadata)

(3) - JSDL and CDL relation and can one cover the requirements for the
>     other
>     - A JSDL submission may be associated with a deployment
>       description or request, and the deployment portion could be
>       described in CDL. [I.e., CDL could be a more specific
> application
>       sub-type in a JSDL document.]
>     - JSDL is not intended to describe the configuration of the
>       software that will be used by the job. The aim is to describe
>       things at a higher level. There may be similarities between the
>       languages (perhaps around resource description) but it does not
>       mean that one language can, or should, replace the other because
>       they serve different purposes.
>     - Jay wants to pursue the issue further among a smaller group of
>       people.

3) OGSA F2F meeting update (30 min)
         Session leaders: Please provide your goals and detailed agenda.


4) Wrap up (10 min)


OGSA-WG F2F Jan. 16-20.
Hiro Kishimoto

More information about the ogsa-bes-wg mailing list