Re: [vdsm] Future of Vdsm network configuration
On 11/18/2012 10:52 AM, Itamar Heim wrote: On 11/18/2012 07:55 AM, Gary Kotton wrote: On 11/17/2012 09:13 PM, Itamar Heim wrote: On 11/17/2012 11:56 AM, Gary Kotton wrote: On 11/17/2012 11:00 AM, Alon Bar-Lev wrote: Hello, After discussion calm down, I want to once again to ask a question. Why isn't this discussion focusing on the interface vdsm will use to access network provider? Why should vdsm core care which network technology it actually uses? Quantum? 1. that's still a specific implementation. I tend to disgree, Quantum is an interface enabling one to manage virtual networks. If I understand correctly this is similar to what Alon is suggesting. At the end of the day VDSM will need to interface with linuxbridge, openvswitch, nics that provide SRIOV etc. This may be done either by VDSM or Quantum agents (in some case there may be no Quantum agents - for example if a NVP controller is used). Quantum enables VDSM and oVirt to consume external technologies that are currently not supported today. For example, if one want to use openvswicth. There is a open source implementation of OVS that is managed by Quantum. That is, a Quantum agent builds and manages all flows. Do you want VDSM to do this? 2. last i checked, it is far from covering the API needed by vdsm for provisioning network configurations, rather than just consuming them? (i.e., i don't remember quantum ever intends to provide an api to bond physical interfaces, etc). Quantum agents may do this. Yes, it will entail some hooks in VDSM but it will provide a large majority of the work that you guys are talking about. The added bonus is that it works with a number of technologies that are not supported by VDSM. I have yet to understand why VDSM has to invent the wheel again. At the moment there is a lot of work being done in Quantum to expose additional services - for example LBaaS. It would be interesting to know if the current networking plans address this. This should be something on the radar and in my opinion is something essential to any networking infrastructure. i didn't see anything in quantum leading me to feel it plans to expose a stable api for configuring/provisioning itself? I do not understand your comment. Via Quantum provider networks Quantum enables one to connect a specific network interface to a virtual network. At the end of the day this connection is done by configuring the agent. If the community ever decides to adopt Quantum, which I would consider a healthy and forward moving decision, then this is something that would need to be managed by VDSM (my understanding is that the only free lunch is one at a youth hostel in the outback in Australia - one needs to by his/her drink). This is why I am in favor of what Dan and Mark have suggested regarding the OVS integration. At the end of the day someone needs to do the wiring. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Future of Vdsm network configuration
On 11/14/2012 05:42 PM, Mark Wu wrote: On 11/14/2012 07:53 PM, Gary Kotton wrote: On 11/14/2012 11:53 AM, 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 Kenigsbergdan...@redhat.com To: vdsm-de...@fedorahosted.org 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
Re: [vdsm] Future of Vdsm network configuration
On 11/14/2012 11:53 AM, 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 Kenigsbergdan...@redhat.com To: vdsm-de...@fedorahosted.org 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
