Open Stack

Hi Dan,

On Thu, Nov 10, 2016 at 1:25 PM, Dan Sneddon <dsneddon at redhat.com> wrote:

> ​<snip/>
>
> Brent,
>
> Thanks for taking the time to analyze this situation. I see a couple of
> potential issues with the topology you are suggesting.
>
> First of all, what about the scenario where a system has only 2x10Gb
> NICs, and the operator wishes to bond these together on a single
> bridge? If we require separate bridges for Neutron than we do for the
> control plane, then it would be impossible to configure a system with
> only 2 NICs in a fault-tolerant way.
>

Unless I'm missing something, I think this would be similar to the single
NIC case. In the case where there is only bond, it would be bridged to the
main overcloud bridge (e.g. br-ctl) and any bridges for external traffic
(e.g. br-ex) would be patched to that. The fault tolerance of the bond
would still be available to all. The cost would be whatever extra overhead
the br-ex->br-ctl patch ports incur.


>
> Second, there will be a large percentage of users who already have a
> shared br-ex that wish to upgrade. Do we tell them that due to an
> architectural change, they now must redeploy a new cloud with a new
> topology to use the latest version?
>

> So while I would be on-board with changing our default for new
> installations, I don't think that relieves us of the responsibility to
> figure out how to handle the edge cases where a separate bridge is not
> feasible.
> ​
>


> --
> Dan Sneddon         |  Senior Principal OpenStack Engineer
>
>
​This is a very good and important point. Migration could be a pain. If it
is a bridge that neutron uses, it manipulates them pretty quickly after
startup. However, if an update would only write the ifcfg changes and
require a rebooting for them to take affect, then that might take care of
that. Probably more problematic is the other IPs that are assigned to the
"main" bridge. If it's keying on the bridge name then that becomes a
problem. If it's the IP, then it should follow the bridge. There is also
the danger of any other number of dependencies or tooling that might need
updating. The bright spot is that neutron's config wouldn't actually
change. In short, it would probably be doable, but I find myself feeling
that I wouldn't recommend it unless it was absolutely necessary and/or fit
some kind of scenario that we had worked out was extremely low risk and
tested heavily.

Cheers,

Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161111/2747da9f/attachment.html>