index.html

m4_include(/mcs/m4/worksp.lib.m4)
_NIMBUS_HEADER(2.6 Extensibility Guide)
_NIMBUS_HEADER2(n,n,y,n,n,n,n,n)

<style type="text/css">
ul.nobullets {
	list-style: none;
}
</style>

_NIMBUS_LEFT2_COLUMN
_NIMBUS_LEFT2_DEV2_SIDEBAR(n,y,n,n,n,n,n,n,n)


_NIMBUS_LEFT2_COLUMN_END
_NIMBUS_CENTER2_COLUMN
_NIMBUS_IS_DEPRECATED


<h2>Extensibility Guide</h2>

<p>
    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.
</p>

<p>
    The <a href="../faq.html">Nimbus FAQ</a> is good prerequisite reading
    for this section, especially
    <a href="../faq.html#nimbus-main-components">this section</a>.
</p>

<p>
    Each <a href="../faq.html#nimbus-main-components">Nimbus component</a>
    can be sanely replaced by something that implements the same interface
    or protocol.

</p>

<p>
    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 <a href="../faq.html#wpilot">workspace pilot</a>).
</p>

<p>
    Also in many cases the pieces can be used on their own.
</p>

<p>
    There is an integration
    with <b>OpenNebula</b> discussed
    <a href="http://trac.opennebula.org/wiki/NimbusIntegration">here</a>,
    an integration with <b>Nagios</b> discussed
    <a href="https://wiki.gridx1.ca/twiki/bin/view/Main/NagiosNimbusPluginInstall">here</a>,
    and an integration with <b>MDS</b> discussed
    <a href="https://wiki.gridx1.ca/twiki/bin/view/Main/MdsVMInfoInstall">here</a>.
</p>

<p>
    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 <a href="http://www.springframework.org/">Spring framework</a>
    dependency injection container.
</p>

<p>
    The <a href="../faq.html#workspace-service">workspace service</a> has
    the most of these internal "plug points" (around 50, all told, although
    it would be esoteric to replace some of them).
</p>
<p>
    The major ones are outlined on the following pages:
</p>

<ul>
    <li>
        <a href="service-sched.html">Scheduling/resource management</a>
    </li>

    <li>
        <a href="service-network.html">Networking leases</a>
    </li>

    <li>
        <a href="service-accounting.html">Usage accounting</a>
    </li>

    <li>
        <a href="service-prop.html">Propagation</a>
    </li>

    <li>
        <a href="service-authz.html">Request authorization</a>
    </li>

    <li>
        <a href="service-reqintake.html">Initial request intake</a>
    </li>

    <li>
        <a href="service-tasks.html">Fine grained replacement for
            VMM control tasks</a>
    </li>

</ul>

<hr />
<p>
    A beginning exercise to start developing plugins would be to:
</p>

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

_NIMBUS_CENTER2_COLUMN_END
_NIMBUS_FOOTER1
_NIMBUS_FOOTER2
_NIMBUS_FOOTER3