Warning: This document describes an old release. Check here for the current version.

Extensibility Guide

This discusses the various ways you can make Nimbus components behave differently, either by activating/switching pre-existing plugins or by creating a new plugin/component to replace a current extensibility point.

The Nimbus FAQ is good prerequisite reading for this section, especially this section.

Each Nimbus component can be sanely replaced by something that implements the same interface or protocol.

This provides a wide range of possibilities. For example, we were able to provide a drop-in workspace-control implementation that supports KVM. Another example is providing a scheduler based on an external resource manager (by using the workspace pilot).

Also in many cases the pieces can be used on their own.

There is an integration with OpenNebula discussed here, an integration with Nagios discussed here, and an integration with MDS discussed here.

On top of all this, most of the Java based components have the built-in ability to define their internal modules at runtime via configuration files. This is achieved by using the Spring framework dependency injection container.

The workspace service has the most of these internal "plug points" (around 50, all told, although it would be esoteric to replace some of them).

The major ones are outlined on the following pages:

A beginning exercise to start developing plugins would be to:

  • Look at the Spring configuration for one of the current plugins in the list above.
  • Find the source code for the implementation listed.
  • Create your own new Java class based on that other implementation and change something around or print something new and prominent to the logger.
  • Then put the fully qualified class name of your new class into the Spring configuration in place of the original class name.
  • Make sure a jar file with your new compiled class exists under $GLOBUS_LOCATION/lib
  • Reboot the container to see your change take effect.