Bug 5744 - Add a default factory
: Add a default factory
wsrf managed job factory service
: 4.1.2
: Macintosh All
: P2 normal
: 4.2
Assigned To:
  Show dependency treegraph
Reported: 2007-12-21 14:26 by
Modified: 2008-02-06 14:25 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2007-12-21 14:26:24
Right now, globusrun-ws assumes that you're submitting to a Fork jobmanager. 
In GT2, the admin had the capability of pointing the default jobmanager to
whatever backend jobmanager they wanted.  So, if I wanted the default job
submission to my site to go to ManagedFork (or PBS, or Condor, ...), I could
make that happen.  In GT4, the client needs to know what kind of scheduler is
behind the GRAM service so they can use the -Ft option.  This breaks the
fundamental abstraction of GRAM.

I propose we make globusrun-ws submit to the "Default" factory, which will be
admin-configurable to point to Fork or PBS or ...

The mapping of Default should also show up as  an RP: like, at this site,
Default means "LSF".
------- Comment #1 From 2007-12-22 00:31:37 -------
This can be accomplished very easy, in fact it's just a few lines of code.
ManagedJobFactoryHome must overwrite the ResourceHomeImpl.find():

public Resource find(
    ResourceKey key)
    throws ResourceException {

    if (key == null) {
        // set key to the configured default.
        // For illustration purpose a hardcoded default:
        key = ManagedJobHelper.getResourceKey("PBS");
    return super.find(key);

With this we don't even need a new factory type "Default". All a
client must do is to just specify the address and no longer
the reference properties/parameters in the factory EPR (which is
optional according to the ws-addressing specification)
A job like the following would then be submitted to the default
local resource manager.


ManagedJobFactoryHome.find() is the the only piece of code that
enables this and all invocations (job submissions, factory
resource properties queries, etc) simply get redirected to the 
configured default factory type in case the client does only specify
the address in the factory EPR. So there's no need for a new factory
resource "Default".

Also the new RP "defaultLocalResourceManager" is not necessarily needed
because we get redirected to the default factory resource here too if
no factory type is specified in a factory RP query:

wsrf-get-property \
   -s https://host:port/wsrf/services/ManagedJobFactoryService \   

gives as response:


I think it would be good to offer a factory RP
"availableLocalResourceManagers" instead that gives a list of all
configured LRMs.

AFAIK this change could also be applied to the 4.0 branch.
Note however that all tests, GramJob, globusrun-ws must be updated
for this. So i'm not sure if we should have this in 4.0.6.
------- Comment #2 From 2007-12-22 08:48:47 -------
Very Cool!  I think adding this for 4.2 is probably good enough.

I like the idea of a list of available resource managers too.  This is
available now from the container's registry service.  But I think it would be
good to provide this in GRAM and not require that dependency on the registry
service for this information.
------- Comment #3 From 2008-02-06 11:58:26 -------
committed to branch ws-gram-bug5247 which will be merged to trunk.
------- Comment #4 From 2008-02-06 12:01:02 -------
*** Bug 3829 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2008-02-06 14:14:06 -------
Committed the following change to ws-gram-bug5247:
A client does not need to provide reference parameters for multijobs.
Regardless of what is configured as default local resource manager: multi
jobs will always go to Multi. The sub-jobs don't need to specify reference
parameters, but can.
Also: An admin must not configure Multi as default factory. This will result
in an error message in container startup and an exception and error message
per submitted job.