[graap-wg] meeting schedule update (Re: [ogsa-wg] Ad hoc calls on Jan. 12th)

[Hiro Kishimoto]

Hi all,

Based on the morning discussion, I've switched ByteIO and OGSA-data
in the Thursday morning.

There are two more the last minutes change requests we should discuss
tomorrow;

- Thursday afternoon
Switch GRAAP joint session and Arch & Glossary 1.5 session, since Jim
Pruyne will come mid afternoon.
- Wednesday afternoon
Move WS-management Profile discussion from Friday Morning to Wednesday
afternoon and push naming session later.

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

Thanks,
----
Hiro Kishimoto

Hiro Kishimoto wrote:
> Hi all,
> 
> We will have an ad hoc call for F2F meeting preparation
> on Thursday. The following is a proposed agenda.
> 
> ATTENTION: day of week, time, dial-in number are all different.
> 
> Date: Jan. 12th Thursday
> Time: 8-10pm (CST) = 6-8pm (PST) = 11am-1pm JST = 2-4am UK
> 
> The dial-in number:
> US Toll number:  +1 408-961-6509 (San Jose) and
>                  +1 718-354-1071 (New York)
> UK Toll number:  +44 (0)207 365-5269
> JP Toll number:  +81 (0)3 3570 8183
> The pass code:   4371991
> 
> Screen share service will be provided.
>   URL:         http://ogsa.glance.net
>   Session key: 0112
> 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
>         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.