Ovirt devel - Feb 2010 - Thinking about a more generic node...

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.

Ideas?

-- 
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/20100223/dbea5400/attachment.sig>

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?

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"

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.

Dunno, just some thoughts...

Perry