Open Stack

Hi Tomasz,

I'm working on the Modular L2 (ml2) quantum plugin (see WIP patch at
https://review.openstack.org/#/c/20105/) and would like to discuss the
relationship between this and your VXLAN work on the linuxbridge plugin
(https://review.openstack.org/#/c/26516/). Zang MingJie's work on
implementing VXLAN for openvswitch
(https://review.openstack.org/#/c/27648/) is also highly relevant.

The immediate goal for ml2 (for H-1) is to replace and deprecate the
linuxbridge, openvswitch, and hyperv plugins, working with their
existing L2 agents. This is intended to eliminate the duplication of
effort implementing similar features in similar ways (VXLAN is a great
example) in multiple plugins and maintaining the three separate plugin
code bases as things evolve.

In addition, a single quantum deployment with the ml2 plugin will be
able to work with the three types of agents simultaneously - supporting
quantum deployments with a mix of technologies. It will also eventually
be able to handle multi-segment networks. Follow-on work (late H-1 or
early H-2) will add a MechanismDriver API able to support integration
with SDN controllers, top-of-rack switches, etc.. Replacing the separate
L2 agents with a modular agent is a longer term goal.

1) To work with the three separate agents, we need to bring the RPC
interfaces these plugins and agents use into sync, and keep them
synchronized going forward. The openvswitch and hyperv RPCs are already
similar, and I see your patch is bringing the linuxbridge RPC into line.
I need this functionality ASAP to proceed with completing the first
phase of ml2 in the next few days. My options are to wait for your code
to be merged, pull a subset of your changes (I don't need the DB changes
or VXLAN support) into my code, or for one of us to address the
linuxbridge RPC changes as a separate patch that could be merged very
quickly (before either of our existing patches). Any thoughts on this?
Bringing the RPCs into sync as a separate patch seems to be ideal as
long is it doesn't delay things too much for either of us.

2) The ml2 plugin will need to support both the linuxbridge and
openvswitch agents' VXLAN implementations that are currently being
developed. This will require a VxlanTypeDriver to be written, which
should be quite similar to the VlanTypeDriver in the WIP ml2 code. I
haven't seen any fundamental reason why ml2 with such a driver could not
work with the VXLAN functionality you are adding to linuxbridge-agent
that Zang is adding to the openvswitch-agent.

3) In addition to making sure the two agents can work with the ml2
plugin for VXLAN, we'll  need to make sure they can work with each
other. This at least means similar agent-side configuration options. Are
there other details necessary for them to interoperate accessing the
same virtual networks?

4) Assuming there is agreement on the above goals, and that the initial
version of the ml2 plugin is on track to merge in the next week or so,
does it make sense to proceed with merging the server-side VXLAN support
into the existing linuxbridge and/or openvswitch plugins? Or would
supporting VXLAN only through the ml2 plugin be acceptable for Havana?

-Bob