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/
pgptauduT2L6l.pgp
Description: PGP signature
_______________________________________________ Ovirt-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/ovirt-devel
