[DRMAA-WG] [ogsa-wg] Grid Command Line interfaces

Wed Jun 4 12:12:43 CDT 2008

No, we were not planning to going in that direction ... but it could be
proposed - see DRMAA survey.

Hrabri

p.s. Hi Rana - it was a log time ...

-----Original Message-----
From: drmaa-wg-bounces at ogf.org [mailto:drmaa-wg-bounces at ogf.org] On
Behalf Of Andre Merzky
Sent: Wednesday, June 04, 2008 11:49 AM
To: Omer F. Rana
Cc: drmaa-wg at ogf.org
Subject: Re: [DRMAA-WG] [ogsa-wg] Grid Command Line interfaces

Well, DRMAA is an API specification as well, so does not
really define command line tools in the spec.  There are a
number of tools available, but I am not qualified to say if
the DRMAA group intended to have a complete API mapping, or
plan to standardize these tools, etc.

Cc to the DRMAA group, maybe they have input on the topic...

Quoting [Omer F. Rana] (Jun 04 2008):
> Date: Wed, 04 Jun 2008 16:35:13 +0100
> From: "Omer F. Rana" <o.f.rana at cs.cardiff.ac.uk>
> To: Andre Merzky <andre at merzky.net>
> Subject: Re: [ogsa-wg] Grid Command Line interfaces
> 
> Hi Andre,
> 
> Thanks. It might be useful to understand the relationship between
these 
> and commands provided
> in DRMAA perhaps? Just a thought.
> 
> best wishes
> Omer
> 
> Andre Merzky wrote:
> >Hi Omer
> >
> >Quoting [Omer F. Rana] (Jun 04 2008):
> >  
> >>Hi,
> >>
> >>Doesn't DRMAA already do this?
> >>
> >>Andre: I thought the aim of SAGA was to provide a programmatic
> >>API rather than a command line tools interface?
> >>    
> >
> >Of course, you are perfectly right.  However, several people
> >(including our won group) use SAGA for the purpose to write
> >such command line tools (which are then middleware
> >independent), and thus we considered mappings from the SAGA
> >API to command line tools since quite a while...
> >
> >Best, Andre.
> >
> >  
> >>regards
> >>Omer
> >>
> >>Steven Newhouse wrote:
> >>    
> >>>It may make sense to define common tools for job:
> >>>
> >>>Submit
> >>>Status
> >>>Terminate
> >>>
> >>>I'm not sure what broader interest we would have to do generic SAGA

> >>>commands.
> >>>
> >>>Steven
> >>>
> >>> 
> >>>      
> >>>>-----Original Message-----
> >>>>From: Andre Merzky [mailto:andre at merzky.net]
> >>>>Sent: Wednesday, June 04, 2008 2:48 PM
> >>>>To: Steven Newhouse
> >>>>Cc: Andre Merzky; ogsa-wg at ogf.org; ogsa-hpcp-wg at ogf.org
> >>>>Subject: Re: [ogsa-wg] Grid Command Line interfaces
> >>>>
> >>>>Quoting [Steven Newhouse] (Jun 04 2008):
> >>>>   
> >>>>        
> >>>>>>is a SAGA command line binding something you would
> >>>>>>conider worth pursuing?  We actually started to do
> >>>>>>something like that, in a pet project...
> >>>>>>       
> >>>>>>            
> >>>>>Do you mean the ability to implement any defined command
> >>>>>line interface using the SAGA APIs? (i.e. internal to the
> >>>>>command) Or To define a set of command line tools to cover
> >>>>>elements of the SAGA API?
> >>>>>     
> >>>>>          
> >>>>The latter.  For example, for the SAGA call
> >>>>
> >>>> class saga::filesystem::file
> >>>> {
> >>>>   void copy (saga::url src, saga::url tgt, it flags);
> >>>> }
> >>>>
> >>>>define the command line tool
> >>>>
> >>>> saga_file_copy [flags] <src> <tgt>
> >>>>
> >>>>     flags:
> >>>>       session related flags
> >>>>         -s|--session <s>   run command in session s
> >>>>         -c|--context <c>   use context c
> >>>>
> >>>>       operational flags
> >>>>         -a|--async=<Sync|Async|Task>
> >>>>                             use async mode Sync, Async or Task
> >>>>                             default is Sync
> >>>>       call specific flags
> >>>>         -r|--recursive  copy recursively
> >>>>         -o|--overwrite  overwrite target if exists
> >>>>         ...
> >>>>
> >>>>So, the command line tools would basically reflect what we
> >>>>define in the SAGA API spec, with a set of flags which are
> >>>>consistent for all command line tools such defined.
> >>>>
> >>>>
> >>>>A session could look like:
> >>>>
> >>>> # saga_create_context --name=my_context --type=UserPass
--user=anon
> >>>> <prompts for password>
> >>>>
> >>>> # saga_create_session --name my_session --add_context=my_context
> >>>>
> >>>> # /bin/date | saga_file_cat --session=my_session --write
> >>>>gsiftp://localhost/tmp/in.dat
> >>>>
> >>>> # saga_file_copy --session=my_session
gsiftp://localhost/tmp/in.dat
> >>>>gsiftp://remotehost/tmp/out.dat
> >>>>
> >>>> # saga_file_cat  --session=my_session
gsiftp://remotehost/tmp/out.dat
> >>>> Wed Jun  4 14:43:27 CEST 2008
> >>>>
> >>>>
> >>>>or, with some default assumptions of course (default session
> >>>>and context):
> >>>>
> >>>>
> >>>> # /bin/date | saga_file_cat --write gsiftp://localhost/tmp/in.dat
> >>>> # saga_file_copy gsiftp://localhost/tmp/in.dat
> >>>>gsiftp://remotehost/tmp/out.dat
> >>>> # saga_file_cat  gsiftp://remotehost/tmp/out.dat
> >>>> Wed Jun  4 14:43:27 CEST 2008
> >>>>
> >>>>
> >>>>Best, Andre.
> >>>>
> >>>>PS.: As for option (a) of yours: yes, that would be trivial to
> >>>>    implement in SAGA :-)  Well, at least it would be easy (one
> >>>>    needs to add some magick for state management, to keep track
> >>>>    of async ops and security credentials between separate calls
> >>>>    to different tools.
> >>>>
> >>>>   
> >>>>        
> >>>>>Steven
> >>>>>     
> >>>>>          
> >>>>--
> >>>>Nothing is ever easy.
> >>>>   
> >>>>        
> >>>--
> >>> ogsa-wg mailing list
> >>> ogsa-wg at ogf.org
> >>> http://www.ogf.org/mailman/listinfo/ogsa-wg
-- 
Nothing is ever easy.
--
  drmaa-wg mailing list
  drmaa-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/drmaa-wg
-------------- next part --------------
An embedded message was scrubbed...
From: =?iso-8859-1?Q?Peter_Tr=F6ger?= <peter at troeger.eu>
Subject: [DRMAA-WG] Call for action - DRMAA NG survey
Date: Wed, 21 May 2008 12:33:27 -0700
Size: 3468
Url: http://www.ogf.org/pipermail/drmaa-wg/attachments/20080604/f3c78556/attachment.mht 