----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > To: "Dan Kenigsberg" <[email protected]> > Cc: "arch" <[email protected]> > Sent: Sunday, May 12, 2013 3:58:53 PM > Subject: Re: feature suggestion: initial generation of management network > > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected]> > > To: "Antoni Segura Puimedon" <[email protected]> > > Cc: "Alon Bar-Lev" <[email protected]>, "arch" <[email protected]> > > Sent: Sunday, May 12, 2013 3:39:54 PM > > Subject: Re: feature suggestion: initial generation of management network > > > > 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. > > What we are trying to say, product wise, is that the requirement to remotely > reboot a host
(cooperate reboot) may be available regardless of the > host-deploy sequence. Administrator may decide to reboot a host right after > host-deploy or once a week. > > Adding the ability to perform reboot is different independent discussion. > > The only reason we discuss it here is because we currently force reboot after > host-deploy (although in the API it is optional). > > Having the bridge created by the engine is, in my opinion, far more important > than keeping the reboot feature. We can discuss if remote reboot feature > should and to which version, regardless. > > Regards, > Alon > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
