[Ovirt-devel] Making the node generic...

[Perry Myers]

On 02/03/2010 01:37 PM, Darryl L. Pierce wrote:
> One task I'm working on is to make the managed node more generic, so
> that it can be leveraged by other hypervisor managers in the same way
> that it is managed by the ovirt-wui.
> 
> One thing I'm considering doing is to add a new configuration file to
> the node, /etc/sysconfig/node-config. This will be a central point for
> defining specific elements, such as management servers, user names, etc.
> And it can be overridden by a configuration management system, such as
> puppet. Options specified in it should also be easily overridden by
> kernel arguments if necessary.
> 
> Now, to the topic of making the node generic. Currently I'm documenting
> the startup process for the node in order to identify the points where a
> node would want to perform key events, such as notifying a management
> system that the node is online, or report its hardware and configuration
> information, etc.
> 
> What I would like to do is make the startup process as modular as
> possible. That way a third party can take the node and provide new
> functionality for a separate management system without having to change
> the code provided by the node itself.
> 
> One method I was considering is to have a directory for scripts, and
> then execute those on the node. So, for example, with a directory called
> /etc/node/startup, if the node finds a script name "awake" then it would
> execute that during that stage. Or, if it finds one named
> "network-change" then it would execute that script when it detected a
> change in networking interfaces.
> 
> Thoughts? Questions?

This is a good start to genericizing things.  One thing to keep in mind is
that it is better to use some sort of standard external interface for
doing as much as possible rather than providing infinite and arbitrary
hooks/scripts plugins.

i.e. rather than providing N hooks for allowing remote configuration of a
node for stateless mode, instead provide a single interface using a well
known standard like AMQP/REST/dnssrv to do this.  Then other users of the
node can just adopt the standard and move forward without needing to
modify the node image itself.

But providing some level of arbitrary hooks is a good idea in general, so
we should do that as well.  I just think the more people use those hooks
the more they'll deviate from the standard node image and the harder it
will be to support in the community.

Perry