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@cs.cardiff.ac.uk> To: Andre Merzky <andre@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@merzky.net] Sent: Wednesday, June 04, 2008 2:48 PM To: Steven Newhouse Cc: Andre Merzky; ogsa-wg@ogf.org; ogsa-hpcp-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg -- Nothing is ever easy.
Date: Wed, 04 Jun 2008 16:35:13 +0100 From: "Omer F. Rana" <o.f.rana@cs.cardiff.ac.uk> To: Andre Merzky <andre@merzky.net> Subject: Re: [ogsa-wg] Grid Command Line interfaces
Hi Andre,
Thanks. It might be useful to understand the relationship between
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@ogf.org [mailto:drmaa-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: Wednesday, June 04, 2008 11:49 AM To: Omer F. Rana Cc: drmaa-wg@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): 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@merzky.net] Sent: Wednesday, June 04, 2008 2:48 PM To: Steven Newhouse Cc: Andre Merzky; ogsa-wg@ogf.org; ogsa-hpcp-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg -- Nothing is ever easy. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
DRMAA is narrowly focused on offering an API, but as was already pointed out, as soon as you have a Perl binding (which we do), the API itself also becomes a set of commands. Daniel Andre Merzky wrote:
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@cs.cardiff.ac.uk> To: Andre Merzky <andre@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@merzky.net] Sent: Wednesday, June 04, 2008 2:48 PM To: Steven Newhouse Cc: Andre Merzky; ogsa-wg@ogf.org; ogsa-hpcp-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
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@cs.cardiff.ac.uk> To: Andre Merzky <andre@merzky.net> Subject: Re: [ogsa-wg] Grid Command Line interfaces
Hi Andre,
Thanks. It might be useful to understand the relationship between
We are still half way through - there is no help option (no options in the classic sense) that is expected in command line tools and it is still an API flavor interface ... plus few conveniences. On the other hand - the Perl/Python API offers an easy stepping stone for building a set of OS and DRMSs portable command line tools. Hrabri -----Original Message----- From: drmaa-wg-bounces@ogf.org [mailto:drmaa-wg-bounces@ogf.org] On Behalf Of Daniel Templeton Sent: Wednesday, June 04, 2008 3:14 PM To: Andre Merzky Cc: drmaa-wg@ogf.org; ogsa-wg@ogf.org; Omer F. Rana Subject: Re: [DRMAA-WG] [ogsa-wg] Grid Command Line interfaces DRMAA is narrowly focused on offering an API, but as was already pointed out, as soon as you have a Perl binding (which we do), the API itself also becomes a set of commands. Daniel Andre Merzky wrote: 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@merzky.net] Sent: Wednesday, June 04, 2008 2:48 PM To: Steven Newhouse Cc: Andre Merzky; ogsa-wg@ogf.org; ogsa-hpcp-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
participants (3)
-
Andre Merzky -
Daniel Templeton -
Rajic, Hrabri