Open Stack

Hi Jiang

Sure let me elaborate - this blueprint basically solves the problem of provisioning VLANs/GRE tunnels on physical switches, such as datacenter top-of-the-rack (TOR) switches which are typically connected to the computer servers, while at the same time allowing Quantum to provision virtual switches ( OVS / LinuxBridge ).

In the current Quantum plugin architecture - there isn't a way of provisioning both physical hardware switches and  virtual switches (ovs) at the same time. Most quantum plugins either support physical switches or virtual switches (OVS/linux bridge) - typically most deployments use the OVSPlugin, while relying on the data center operator to manually provision the physical switches (or the data center operator has to either trunk all VLANs on all ports which is not a desirable solution).

The blueprint proposes a solution to address this - it uses the most popular OVSPlugin as an use case. It adds an extension API (driver API) into the OVSPlugin, which allows hardware switch drivers to plug into the OVSPlugin. When the OVSPlugin receives the 'create_network', 'create_port', 'update_port' etc., API calls from Quantum, it first sends the provisioning request to the OVS agents (as it does today) and in addition, invokes one or more driver APIs which we have added.

This allows the physical device driver to talk to one or more vendors' devices (or management stations) and provision them at the same time as the virtual switches. The blueprint also allows more than one vendors driver to be configured at the same time. In this case, the OVSPlugin will invoke each driver in turn. This might be useful in mixed vendor environments, where part of the datacenter uses hardware from one vendor, while the remaining uses hardware from a different vendor.

Hope this makes it clear?

Regards,
Satish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130129/46c08b94/attachment.html>