On 22/02/12 17:58, Mike Burns wrote: > 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  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 >>> >>>  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 > This will require some thinking.
>> >> * 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. > Close, but not exactly; vdsm-reg will run on every boot, but if the relevant bridge is found, then networking is unchanged. >> >> * 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. > This is a security issue, since the key pair should be generated on the node. This will lead us back to your TPM suggestion, but (although I like it, ) will cause us to be tpm-dependent, not to mention a non-trivial implementation. >> >> * 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. This will also need some work on the vdsm side. >> > > 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. Indeed so- completely forgot about swap... > > Mike > -- /d “Funny,” he intoned funereally, “how just when you think life can't possibly get any worse it suddenly does.” --Douglas Adams, The Hitchhiker's Guide to the Galaxy _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://fedorahosted.org/mailman/listinfo/vdsm-devel