----- Original Message ----- > From: "Barak Azulay" <[email protected]> > To: "Livnat Peer" <[email protected]> > Cc: "arch" <[email protected]> > Sent: Thursday, May 9, 2013 6:12:38 PM > Subject: Re: feature suggestion: initial generation of management network > > 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
I disagree. After management agent (VDSM in our case) is installed, all communications should be done via that agent. Using multi-protocol layers is not wise in this architecture. For example, if we switch the direction of engine->vdsm communications we cannot use SSH. > > 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" <[email protected]> > > To: "Dan Kenigsberg" <[email protected]>, "Barak Azulay" > > <[email protected]> > > Cc: "arch" <[email protected]> > > 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" <[email protected]> > > >>> To: "Moti Asayag" <[email protected]> > > >>> Cc: "arch" <[email protected]>, "Alon Bar-Lev" <[email protected]> > > >>> Sent: Tuesday, May 7, 2013 4:11:05 PM > > >>> Subject: Re: feature suggestion: initial generation of management > > >>> network > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Moti Asayag" <[email protected]> > > >>>> To: "arch" <[email protected]> > > >>>> Cc: "Alon Bar-Lev" <[email protected]> > > >>>> 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 > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > _______________________________________________ > > Arch mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
