[openstack-dev] [tripleo] Is it time to reconsider how we configure OVS bridges in the overcloud?

Russell Bryant rbryant at redhat.com
Fri Nov 11 17:23:33 UTC 2016

On Thu, Nov 10, 2016 at 10:22 AM, Brent Eagles <beagles at redhat.com> wrote:

> To something like:
> (triple configured)
> - eth0
>  - br-ctl - used as br-ex is currently used except neutron knows nothing
> about it.
> - br-ex -patched to br-ctl - ostensibly for external traffic and this is
> what neutron in the overcloud is configured to use
> (neutron configured)
> - br-int
> - br-tun
> (In all cases, neutron configures patches, etc. between bridges *it knows
> about* as needed. That is, in the second case, tripleo would configure the
> patch between br-ctl and br-ex)
​+1.  I think this configuration makes more sense than the previous
overlapping usage of br-ex.​

> At the cost of an extra bridge (ovs bridge to ovs bridge with patch ports
> is allegedly cheap btw) we get:
​Yes, it is cheap.  I would not consider this a concern from a data path
performance point of view.  The separate bridges and patch ports only exist
in userspace.  They don't affect the fast path and the impact to the slow
path is negligible.

>  1. an independently configured bridge for overcloud traffic insulates
> non-tenant node traffic against changes to neutron, including upgrades,
> neutron bugs, etc.
>  2. insulates neutron from changes to the underlying network that it
> doesn't "care" about.
>  3. In OVS only environments, the difference between a single nic
> environment and one where there is a dedicated nic for external traffic is,
> instead of a patch port from br-ctl to br-ex, it is directly connected to
> the nic for the external traffic.
> Even without the issue that instigated this message, I think that this is
> a change worth considering.

​Nice writeup, Brent.

Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161111/2b7cd1a6/attachment.html>

More information about the OpenStack-dev mailing list