Hi Hiro and all, Please find the attached slide on CDL for BLAST. Please also see the explanation on the slides below. Unfortunately, I will not be able to attend the call today, and Dejan will likely not either. So can we postpone discussion to F2F and solicit offline feedback by then? Best Regards, Jun --- explanation on slides---- The first slide describes assumed environments, where a data center provides a cluster environment consisting of computing servers and file servers. The user has a code (BLAST) and data (BLAST database) somewhere and wants it ready to run on the servers at the data center. In this example, we focus on deployment, not provisioning. Here, provisioning means to reserve appropriate computing servers and file servers for the task. Given those reserved resources through provisioning, deployment is to the code ready to run, including mounting the file system to the server at an appropriate mount point as well as installing BLAST code and data. Then we design components for this environment in the next slide. It is desirable to design component interfaces so generic and abstract that we can reuse them for various deployment. A component for a file server lets you deploy your files and provides an ID, with which a server component can mount your files. You don't have to know what kind of technology is used or how it is physically provided (this may be a local storage device or remote network file system). The property ID is (@cdl:lazy) meaning that it is automatically assigned at deployment time (so the user is not supposed to set value). You will specify the data to be deployed (e.g. blastdata.tar) with the property cmp:CodeBase. A component for a (computing) server lets you mount the file system deployed above by specifying the ID. To refer to such a value given at deployment time, you can use @cdl:ref. We will see this in the next slide. The server component also lets you install your code under RootDir (which can be the real root '/' or a user home directory, depending on a particular implementation). The property RootDir is thus lazy so you can refer to the value later. The enviroment variables can be also specified through this component interface. The next slide shows how to compose a system for BLAST using the above components. @cdl:extends is used to refer to those components and @cdl:ref is used to refer to property variables. The next slide shows an example of parameterization. If you want to deploy BLAST many times with changing deployment parameters, you can create a template then inherit it for each deployment. In this example, you can specify a database file for each time. -------------------------------- Hiro Kishimoto wrote:
Hi all,
The following is a proposed agenda for OGSA-WG telecon on March 29th. Wednesday from 4pm to 6pm (CST).
Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815
Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0329 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html
1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Agenda bashing
2) April F2F meeting update (10 min) Revised meeting agenda is on GridForge: https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA-F2F-agend...
3) Security Architecture discussion (30 min) Scope, goal, and process discussion.
4) Information model discussion (30 min) Ellen will send out revised container info model (CIM profile) draft for review.
5) Joint CDDLM discussion (30 min) we will review Jun's CDL example document for BLAST job. Jun: Please send out CDL example document before the call.
https://forge.gridforum.org/projects/ogsa-wg/document/minutes-2006-03-15/en/...
6) Wrap up AOB
<NEXT CALL> April 3 (Mon): NO call
April 4-7: F2F meeting in San Francisco Bay Area
Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/