<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hi Dan,</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 10, 2016 at 1:25 PM, Dan Sneddon <span dir="ltr"><<a href="mailto:dsneddon@redhat.com" target="_blank">dsneddon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-3451801553426501677HOEnZb"><div class="m_-3451801553426501677h5"><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><snip/></div></div></div>
<br>
Brent,<br>
<br>
Thanks for taking the time to analyze this situation. I see a couple of<br>
potential issues with the topology you are suggesting.<br>
<br>
First of all, what about the scenario where a system has only 2x10Gb<br>
NICs, and the operator wishes to bond these together on a single<br>
bridge? If we require separate bridges for Neutron than we do for the<br>
control plane, then it would be impossible to configure a system with<br>
only 2 NICs in a fault-tolerant way.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">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.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Second, there will be a large percentage of users who already have a<br>
shared br-ex that wish to upgrade. Do we tell them that due to an<br>
architectural change, they now must redeploy a new cloud with a new<br>
topology to use the latest version?<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
So while I would be on-board with changing our default for new<br>
installations, I don't think that relieves us of the responsibility to<br>
figure out how to handle the edge cases where a separate bridge is not<br>
feasible.<div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-3451801553426501677HOEnZb"><font color="#888888"><br>
--<br>
Dan Sneddon | Senior Principal OpenStack Engineer<br><br></font></span></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">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. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Cheers,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Brent</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div></div></div></div>