Whether you want to build the software, run it, grow the community or just learn more about it, there will be content, workshops and design sessions for you to attend at the OpenStack Summit, Oct 15-18 in San Diego. Stick around Friday for the first OpenStack service day, a 1/2 day beach cleanup.
Beyond support for GRE networks, there is no meaningful server-side difference between the current openvswitch and linuxbridge plugins. Both support VLAN tenant networks and the same set of provider network types. Their agents also are similarly structured, differing mainly in the specific networking commands they run in response to the same set of events. We will propose replacing these two plugins in Grizzly with a modular Quantum plugin and agent where both L2 network types and the mechanisms supporting those types plug-in as driver, allowing multiple networking technologies to be simultaneously deployed within a Quantum installation.
Network types such as VLAN, GRE, and flat will be implemented in the server-side plugin as network-type-drivers. These network-type-drivers are responsible for maintaining any type-specific DB schema, pooling and allocating tenant networks, and validating parameters for provider networks. But a network-type-driver is not tied to any specific mechanism for realizing that network type on participating compute or L3 agent nodes.
The current Open vSwitch and Linux bridging mechanisms would plug into the modular L2 agent as agent-mechanism-drivers. Nodes using different agent-mechanism-drivers for a common network type could co-exist and interoperate within a Quantum deployment. Multiple agent-mechanism-drivers could also plug into a node's L2 agent simultaneously to handle different network types. We will also explore server-mechanism-drivers that would integrate certain centralized or controller-based mechanisms on the server-side, without the need for L2 agents on the participating nodes.
This modular L2 plugin and agent architecture is not intended to replace the current Quantum plugin abstraction. Non-modular plugins are more appropriate when an external controller completely controls the data center network. We will discuss the benefits this modular architecture offers in cases where a variety of networking technologies co-exist within a data center. In particular, we believe this approach is more flexible and more maintainable than the meta-plugin approaches currently used in Folsom.
Monday October 15, 2012 4:30pm - 5:10pm