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:
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?
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
i didn't see anything in quantum leading me to feel it plans to expose a
stable api for configuring/provisioning itself?
vdsm-devel mailing list