On 22/02/12 18:06, Perry Myers wrote:
- 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.
I think the point mburns is trying to make in his initial email is that we're going to need to do some joint work between node and vdsm teams to change the registration process so that this is no longer necessary.
It will require some redesigning of the registration process
I'm aware of it, and that's why I'm raising my concerns, so we'll have a (partial) task list ;)
- 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.
Well, if the network is busted which leads to the bridge rename failing, wouldn't the fact that the network is broken cause other problems anyhow?
Perry, my point is that we're increasing the chances to get into these holes. Network is not busted most of the time, but occasionally there's a glitch and we'd like to stay away from it. I'm sure you know what I'm talking about.
So I don't see this as a problem. If your network doesn't work properly, don't expect hosts in the network to subsequently work properly.
See previous answer.
As an aside, why is reverse DNS lookup a requirement? If we remove that it makes things a lot easier, no?
Not sure I'm the right guy to defend it, but in order to drop reverse-dns, you need to consider dropping SSL, LDAP and some other important shortcuts...
- 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).
I don't think we should regenerate a new certificate on each boot. I think we need a way for 'an already registered host to retrieve it's certificate from the oVirt Engine server'
Using an embedded encryption key (if you trust your mgmt network or are booting from embedded flash), or for the paranoid a key stored in TPM can be used to have vdsm safely retrieve this from the oVirt Engine server on each boot so that it's not required to regenerate/reregister on each boot
Thoughtful redesign needed here...
- 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...
This flow would still be applicable. We are going to allow setting of the admin password embedded in the core ISO via an offline process. Once vdsm is fixed to use a non-root account for installation flow, this is no longer a problem
This is not exactly vdsm. More like vdsm-bootstrap.
Also, if we (as described above) make registrations persistent across reboots by changing the registration flow a bit, then the install user password only need be set for the initial boot anyhow.
Therefore I think as a requirement for stateless oVirt Node, we must have as a prerequsite removing root account usage for registration/installation
This is both for vdsm and engine, and I'm not sure it's that trivial.
- Other issues
- Local storage; so far we were able to define a local
storage in ovirt node. Stateless will block this ability.
It shouldn't. The Node should be able to automatically scan locally attached disks to look for a well defined VG or partition label and based on that automatically activate/mount
Stateless doesn't imply diskless. It is a requirement even for stateless node usage to be able to leverage locally attached disks both for VM storage and also for Swap.
Still, in a pure disk-less setup you will not have local storage. See also Mike's answer.
- 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.
Upgrades are no longer needed with stateless. To upgrade a stateless node all you need to do is 'reboot from a newer image'. i.e. all upgrades would be done via PXE server image replacement. So the flow of 'upload ISO to running oVirt Node' is no longer even necessary
This is assuming PXE only use-case. I'm not sure it's the only one.
- 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?
We already provide ability to send kdumps to remote ssh/NFS location and already provide the ability to use both collectd and rsyslogs to pipe logs/stats to remote server(s). Local logs can be set to logrotate to a reasonable size so that local RAM FS always contains recent log information for quick triage, but long term historical logging would be maintained on the rsyslog server
This needs to be co-ordinated with log-collection, as well as the bootstrapping code.
Perry