Quoting Andre Merzky <andre@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