On 07/16/2015 08:07 PM, Ben Pfaff wrote: > On Thu, Jul 16, 2015 at 06:06:12PM -0400, Russell Bryant wrote: >> While parsing the OVN bridge mapping configuration, ensure that patch >> ports exist between the OVN integration bridge and the physical >> network bridge. If they do not exist, create them automatically. >> >> Signed-off-by: Russell Bryant <rbry...@redhat.com> > > Now it compiles again.
:-) I moved the misplaced hunk to this patch. > This raises a philosophical issue. Currently OVN requires something > else in the system, that runs before ovn-controller starts, to create > the integration bridge. This seems reasonable enough, but > ovn-controller could do it itself. Similarly, OVN could require > something else in the system to add the ports to the integration bridge > before it starts up. That would put a little more burden on startup > scripts, but it would also be more flexible (the ports wouldn't have to > be patch ports, if something else is appropriate, for example). It > would also mean that ovn-controller itself would need less > configuration, although that would presumably get shifted somewhere else > so it's net zero. > > What is your opinion? I think that the more we can make OVN "just work", the more successful it will be. With that said, some amount of optional flexibility is nice. Specifically: I think it makes sense for ovn-controller to create the integration bridge if it does not already exist. Create it if you want to (or have some reason to need to), but otherwise ovn-controller should create it. That seems like a low hanging "just works" capability. Regarding this patch, to be honest, the choice of "bridge mappings" is just borrowed from the existing OVS support in OpenStack. What's implemented here matches how that works. It expects the bridge to be created already, but automatically creates patch ports to/from the integration bridge. I don't feel experienced enough with OVS to really feel confident in suggesting the proper balance between "just works" and "useful flexibility". In case this helps the discussion, one other thing needed that's not yet implemented in this series is VLAN support. We also need the ability for the Neutron adminisrator to optionally specify a VLAN ID. How to do this is probably obvious to you but I haven't tried to build it yet. I was imagining ovn-controller creating additional ports between the integration bridge and the network access bridge, one for each VLAN used on that network. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev