[ovs-dev] [RFC v2 04/11] ovn: Add patch ports for ovn bridge mappings.

[Russell Bryant]

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 <rbryant at 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