On Wed, Nov 14, 2012 at 11:53:06AM +0200, Livnat Peer wrote: > On 14/11/12 00:28, Adam Litke wrote: > > On Sun, Nov 11, 2012 at 09:46:43AM -0500, Alon Bar-Lev wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Dan Kenigsberg" <[email protected]> > >>> To: [email protected] > >>> Sent: Sunday, November 11, 2012 4:07:30 PM > >>> Subject: [vdsm] Future of Vdsm network configuration > >>> > >>> Hi, > >>> > >>> Nowadays, when vdsm receives the setupNetowrk verb, it mangles > >>> /etc/sysconfig/network-scripts/ifcfg-* files and restarts the network > >>> service, so they are read by the responsible SysV service. > >>> > >>> This is very much Fedora-oriented, and not up with the new themes > >>> in Linux network configuration. Since we want oVirt and Vdsm to be > >>> distribution agnostic, and support new features, we have to change. > >>> > >>> setupNetwork is responsible for two different things: > >>> (1) configure the host networking interfaces, and > >>> (2) create virtual networks for guests and connect the to the world > >>> over (1). > >>> > >>> Functionality (2) is provided by building Linux software bridges, and > >>> vlan devices. I'd like to explore moving it to Open vSwitch, which > >>> would > >>> enable a host of functionalities that we currently lack (e.g. > >>> tunneling). One thing that worries me is the need to reimplement our > >>> config snapshot/recovery on ovs's database. > >>> > >>> As far as I know, ovs is unable to maintain host level parameters of > >>> interfaces (e.g. eth0's IPv4 address), so we need another > >>> tool for functionality (1): either speak to NetworkManager directly, > >>> or > >>> to use NetCF, via its libvirt virInterface* wrapper. > >>> > >>> I have minor worries about NetCF's breadth of testing and usage; I > >>> know > >>> it is intended to be cross-platform, but unlike ovs, I am not aware > >>> of a > >>> wide Debian usage thereof. On the other hand, its API is ready for > >>> vdsm's > >>> usage for quite a while. > >>> > >>> NetworkManager has become ubiquitous, and we'd better integrate with > >>> it > >>> better than our current setting of NM_CONTROLLED=no. But as DPB tells > >>> us, > >>> https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html > >>> we'd better offload integration with NM to libvirt. > >>> > >>> We would like to take Network configuration in VDSM to the next level > >>> and make it distribution agnostic in addition for setting the > >>> infrastructure for more advanced features to be used going forward. > >>> The path we think of taking is to integrate with OVS and for feature > >>> completeness use NetCF, via its libvirt virInterface* wrapper. Any > >>> comments or feedback on this proposal is welcomed. > >>> > >>> Thanks to the oVirt net team members who's input has helped writing > >>> this > >>> email. > >> > >> Hi, > >> > >> As far as I see this, network manager is a monster that is a huge > >> dependency > >> to have just to create bridges or configure network interfaces... It is > >> true > >> that on a host where network manager lives it would be not polite to define > >> network resources not via its interface, however I don't like we force > >> network > >> manager. > >> > >> libvirt is long not used as virtualization library but system management > >> agent, I am not sure this is the best system agent I would have chosen. > >> > >> I think that all the terms and building blocks got lost in time... and the > >> result integration became more and more complex. > >> > >> Stabilizing such multi-layered component environment is much harder than > >> monolithic environment. > >> > >> I would really want to see vdsm as monolithic component with full control > >> over > >> its resources, I believe this is the only way vdsm can be stable enough to > >> be > >> production grade. > >> > >> 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. > >> > >> I know this derive some more work, but I don't think it is that complex to > >> implement and maintain. > >> > >> Just my 2 cents... > > > > I couldn't disagree more. What you are suggesting requires that we > > reimplement > > every single networking feature in oVirt by ourselves. If we want to > > support > > the (absolutely critical) goal of being distro agnostic, then we need to > > implement the same functionality across multiple distros too. This is more > > work > > than we will ever be able to keep up with. If you think it's hard to > > stabilize > > the integration of an external networking library, imagine how hard it will > > be > > to stabilize our own rewritten and buggy version. This is not how open > > source > > is supposed to work. We should be assembling distinct, modular, > > pre-existing > > components together when they are available. If NetworkManager has > > integration > > problems, let's work upstream to fix them. If it's dependencies are too > > great, > > let's modularize it so we don't need to ship the parts that we don't need. > > > > I agree with Adam on this one, reimplementing the networking management > layer by ourselves using only atoms seems like duplication of work that > was already done and available for our use both by NM and by libvirt. > > Yes, it is not perfect (far from it actually) but I think we better > focus our efforts around adding new functionalities to VDSM and > improving the current robustness of the code (we have issues regardless > of any external component we're using). > > For the sake of being distribution agnostic I support the original plan > proposed by danken, using OVS combined with libvirt virInterface* wrapper.
ACK. -- Adam Litke <[email protected]> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
