Class IBackend

x.__init__(...) initializes x; see help(type(x)) for signature

Overrides: object.__init__

(inherited documentation)

This is a hook called for each job when Ganga.Core services are started up. The hook is called before the monitoring subsystem is enabled. This hook may be used by some backends to do specialized setup (e.g. to open ssh transport pipes of the Remote backend)

Submit   the  master  job  and  all   its  subjobs.   The
masterjobconfig  is  shared,  individual  subjob  configs  are
defined  in  subjobconfigs.   Submission  of  individual  jobs
(not-split) also  always goes via  this method.  In  that case
the subjobconfigs contains just one element - the job itself.

The default  implementation of  this method emulates  the bulk
submission  calling  a submit()  method  on individual  subjob
objects.  If submission  of any of the subjobs  fails then the
whole   process  is  aborted   with  IncompleteSubmissionError
exception. The subjobs which  have already been submitted stay
submitted.

The default implementation does not process the masterjobconfig.
Therefore this method may be overriden in the derived class
in the following way:

def master_submit(self,masterjobconfig,subjobconfigs,keep_going):
   ... 
   do_some_processsing_of(masterjobconfig)
   ...
   return IBackend.master_submit(self,subjobconfigs,masterjobconfig,keep_joing)


Implementation note: we set keep_going to be optional in the
signature of IBackend.master_submit() to allow the existing
backend implementations which do not support keep_going=True
and which at some point may call IBackend.master_submit() to
work without change. It may sometimes be non-trivial to enable
support for keep_going=True in some backends, even if the
finally call IBackend.master_submit(). Therefore it is left to
the decision of backend developer to explicitly enable the
support for keep_going flag.

Submit an individual job. Return 1 in case of success.

master_input_sandbox is a list of file-names which is shared by all subjobs.

This method is not called directly by the framework. It is only called by the default implementation of master_submit() method.

Therefore if the implementation of master_submit() is able to cope with submission of individual jobs, then submit() is redundant.

Transition from Ganga 4.0.x:

• subjobconfig is equvalent to jobconfig in the older interface.
• jobid is an obsolte parameter which will be removed in the future

Prepare the master job (shared sandbox files). This method is/should be called by master_submit() exactly once. The input sandbox is created according to self._packed_input_sandbox flag (a class attribute)

A hook in case someone wanted to override the auto resubmission behaviour. Otherwise, it auto_resubmit is equivalent for all practical purposes to a normal resubmit (so it automatcially benefits from bulk resubmit if implemented).

Resubmit (previously submitted) job. Configuration phase is skipped. Default implementation works is an emulated-bulk operation. If you override this method for bulk optimization then make sure that you call updateMasterJobStatus() on the master job, so the master job will be monitored by the monitoring loop.

Kill a job and all its subjobs. Return 1 in case of success.

The default implementation uses the kill() method and emulates the bulk operation on all subjobs. It tries to kill as many subjobs as possible even if there are failures. If the operation is incomplete then raise IncompleteKillError().

Kill a job (and also all its subjobs). This method is never called by the framework directly. It may only be called by the default implementation of master_kill().

Allow viewing of job output files on the backend
(i.e. while job is in 'running' state)

Arguments other than self:
filename : name of file to be viewed
          => Path specified relative to work directory
command  : command to be used for file viewing

Return value: None

When the job is removed then this backend method is called. The primary use-case is the Remote (ssh) backend.

Update monitoring information for jobs: jobs is a list of jobs in this backend which require monitoring (either 'submitted' or 'running' state). The jobs list never contains the subjobs.

The default implementation iterates over subjobs and calls updateMonitoringInformation().

Update monitoring information for individual jobs: jobs is a list which may contain subjobs as well as the non-split jobs. This method is never called by the framework directly. It may only be called by the default implementation of master_updateMonitoringInformation().