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.

Thanks
Gary



With proper design of such interface, and the ability to select
interface implementation using configuration, vdsm will be able to
work with various of technologies without a change.

Technologies can be either network manager, ovs, libvirt or basic.
What popular now can be unpopular in future, what is considered stable
enough for now, may be not stable enough for future uses, what is
maintained now may be unmaintained in future.

Developing tightly coupled software is something I would avoid if not
absolutely required.

People may vote which interface they like to have now and we can
implement one, while in time we may see other implementations as
contributions. This will also allow us to move from one technology to
another with decent effort/costs if required for any reason.

Best Regards,
Alon Bar-Lev.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to