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
