----- Original Message -----
From: "Simon Grinberg" simon@redhat.com To: "Mark Wu" wudxw@linux.vnet.ibm.com Cc: vdsm-devel@fedorahosted.org, "Alon Bar-Lev" alonbl@redhat.com Sent: Tuesday, November 13, 2012 10:06:42 AM Subject: Re: [vdsm] Future of Vdsm network configuration
Hypervisor should be a total slave of manager (or cluster), so I have no problem in bypassing/disabling any distribution specific tool in favour of atoms (brctl, iproute), in non persistence mode.
Do you mean just using the utilities (brctl, iproute) on demand and not keeping any network configuration on vdsm host? Then manager needs reconfigure network on every host reboot. Actually, I like this way. It could be more flexible than libvirt's virInterface (netcf or NM) and have fine-grained control to handle some tough cases. Moreover, it's clean than the current mangling network configuration files.
+1, I've raised that is the past, I don't think the network configuration done by the engine should be persisted. This way the admin sets up the node in a persistent way such that it always succeeds to boot and has a rout to the engine. Engine on node activation updates the network, connects to storage etc.
Now that setupNetworks can do it in one atomic operation this is the way to go, very simple. It's also eases the move of a node from a cluster to cluster. With current concept, after you move the host you need to modify the node networks to fit the new cluster topology. With non-persistent, placing a host into maintenance should also revert the host to the original networking after boot same as it disconnects the storage. Now you can easily move the node from cluster to cluster or even a differed DC. As soon as you activate - it is configured with the new DC/Cluster pair requirements.
And it's a valuable step in the direction of -> Go go dynamic host allocation :)
So I am not the only insane one where! Good to know!
Alon