[Ovirt-devel] Thinking about a more generic node...

[Darryl L. Pierce]

On Wed, Mar 03, 2010 at 04:44:48PM -0500, Perry Myers wrote:
> On 02/23/2010 10:15 AM, Darryl L. Pierce wrote:
> > So in working on making the node more generic, I've initially taken on
> > the startup processes. Right now I have patches that I'm finishing which
> > will give a more generic way of performing the following functions:
> > 
> >  * AWAKE   - notify the management system the node is awake
> >  * READY   - notify the management system the node is ready to perform
> >              tasks and run VMS
> >  * OFFLINE - notify the management system the node is going offline
> > 
> > What are other points we need to consider regarding the node's state and
> > lifecycle? I'm looking to explore what should be our initial set of
> > generic APIs that a management system would want to have available on a
> > node to make use of it.
> 
> Might want to differentiate between states like:
> CONFIGURED
> UNCONFIGURED
> 
> To differentiate between a node that has local config info vs. one that
> needs to grab config information.  Where does config bundle grabbing fit
> into this model?

Thinking about this, it seems to me a node is always technically
unconfigured in that, each time it boots, it is given a networking
configuration and applies it. Even a stateful node does this since it
really doesn't do a delta of what is setup and what's new.

I've also been thinking about whether configuration should be an
all-in-one shot or if we should break out configuration updates into
separate events. For example, if the admin changes networking setup on
the node, then an "update networking" message is fired. Or if a network
becomes unavailable then the node fires a "network update" message. But
are there any other configuration types we'd want to handle, such as
firewall changes or anything else?

> AWAKE might need to be bundled with additional state information like a
> hardware manifest to tell the mgmt server "here's the latest set of hw
> that I just booted on"

That sounds like a fine way to streamline the hardware identification
portion. Right now we send it as a combination of network
configuration/hardware set. But yesterday it was brought up in IRC that
it might be a good idea to have a separate way to query the current
networking configuration. If we break out the node reporting its network
setup to a separate event, then there's no reason not to send the
hardware information during wake up.

> OFFLINE might also need to be broken up into:
> OFFLINE - this state is when the node is going down (hardware power off)
> STANDBY - idle node, but not powered off.  mgmt system could toggle state
> back.

That's an interesting idea, having a standby state. If we can have a
node do a wake-on-LAN when the management server needs it, then this
would be a doable thing.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20100304/a5e94eec/attachment.sig>