feature suggestion: initial generation of management network

Thu May 9 15:12:38 UTC 2013

After reading the thread, top posting to give my perspective of the what I think would be the best approach:

Some background:
- The reboot at the end of host deployment came after issues in host deployment that were discovered after fencing/reboot (which had nothing to do with the reboot reason).
- Host deployment takes care of of constructing the bridge (when no bonding exist on host).

So Bottom line:
- I think that both handling the network configuration and reboot should be removed from host deployment (I think we all agree on that)
- host deployment should leave the VDSM up and running with everything configured (including the SSL and SSH keys), and listening to all networks.
- About the reboot - I'm not sure we still need reboot (this is a question even without this discussion)
- Anyway about how to reboot:
  - I don't think it should be done through a VDSM command
  - There is an open issue already with enabling a few stages of fencing with no PowerManagement module but based on SSH,
    So a new engine internal command should be introduced like (runSSHCmdOnVds ... and this command can have 2 variants ... one of them is reboot ... (the other is restart VDSM))
  - such command will not require a password as the SSH keys should already be in place

Thoughts/Implications on Host Life cycle:
- The easiest approach will be to leave the host in Installing phase throughout this process (all under installVdsCommand), and eventually move it to reboot 
- If one skips reboot than assuming the cluster has more than one network, he host will imminently move to none-operational ( like today)
- We can take a different approach and add a new status to the Host - PendingNetworkConfig, which could be executed automatically in the future with network-labels, ot today simply popup todo dialog in the UI.

Thanks
Barak Azulay

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>, "Barak Azulay" <bazulay at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, May 9, 2013 8:42:28 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> > 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).
> > 
> 
> +1
> 
> > 
> > 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.
> > 
> 
> Adding Barak to the thread as I think he had some concern about removing
> the reboot after install.
> 
> 
> >>
> >>>> 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
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 