[saga-rg] Comments on the job API (revision 1.4)

[G.E.POUND at soton.ac.uk]

Quoting Andre Merzky <andre at merzky.net>:

>
> Hi Graeme,
>
> Quoting [Graeme Pound] (Mar 07 2006):
> >
> > Andre Merzky wrote:
> > >Hi Graeme,
> > >
> > >Quoting [Graeme Pound] (Mar 07 2006):
> > >>I am afraid that I find this a little bizarre.
> > >>
> > >>As I understand it; job_service.get_self() returns a representation
> of
> > >>the _local_ client application which has instantiated the job_service
> > >>object (is that correct?). This would allow the client application to
> > >>perform operations upon itself via the 'job' interface.
> > >
> > >Exactly! :-)
> > >
> > >We call those applications to be 'Grid aware', but I am not
> > >sure if that is a good term.  However, the app 'knows' it is
> > >running in a Grid, and can actively perform actions, also on
> > >itself.   For example it can migrate itself, if there is
> > >need to do so (think agents).  Also, it can spawn copies of
> > >itself, to perform some partial analysis (it gets the job
> > >object for self, it gets the job description from that, and
> > >resubmits that description with some changed parameters:
> > >ergo the app gets cloned).
> > >
> > >I think taht the concept opens a range of very dynamic
> > >scenarios...
> >
> > Andre,
> >
> > I really do not like this concept. It has been added as an aside to the
> > jobmanagement package but opens a large can of worms.
> >
> > The practical problems that this poses to implementations of the API
> are
> > huge. For starters; each SAGA implementation must provide an
> > implementation of the Job interface specific to the resource which that
> > implementation targets, a large amount of additional code would be
> > required to perform operations on the _local_ client application.
>
> No, not at all: if your implementation talks to a resource
> manager, but that manager has no access to your application,
> e.g. because you running on a client where that RM has no
> access to, then you can't return a job in get_self,
> obviously!  That should only be available if:
>
>   - you application gets submitted via an RM
>   - THAT application asks THAT rm for a handle for itself,
>     in order to do things to itself.
>
> If you do a list_job on that RM, you would find that
> application anyway, and would be able to get a job handle
> for it.  However, you have no chance to find YOUR
> application ID - thats the only missing link, which is
> solved by that method:
>
> get_self is a shortcut for getting my own job_id out of
> bound, then doing a list_jobs, and then getting the job
> handle for my own ID.
>
> Andre.
>

Hmmm, Ok I am having a little difficultly imagining this working in
practice. I certainly do not think that this a frequent scenario.

I believe that this would be best left out of the API.

Graeme



>
> > This must be beyond the scope of the jobmanagement package, which is
> > otherwise well defined. Operations on the local client application can
> > only be in a fraction (if any) of the SAGA use cases. This sort of
> thing
> > departs from the concept of a *simple* API for the Grid.
> >
> > Graeme
> >
>
>
>
> --
> "So much time, so little to do..."  -- Garfield
>
>
>