Bugzilla – Bug 3748
WS-GRAM Plugable Resource Manager Backend
Last modified: 2012-09-05 13:38:52
You need to
before you can comment on or make changes to this bug.
The resource manager backend for WS-GRAM is currently hard coded to use the
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):
- could be useful for activities like Kerberos setup
- submits the job to the resource manager queue
- 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
1. A generic resource manager backend Java interface.
2. An implementation of the interface that just calls the Perl scripts as
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.
1. Create the generic resource manager Java interface.
2. Add support in the home configuration for specifying the plugin
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
6. Update the non-default configuration section of the admin guide
how to configure the plugin.
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
6) Added cancel operation to remove the job from the resource manager
7) Added cleanUp operation to do post Done/Failed clean up
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.
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...
This work has been retargeted for the 4.4 series.
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: