<div dir="ltr">Hi Maru, <div><br></div><div>Thanks for getting this thread started. I've filed the following blueprint for this:</div><div><br></div><div><a href="https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status">https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status</a> </div>
<div><br></div><div>and have a have a prototype of it working here: </div><div><br></div><div><a href="https://review.openstack.org/#/c/74197/">https://review.openstack.org/#/c/74197/</a></div><div><a href="https://review.openstack.org/#/c/74218/">https://review.openstack.org/#/c/74218/</a> </div>
<div><br></div><div>One part that threw me a little while getting this working is that if using ovs and the new libvirt_vif_driver LibvirtGenericVifDriver, nova no longer calls ovs-vsctl to set external_ids:iface-id and that libvirt automatically does that for you. Unfortunately, this data seems to only make it to ovsdb when the instance is powered on. Because of this I needed to add back those calls as neutron needs this data to be set in ovsdb before it can start wiring the ports. </div>
<div><br></div><div>I'm hoping this change should help out with <a href="https://bugs.launchpad.net/neutron/+bug/1253896">https://bugs.launchpad.net/neutron/+bug/1253896</a> but we'll see. I'm not sure if it's to late to merge this in icehouse but it might be worth considering if we find that it helps reduce gate failures. </div>
<div><br></div><div>Best, </div><div><br></div><div>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 3:31 AM, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 for this feature which could potentially resolve a race condition<br>
that could occur after port-binding refactoring in ML2 [1].<br>
in ML2, the port could be ACTIVE once a MD has bound the port. the<br>
vif_type could then be known by nova, and nova could create the<br>
network correctly thanks to vif_type and vif_details ( with<br>
vif_security embedded [2])<br>
<br>
[1]<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/026750.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-February/026750.html</a><br>
[2]<a href="https://review.openstack.org/#/c/72452/" target="_blank">https://review.openstack.org/#/c/72452/</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Feb 13, 2014 at 3:13 AM, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
> Booting a Nova instance when Neutron is enabled is often unreliable due to the lack of coordination between Nova and Neutron apart from port allocation.  Aaron Rosen and I have been talking about fixing this by having Nova perform a check for port 'liveness' after vif plug and before vm boot.  The idea is to have Nova fail the instance if its ports are not seen to be 'live' within a reasonable timeframe after plug.  Our initial thought is that the compute node would call Nova's networking subsystem which could query Neutron for the status of the instance's ports.<br>

><br>
> The open question is whether the port 'status' field can be relied upon to become ACTIVE for all the plugins currently in the tree.  If this is not the case, please reply to this thread with an indication of how one would be able to tell the 'liveness' of a port managed by the plugin you maintain.<br>

><br>
> In the event that one or more plugins cannot reliably indicate port liveness, we'll need to ensure that the port liveness check can be optionally disabled so that the existing behavior of racing vm boot is maintained for plugins that need it.<br>

><br>
> Thanks in advance,<br>
><br>
><br>
> Maru<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>