Open Stack

+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