On 05/09/2013 10:55 AM, Alon Bar-Lev wrote:
----- 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.
+1
--
Cheers
Douglas
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
