Open Stack

Hi Maru,

Thanks for getting this thread started. I've filed the following blueprint
for this:

https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status

and have a have a prototype of it working here:

https://review.openstack.org/#/c/74197/
https://review.openstack.org/#/c/74218/

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.

I'm hoping this change should help out with
https://bugs.launchpad.net/neutron/+bug/1253896 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.

Best,

Aaron


On Thu, Feb 13, 2014 at 3:31 AM, Mathieu Rohon <mathieu.rohon at gmail.com>wrote:

> +1 for this feature which could potentially resolve a race condition
> that could occur after port-binding refactoring in ML2 [1].
> in ML2, the port could be ACTIVE once a MD has bound the port. the
> vif_type could then be known by nova, and nova could create the
> network correctly thanks to vif_type and vif_details ( with
> vif_security embedded [2])
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026750.html
> [2]https://review.openstack.org/#/c/72452/
>
> On Thu, Feb 13, 2014 at 3:13 AM, Maru Newby <marun at redhat.com> wrote:
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Thanks in advance,
> >
> >
> > Maru
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140217/29b10c21/attachment.html>