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-agend... 4) Wrap up (10 min) AOB <NEXT CALL> OGSA-WG F2F Jan. 16-20. -- Hiro Kishimoto