feature suggestion: initial generation of management network

[Dan Kenigsberg]

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.