feature suggestion: initial generation of management network

[Dan Kenigsberg]

On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
> > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
> > Sent: Tuesday, May 7, 2013 4:11:05 PM
> > Subject: Re: feature suggestion: initial generation of management network
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Moti Asayag" <masayag at redhat.com>
> > > To: "arch" <arch at ovirt.org>
> > > Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > > Sent: Tuesday, May 7, 2013 2:22:19 PM
> > > Subject: Re: feature suggestion: initial generation of management network
> > > 
> > > I stumbled upon few issues with the current design while implementing it:
> > > 
> > > There seems to be a requirement to reboot the host after the installation
> > > is completed in order to assure the host is recoverable.
> > > 
> > > Therefore, the building blocks of the installation process of 3.3 are:
> > > 1. host deploy which installs the host expect configuring its management
> > > network.
> > > 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
> > > network
> > > on the host and persisting the network configuration.
> > > 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
> > > but it
> > > requires the power management to be configured prior to the installation
> > > and
> > > might
> > > be irrelevant for hosts without PM.)
> > > 
> > > So, there are couple of issues here:
> > > 1. How to reboot the host?
> > > 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
> > > engine
> > > 1.2. By opening ssh dialog to the host in order to execute the reboot
> > > 
> > 
> > why not send a reboot flag to the CommitNetworkChanges which is sent anyway,
> > one less call (or connection if you choose ssh) and easier to do.
> > 
> 
> Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig on vdsm side) 
> exceeds its logical scope which is persisting the network changes.
> 
> Needless to say if such functionally will be required elsewhere, it couldn't be
> properly reused if implemented as part of that command.
> 
> Adding Dan to comment on this as well.

Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
If reboot-after-initial-net-config is crucial, we would need to add a
special verb for that (or use the fenceNode verb if available).


However, I am not sure that this reboot is unavoidable.
Originally the reboot had two important goal:
- make sure that the updated kernel is running
- make sure that the network, which we tweak during bootstrap, is
  accessible after boot

Nowadays, the kernels does not change THAT often, for all ovirt can
matter. running an oldish kernel is not the end of the world.

And with Moti's feature implemented, we no longer tweak net config
blindly during boot. We use a well-define setupNetwork API, with a
well-tested rollback mechanism.

The bottom line is, that in my opinion, reboot-after-install can be
skipped these days.

> 
> > > 2. When to perform the reboot?
> > > 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
> > > It requires to configure the network by the monitor when the host is
> > > detected
> > > by the engine,
> > > detached from the installation flow. However it is a step toward the
> > > non-persistent network feature
> > > yet to be defined.
> > > 2.2. After setupNetwork is done and network was configured and persisted on
> > > the host.
> > > There is no special advantage from recoverable aspect, as setupNetwork is
> > > constantly
> > > used to persist the network configuration (by the complementary
> > > CommitNetworkChanges command).
> > > In case and network configuration fails, VDSM will revert to the last well
> > > known configuration
> > > - so connectivity with engine should be restored. Design wise, it fits to
> > > configure the management
> > >  network as part of the installation sequence.
> > > If the network configuration fails in this context, the host status will be
> > > set to "InstallFailed" rather than "NonOperational",
> > > as might occur as a result of a failed setupNetwork command.
> > > 
> > > 
> > > Your inputs are welcome.
> > > 
> > > Thanks,
> > > Moti