<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Tue, Aug 21, 2018, 8:29 AM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/21/2018 7:28 AM, Matt Riedemann wrote:<br>
> On 8/20/2018 3:18 PM, Sean Mooney wrote:<br>
>> in both the ovs-dpdk tests, when the migration failed and the vm<br>
>> contiuned to run on the source node however<br>
>> it had no network connectivity. on hard reboot of the vm, it went to<br>
>> error state because the vif binding<br>
>> was set to none as the vif:bidning-details:host_id  was set to none so<br>
>> the vif_type was also set to none.<br>
>> i have opened a nova bug to track the fact that the vm is left in an<br>
>> invalid state even though the status is active.<br>
>> see bug 1788014<br>
> <br>
> I've got a nova patch for this here:<br>
> <br>
> <a href="https://review.openstack.org/#/c/594139/" rel="noreferrer noreferrer" target="_blank">https://review.openstack.org/#/c/594139/</a><br>
> <br>
> However, I'd like Miguel to look at that bug because I assumed that when <br>
> nova deletes the dest host port binding, the only remaining port binding <br>
> is the inactive one for the source host, and neutron would automatically <br>
> activate it, similar to how neutron will automatically deactivate all <br>
> other bindings for a port when one of the other bindings is activated <br>
> (like when nova activates the dest host port binding during live <br>
> migration, the source host port binding is automatically deactivated <br>
> because only one port binding can be active at any time). If there is a <br>
> good reason why neutron doesn't do this on port binding delete, then I <br>
> guess we go with fixing this in nova.<br>
> <br>
<br>
By the way, Sean, thanks a ton for doing all of this testing. It's super <br>
helpful and way above anything I could have gotten setup myself for the <br>
various neutron backend configurations.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Agreed, big +1 and thanks to Sean for doing this.</div><div dir="auto"><br></div><div dir="auto">However, I'd like to point out that this highlights the unfortunate situation we're in: only a select couple contributors actually are able to understand the overly complex, ludicrously inconsistent, and all too often incompatible networking technologies that OpenStack has come to rely on 😐</div><div dir="auto"><br></div><div dir="auto">This reminds me of a recent conversation I had on Twitter with an old coworker of mine who is now at booking. com who stated the frustrating complexity of networking and SDN setup in OpenStack was the reason he switched to Kubernetes and hasn't looked back since.</div><div dir="auto"><br></div><div dir="auto">-jay</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Matt<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>