On Tue, Nov 27, 2012 at 05:38:25AM -0500, Alon Bar-Lev wrote:
<snip>
ASSUMPTION
After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine.
MISSION
Reduce complexity of implementation, so that only one algorithm is used in order to reach to operative state as far as networking is concerned.
(Storage is extremely similar I can s/network/storage/ and still be relevant).
For reaching the mission above we can also use the approach suggested by Adam. start from a clean configuration and execute setup network to set the host networking configuration. In Adam's proposal VDSM itself is issuing the setupNetwork and in your approach the engine does.
Right. we can do this 100+ ways, question is which implementation will be the simplest.
My problem with Adam's idea is http://xkcd.com/927/ : it amounts to an (n+1)th way of persisting network configuration on disk. We may have to take that way, but as with VM definitions and storage connections, I would like to keep it in a smaller service on top of vdsm.
DESIGN FOCAL POINT
Host running vdsm is a complete slave of its master, will it be ovirt-engine or other engine.
Having a complete slave ease implementation:
- Master always apply the setting as-is.
- No need to consider slave state.
- No need to implement AI to reach from unknown state X to known
state Y + delta. 4. After reboot (or fence) host is always in known state.
ALGORITHM
A. Given communication to vdsm,
I think we should not brush this permise aside. Current Vdsm API lets Engine tweak the means of communication for next boot. We had customers that wanted to add a bond, or change the vlan, or fix the IP address of the management interface. They could have used Engine for this, and declare the new configuration as safe (setSafeNetConfig). In many cases, the latter step has to be done out of band. But there are cases where this can be done completely remotely.
It seems that you suggest to take this crucial configuration completely out-of-band.
construct required vlan, bonding, bridge setup on machine.
B. Reboot/Fence - host is reset, apply A.
C. Network configuration is changed at engine: (1) Drop all resources that are not used by active VMs.
I'm not sure what you mean by the above, drop all resources *not* used by VMs?
Let's say we have running VM using bridge bridge1. We cannot modify this bridge1 as long as VM is operative. So we drop all network configuration except of bridge1 to allow VM to survive the upgrade.
I was tempted to write something else but I did not want to alarm people.... But... when network configuration is changed on a host with running VMs, first move the VMs to a different host, then recycle configuration (simplest: reboot).
We've been doing that until v3.1...
(2) Apply A.
D. Host in maintenance - network configuration can be changed, will be applied when host go into active, apply C (no resources are used by VMs, all resources are dropped).
E. Critical network is down (Host not operative) - network configuration is not changed.
F. Host unreachable (None responsive) - network configuration cannot be changed.
What happens if we have a host that is added to the engine (or used to be non-operational and now returns to up) and reports a network configuration different than what is configured in the engine?
This is a sign of totally malicious node! A trigger to fencing, active rebooting. Can you please describe a valid sequence in which it can happen?
I'm not sure this example flies all, but how about a sysadmin that wants to replace our bonding definition with teaming.