Re: [Engine-devel] [node-devel] Support for stateless nodes

On Wed, 2012-02-22 at 17:33 +0200, Doron Fediuck wrote: > On 22/02/12 16:57, Mike Burns wrote: >> There has been a lot of interest in being able to run stateless Nodes >> with ovirt-engine. ovirt-node has designed a way [1] to achieve this on >> the node side, but we need input from the engine and vdsm teams to see >> if we're missing some requirement or if there needs to be changes on the >> engine/vdsm side to achieve this. >> >> As it currently stands, every time you reboot an ovirt-node that is >> stateless, it would require manually removing the host in engine, then >> re-registering/approving it again in engine. >> >> Any thoughts, concerns, input on how to solve this? >> >> Thanks >> >> Mike >> >> [1] http://ovirt.org/wiki/Node_Stateless >> > > Some points need to be considered; > > - Installation issues > > * Just stating the obvious, which is users need > to remove-add the host on every reboot. This will > not make this feature a lovable one from user's point of view. Yes, this is something that will cause this to be a non-starter. We'd need to change something in the engine/vdsm to make it smoother. Perhaps, a flag in engine on the host saying that it's stateless. Then if a host comes up with the same information, but no certs, etc, it would validate some other embedded key (TPM, key embedded in the node itself), and auto-approve it to be the same state as the previous boot

> > * During initial boot, vdsm-reg configures the networking > and creates a management network bridge. This is a very > delicate process which may fail due to networking issues > such as resolution, routing, etc. So re-doing this on > every boot increases the chances of loosing a node due > to network problems. vdsm-reg runs on *every* boot anyway and renames the bridge. This is something that was debated previously, but it was decided to re-run it every boot.

> > * CA pollution; generating a certificate on each reboot > for each node will create a huge number of certificates > in the engine side, which eventually may damage the CA. > (Unsure if there's a limitation to certificates number, > but having hundreds of junk cert's can't be good). We could have vdsm/engine store the certs on the engine side, and on boot, after validating the host (however that is done), it will load the certs onto the node machine.

> > * Today there's a supported flow that for nodes with > password, the user is allowed to use the "add host" > scenario. For stateless, it means re-configuring a password > on every boot... Stateless is really targeted for a PXE environment. There is a supported kernel param that can be set that will set this password. Also, if we follow the design mentioned ^^, then it's not an issue since the host will auto-approve itself when it connects > > - Other issues > > * Local storage; so far we were able to define a local > storage in ovirt node. Stateless will block this ability. Yes, this would be unavailable if you're running stateless. I think that's a fine tradeoff since people want the host to be diskless. > > * Node upgrade; currently it's possible to upgrade a node > from the engine. In stateless it will error, since no where > to d/l the iso file to. Upgrade is handled easily by rebooting the host after updating the pxe server > > * Collecting information; core dumps and logging may not > be available due to lack of space? Or will it cause kernel > panic if all space is consumed? A valid concern, but a stateless environment would likely have collectd/rsyslog/netconsole servers running elsewhere that will collect the logs. kdumps can be configured to dump remotely as well.

> Another concern raised is swap and overcommit. First version would likely disable swap completely. This would disable overcommit as well. Future versions could enable a local disk to be used completely for swap, but that is another tradeoff that people would need to evaluate when choosing between stateless and stateful installs.

Mike