----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > To: "Dan Kenigsberg" <[email protected]> > Cc: "arch" <[email protected]> > Sent: Thursday, May 9, 2013 4:55:00 PM > Subject: Re: feature suggestion: initial generation of management network > > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected]> > > To: "Moti Asayag" <[email protected]> > > Cc: "arch" <[email protected]> > > Sent: Wednesday, May 8, 2013 4:35:49 PM > > Subject: Re: feature suggestion: initial generation of management network > > > > 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. > > Yes. > > > 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. > > I agree. > > The current design of ovirt-host-deploy fully supports a deployment cycle > without requiring a reboot. > We no longer update kernel command-line, nor performing changes without > activating them at runtime. > The bridge setup was the one bit that was risky and could not be rolled back > cleanly without re-implementation of large chunk of engine logic. > > 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. > > > > > > > > > > > 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
