On 07/17/2015 04:04 PM, Ben Pfaff wrote: > On Fri, Jul 17, 2015 at 03:20:00PM -0400, Russell Bryant wrote: >> 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. > > Absolutely. > >> 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. > > I agree.
Yay. Consider that on my todo list then. >> 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". > > I didn't know there was precedent here. How is the configuration > conveyed to that existing plugin? I mean, where does it get the > configuration from (presumably it's not from the same external-ids key > but if it is then so much the better). > > Looking at an installation manual, it looks like it's configured through > essentially an old-school Windows INI file with a .conf extension. I > don't know whether that's better or worse than the OVS DB. Yes, it's in an ini conf file. Similar style conf files are used for all OpenStack services. I actually think a conf file would be easier than ovsdb for ovn-controller config. That seems easier to manage from config management tools (puppet, chef, ...). >> 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. > > I think you just need to set the "tag" column on the patch port that is > added to the physical bridge to the desired VLAN ID. Yes, if there's > more than one VLAN then you'd want multiple pairs of patch ports. Great, that's what I thought. Thanks for confirming! -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
