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

[Andre Merzky]

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.


> 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