Bug 3829 - Separating the factory type from the resource name
: Separating the factory type from the resource name
Status: RESOLVED DUPLICATE of bug 5744
: GRAM
wsrf managed job factory service
: 4.0.1
: Macintosh All
: P2 enhancement
: 4.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-10-19 13:20 by
Modified: 2008-02-06 12:01 (History)


Attachments


Note

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


Description From 2005-10-19 13:20:33
Hi,

To simplify deployment, I want to have a common naming scheme of "Fork" vs
"Batch" factory types across a bunch of clusters. Also, I want a simple way in
which to make batch submission default. E.g., if people do "globusrun-ws -F
hostname" (not specifying -Ft) I want the "Fork" Factory type pointing to a
scheduler backend.

I tried shifting the etc/gram-service-*/ directories around but that doesn't work.

Wouldn't this be fairly easy to fix? Either

a) Make the naming of the etc/gram-service-*/ directories control what resource
key to register as

or

b) Add a configuration key in etc/gram-service-*/jndi-config.xml that defines
what resource key to register under. If this key is not specified, let the
default be the value of the "localResourceManager" configuration entry.

/Olle
------- Comment #1 From 2005-10-19 13:48:37 -------
Actually, this came up in a different discussion and I was thinking an easier
way to do this would be to allow a null resource key that would default to a
particular resource manager according to a configuration in the
gram-service/jndi-config.xml.  I haven't tried this yet, but I think that should
be possible.  We would have to change globusrun-ws to not specify a default if
-Ft is omitted.
------- Comment #2 From 2008-02-04 11:28:28 -------
Peter's idea was implemented.  If no resource key is specified in a request to
the factory service, then the default factory resource specified in the
service's JNDI config will be used.
------- Comment #3 From 2008-02-06 12:01:02 -------

*** This bug has been marked as a duplicate of 5744 ***