feature suggestion: initial generation of management network

[Alon Bar-Lev]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
> 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