> > 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.

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 
vdsm-devel mailing list

Reply via email to