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

[Andre Merzky]

Hi Chris, 

Quoting [Christopher Smith] (Mar 06 2006):
> 
> FWIW
> 
> I see the JobService as being closely coupled to the resource manager, such
> that the constructor of the JobService could take the address of an RM
> endpoint. 
> 
> I'm also not sure of the usefulness of having separate createJob and run
> methods, rather than submitJob ... and I can't recall the conversations that
> lead to the distinction. :-)

The main reason is the required ability to handle large
bulks of jobs:

  saga::task_container tc;

  for ( int i = 0; i < 100000; i++ )
  {
    saga::job j = js.create_job (description);

    // remember: job implements task
    tc.add_task (j);
  }

  // ran these jobs as bulk:
  tc.run ();


> I do believe that jobs started with runJob are still "jobs" and should be
> added to indices. runJob is just a shortcut method (we had lots of
> discussions about whether to add it or not).

Right, run_job is just a shortcut, avoiding the
job_description altogether.

Cheers, Andre.


> -- Chris
> 
> On 3/3/06 03:35, "Graeme Pound" <G.E.POUND at soton.ac.uk> wrote:
> 
> > Hi,
> > 
> > I have some comments on the job section of the Strawman API (revision 1.4).
> > 
> > Thanks
> >    Graeme
> > 
> > 
> > 
> >   -3.37 I do not understand the purpose of job_service.get_self() which
> > returns a Job object.
> > 
> >   -3.38 I like the removal of the JobInfo and JobExitStatus objects from
> > the API, and adding this information as attributes to Job. This
> > streamlines the API, the concept of read only attributes also makes
> > sense [to me] within the context of the Job object.
> > 
> >   -3.39 I like the simplification of the job_state enumeration. NB This
> > is called 'state' in the SIDL and should be corrected to 'job_state'.
> > 
> >   -3.41 The separation of the JobService.submitJob() method into two
> > methods JobService.createJob() [create the job object] and Job.run()
> > [start the job] has not been seamless and there are several of
> > conceptual and practical problems. This needs to be fine-tuned further.
> > On many [all?] resource managers there is no separation between
> > submitting a job to the resource manager and manually starting the job,
> > this raises the following problem:
> >          - Job objects are identified via the job_id which is described
> > as the  "job identifier as returned by the resource manager".
> > Unfortunately since this information will only be available upon
> > submission of the job (via Job.run()) this breaks the methods
> > JobService.list() and JobService.getJob(). It is now impossible to
> > manage an index of Job objects within JobService based upon the job ID.
> >          - What is the conceptual relationship between the JobService
> > and the resource manager? At present this is a little confused in a
> > couple of ways.
> >              #1 Should there be a one to one relationship between
> > JobService instances and resource managers; i.e. should the resource
> > manager endpoint be specified in the JobService constructor (or
> > otherwise as an argument to JobService.createJob())?
> >              #2 The term JobService implies a close relationship to the
> > resource manager. Previously JobService.submitJob() corresponded to
> > communication with the resource manager. Now JobService.createJob()
> > corresponds to the creation of instances of the Job class the JobService
> > is acting as a factory. It may beneficial to rename JobService to
> > JobFactory to clarify the relationship.
> > 
> >   -3.42 Should Job objects created by runJob() be added to the index
> > managed by the JobService? Or in other terms, should JobService.runJob()
> > be a Java 'static' method?
> > 
> > 
> > 
> > 



-- 
"So much time, so little to do..."  -- Garfield