feature suggestion: initial generation of management network

[Barak Azulay]

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Sunday, May 12, 2013 3:58:53 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> 
> ----- 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
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
>