Bug 3748 – WS-GRAM Plugable Resource Manager Backend

Bug 3748 - WS-GRAM Plugable Resource Manager Backend

Summary:

WS-GRAM Plugable Resource Manager Backend

Status:	RESOLVED WONTFIX

Product:	GRAM
Component:	Campaign
Version:	unspecified
Platform:	PC Linux

Importance:	P3 normal
Target Milestone:	4.4
Assigned To:	Stuart Martin

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-09-14 12:33 by Peter Lane
Modified:	2012-09-05 13:38 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description From Peter Lane 2005-09-14 12:33:00

The resource manager backend for WS-GRAM is currently hard coded to use the
perl
scripts used for previous versions of GRAM. To anticipate future developments
such as the Windows port being done by Univa and the possible re-implementation
of the Perl scripts to Java, a generic, plugable interface should be created to
allow customization without having to hack such changes into the code. The
following methods are proposed as part of this interface (arguements will be
determined during the campaign):

preSubmit
- could be useful for activities like Kerberos setup
submit
- submits the job to the resource manager queue
postSubmit
- usefull for activities such as merging stdout files, but could also be used
for activities such as Kerberos cleanup remove
- remove the job from the resource manager queue if still running, and clean up
any lingering job state

Deliverables:

   1. A generic resource manager backend Java interface.
   2. An implementation of the interface that just calls the Perl scripts as
the 
      Java code does currently.
   3. Updated configuration settings which specify #2 as the default plugin.
   4. Add documentation for the new Java interface and configuration support. 

Tasks:

   1. Create the generic resource manager Java interface.
   2. Add support in the home configuration for specifying the plugin 
      implementation class.
   3. Move any non-generic code from ManagedExecutableJobResource and 
      StateMachine into an implementation of the interface.
   4. Verify that the unit tests pass.
   5. Add a section to the admin guide for addressing the new Java plugin 
      interface.
   6. Update the non-default configuration section of the admin guide
describing 
      how to configure the plugin.

------- Comment #1 From Peter Lane 2005-09-14 12:41:01 -------

I've been working on this since Friday, September 9th.  Some slight
modifications to the interface have occured since I started working on this:

1) I have added an activate method to enable adapter bootstraping.  This is also
where the JobStateChangeListener is set.
2) To make the plugin more of an adapter API that treats the job monitoring as
part of the resource maanger, I have added the following operations:
registerJobIds and unregisterJobIds.
3) postSubmit is confusing in it's current definition since some may think it's
used to perform tasks after the job has been submitted but before it has
finished. I have redefined postSubmit to be the method that performs tasks after
the job has been submitted.
4) To replace the old postSubmit (see #2), I have added a postProcess method.
5) I have added a getState method which polls the RM for the job state. This
makes sense with the new view of treating this as an adapter API instead of just
a plugin.

------- Comment #2 From Peter Lane 2005-09-14 15:03:30 -------

6) Added cancel operation to remove the job from the resource manager
7) Added cleanUp operation to do post Done/Failed clean up

------- Comment #3 From Peter Lane 2005-09-14 18:58:30 -------

The adapter code separation is finished.  I still need to update the
configuration package to expose the new plugin class setting (relatively trivial
change).  Since we don't have a separate 4.2 documentation repository, I will
have to stall this campaign once I finish deliverable #3 until that is available.

------- Comment #4 From Peter Lane 2005-09-15 16:52:49 -------

The setup packages have been upgraded to allow the new adapter parameter.  The
campaign_518_branch has been merged with the trunk as well.

As I mentioned before, I'm need a 4.2-specific doc repository before I can
complete this campaign.  Therefore I guess it's officially stalled...

------- Comment #5 From Stuart Martin 2008-02-04 11:36:39 -------

This work has been retargeted for the 4.4 series.

------- Comment #6 From Stuart Martin 2012-09-05 13:38:52 -------

Doing some bugzilla cleanup...  Resolving old GRAM3 and GRAM4 issues that are
no longer relevant since we've moved on to GRAM5.  Also, we're now tracking
issue in jira.  Any new issues should be added here:

http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363