<div dir="ltr">Hi <span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Mathieu, </span><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">The current train of thought is to have neutron notify nova via a call back when ports are ready. This model should hopefully scale better as now nova-compute won't need to poll on neutron checking on the port status. Dan Smith already has a patch out that adds an api to nova for it to receive external events : </span><a href="https://review.openstack.org/#/c/74565/">https://review.openstack.org/#/c/74565/</a>  that neutron can use for this.</div>
<div><br></div><div>I abandoned that patch as it takes the approach of polling neutron from nova-compute which we don't want. </div><div><br></div><div>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Feb 19, 2014 at 12:58 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">
Hi Aaron,<br>
<br>
You seem to have abandonned this patch :<br>
<a href="https://review.openstack.org/#/c/74218/" target="_blank">https://review.openstack.org/#/c/74218/</a><br>
<br>
You want neutron to update port in nova, can you please tell us how do<br>
you want to do that?<br>
<br>
I think that we should use such a mechanism for live-migration.<br>
live-migration should occur once the port is set up on the destination<br>
host. This could potentially resolve this bug :<br>
<br>
<a href="https://bugs.launchpad.net/neutron/+bug/1274160" target="_blank">https://bugs.launchpad.net/neutron/+bug/1274160</a><br>
<br>
Best,<br>
<br>
Mathieu<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Feb 18, 2014 at 2:55 AM, Aaron Rosen <<a href="mailto:aaronorosen@gmail.com">aaronorosen@gmail.com</a>> wrote:<br>
> Hi Maru,<br>
><br>
> Thanks for getting this thread started. I've filed the following blueprint<br>
> for this:<br>
><br>
> <a href="https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status" target="_blank">https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status</a><br>
><br>
> and have a have a prototype of it working here:<br>
><br>
> <a href="https://review.openstack.org/#/c/74197/" target="_blank">https://review.openstack.org/#/c/74197/</a><br>
> <a href="https://review.openstack.org/#/c/74218/" target="_blank">https://review.openstack.org/#/c/74218/</a><br>
><br>
> One part that threw me a little while getting this working is that if using<br>
> ovs and the new libvirt_vif_driver LibvirtGenericVifDriver, nova no longer<br>
> calls ovs-vsctl to set external_ids:iface-id and that libvirt automatically<br>
> does that for you. Unfortunately, this data seems to only make it to ovsdb<br>
> when the instance is powered on. Because of this I needed to add back those<br>
> calls as neutron needs this data to be set in ovsdb before it can start<br>
> wiring the ports.<br>
><br>
> I'm hoping this change should help out with<br>
> <a href="https://bugs.launchpad.net/neutron/+bug/1253896" target="_blank">https://bugs.launchpad.net/neutron/+bug/1253896</a> but we'll see. I'm not sure<br>
> if it's to late to merge this in icehouse but it might be worth considering<br>
> if we find that it helps reduce gate failures.<br>
><br>
> Best,<br>
><br>
> Aaron<br>
><br>
><br>
> On Thu, Feb 13, 2014 at 3:31 AM, Mathieu Rohon <<a href="mailto:mathieu.rohon@gmail.com">mathieu.rohon@gmail.com</a>><br>
> wrote:<br>
>><br>
>> +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>
>><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>
>><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<br>
>> > to the lack of coordination between Nova and Neutron apart from port<br>
>> > allocation.  Aaron Rosen and I have been talking about fixing this by having<br>
>> > Nova perform a check for port 'liveness' after vif plug and before vm boot.<br>
>> > The idea is to have Nova fail the instance if its ports are not seen to be<br>
>> > 'live' within a reasonable timeframe after plug.  Our initial thought is<br>
>> > that the compute node would call Nova's networking subsystem which could<br>
>> > 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<br>
>> > to become ACTIVE for all the plugins currently in the tree.  If this is not<br>
>> > the case, please reply to this thread with an indication of how one would be<br>
>> > 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<br>
>> > liveness, we'll need to ensure that the port liveness check can be<br>
>> > optionally disabled so that the existing behavior of racing vm boot is<br>
>> > 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>
><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>
_______________________________________________<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>