On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote: > > > > The risk of a deployed system (without bridge) to be unresponsive after > > reboot is minimum. > > > > 1. iptables rules are already active. > > 2. udev rules are active. > > 3. vdsm is up. > > > > The major risk is basically if some dependency package was UPDATED during > > the > > installation of vdsm, while its service/consumer is already running, then we > > are running a host with the old software and there is a chance that after > > reboot with the new software the host will fail. > > > > I think that the decision to reboot host should be delegated to > > administrator, adding vdsm verb to reboot is usable. This way admin will be > > able to take a host to maintenance mode and reboot, and we can add checkbox > > to the add host dialog '[x] reboot', rebooting the host at the end of the > > sequence. I think the default should be off. > > I'm also in agreement with the addition of a reboot verb. It could be a nice > addition regardless of this specific use case.
A "reboot" verb is nice, but I am not yet sure that it is actually needed. Above, Alon give one argument for it - to make sure that vdsm (and its dependencies, and other updated packages) works smoothely after boot. That's a good argument - but it may be acheived by post-deploy boot as done today - without an additional frighteningly-named verb. Note that vdsm, or any other package, may be upgraded by yum asynchronous to Engine's operation, so we may face a surprise cannot-start-after-boot later in the host life cycle. Not only post-install. As I said in my first comment to this thread - I do not think that reboot-after-install is desperately needed, and find that it does not deserve the Engine-side complexity of calling a new verb. Dan. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
