[ogsa-wg] Proposed agenda for Jan. 9th call

[Hiro Kishimoto]

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:
http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html

1) Early discussion (10 min)
         Note taker assignment
         Roll call
         Telecon minutes approval (Dec. 19)
https://forge.gridforum.org/projects/ogsa-wg/document/minutes20051219/en/1
         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.

https://forge.gridforum.org/projects/ogsa-wg/document/2005Winter_F2F_survay
https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agenda

4) Wrap up (10 min)
         AOB

<NEXT CALL>

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