----- Original Message ----- > From: "Gary Kotton" <gkot...@redhat.com> > To: "Itamar Heim" <ih...@redhat.com> > Cc: email@example.com > Sent: Sunday, November 18, 2012 11:07:58 AM > Subject: 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.
Hello, Quantum is just like any other network management technology VDSM can use. What I would like to see is an interface without any 3rd party dependency of VDSM to network management technology, aka network management provider. This interface should specify all services VDSM expects from a network management technology, such as defining bond, bridge, vlan, interface configuration, enumeration, events. Then if we decide to implement a provider using Quantum it will be possible, exactly as it will be possible to implement a provider based on network manager or low level. Of course that there are advantages and features that VDSM may have if using a provider of specific technology, but the interface it-self should not have any affiliation with 3rd party component to allow us the flexibility of choice in future. Regards, Alon Bar-Lev. _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel