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 -- /d "Willyoupleasehelpmefixmykeyboard?Thespacebarisbroken!" _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
