[ogsa-wg] Re: [cddlm] Basic POSIX Component & template draft

Hiro Kishimoto hiro.kishimoto at jp.fujitsu.com
Mon May 8 08:55:39 CDT 2006


Hi Steve,

Your file & filesystem components are very good. They are what
I am looking for. One more question I have in my mind is how to
set user-id, group-id, and permissions to deployed files.

Can you call in OGSA-EMS session on Wednesday?
It starts 5:45pm JST = 9:45am UK.

The dial-in number for this session;
   US:    +1 718 3541071 (New York) or
          +1 408 9616509 (San Jose)
   UK:    +44 (0)207 3655269 (London)
   Japan: +81 (0)3 3570 8225 (Tokyo)
   PIN:  4371991

Thanks,
----
Hiro Kishimoto

Steve Loughran wrote:
> Hiro Kishimoto wrote:
>> Hi all,
>>
>> Jun Tatemura and I took a home work assignment about "Basic POSIX
>> Component" for BLAST application deployment.
>>
>> Attached is my first-cut draft and hope to discuss at GGF17 OGSA EMS
>> session.
>> Please have a look and give your feedbacks before or
>> at the GGF17. Your feedbacks are very important.
>>
>> Thanks and see you in Tokyo!
> 
> 
> This is really good, and I do agree, we do need a set of foundational 
> things to deploy.
> 
> One thing I would argue, having learned the lessons of both Ant and 
> SmartFrog, is that a consistent model of file system components comes 
> first. That is, we need components to model
> 
> -files (with a liveness test that verifies the file is present)
> -paths (an ordered list of files/directories)
> -directories (with components that can create a dir on deployment, 
> optionally to delete it and its contents on termination)
> -wildcarded sets of files (**/*.csv)
> -temporary files and directories
> -cached downloads
> -text files
> 
> I'm attaching the PDF file describing the current smartfrog set of 
> components that do this.  The underlying way that this is done is that 
> all components that consider themselves to be sources of filenames/paths 
> set the attribute absolutePath at runtime. They usually also export an 
> RMI interface for RPC-style operations, along side their RESTy state.
> 
> A standard set of filesystem components lets you include the operations 
> to create and clean up directories, temporary files and other 
> housekeeping operations into the workflows of a deployment.
> 
> Looking at the Posix proposal, I'd suggest starting with the reusable 
> set of filesystem types, including a <fs:mount> component that could 
> mount a local or remote filesystem, and which would then pass the local 
> location to interested parties as the filesystem:absolutePath attribute.
> 
> You absolutely don't need to introduce a new shared datatype 
> FileSystemName, because that implies some kind of alternate 
> naming/locating scheme outside of what CDL and the runtime has built in. 
> Dynamic CDL references are sufficient to crosslink information inside 
> the graph of deployed things, and offer flexibility as well as ease of 
> management (you see them when you walk the graph).
> 
> First, we'd need filesystem types:
> 
> <tmp cdl:extends="fs:TempFileSystem">
>    <fs:Description> … </fs:Description>
>    <fs:DiskSpace>
>       <fs:LowerBoundedRange>10737418240.0</fs:LowerBoundedRange>
>    </fs:DiskSpace>
> </tmp>
> 
> <home cdl:extends="fs:Directory">
>    <fs:Description>Chris's home directory</fs:Description>
>    <fs:dir>/home/csmith</fs:dir>
> </home>
> 
> When deployed, both of these would add absolutePath as an attribute,
> so that tmp/absolutePath woudl resolve to, say, tmp/work01234/ and
> home:absolutePath to /home/csmith.
> 
> 
> You'd then mount a blast dir, say on an nfs filesys whose URL you provide
> 
> <blastfs cdl:extends="fs:RemoteFileSystem">
>    <fs:url>nfs://filestore/csmith/blast</fs:url>
>    <fs:mountUser>csmith</fs:mountUser>
> </tmp>
> 
> The database file is under here, and you declare that it must exist. 
> Deployment will fail
> if it is absent:
> 
> <db cdl:extends="fs:File">
>    <fs:dir cdl:ref="/tmp/absolutePath" cdl:lazy="true" />
>    <fs:filename>db/ncbiblast/est</fs:filename>
>    <fs:filemustexist>true</fs:filemustexist>
> </db>
> 
> 
> To use it, just refer to its path
> 
> <blast:database cdl:ref="/db/absolutePath" cdl:lazy="true"/>
> 
> Paths could be represented by some list-like element, whose entries are
> evaluated at deploy time and then a platform-specific path created as a 
> result
> 
> <path cdl:extends="fs:Path">
>   <pathentry cdl:ref="/blastfs/absolutePath" cdl:lazy="true" />
>   <pathentry cdl:ref="/home/absolutePath" cdl:lazy="true"/>
> </path>
> 
> On Windows /path/absolutePath would become something like
>   "\\filestore\csmith\blast;c:\documents and settings\csmith"
> while on unix it could be
>   "/nfs/filestore/csmith/blast:/home/csmith"
> 
> This information now goes down to the jsdl component
> 
> <jsdl-posix:Environment name="PATH"
>   cdl:ref="path:absolutePath" cdl:lazy="true"/>
> <jsdl-posix:Environment name="TMPDIR"
>   cdl:ref="tmp/absolutePath" cdl:lazy="true"/>
> 
> 
> -Steve
> 
> 
> 
> 
> 
> 
> 





More information about the ogsa-wg mailing list