[openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point

Brent Eagles beagles at redhat.com
Mon Dec 23 20:48:50 UTC 2013

Salvatore Orlando wrote:
> Before starting this post I confess I did not read with the required level
> of attention all this thread, so I apologise for any repetition.
> I just wanted to point out that floating IPs in neutron are created
> asynchronously when using the l3 agent, and I think this is clear to
> everybody.
> So when the create floating IP call returns, this does not mean the
> floating IP has actually been wired, ie: IP configured on qg-interface and
> SNAT/DNAT rules added.
> Unfortunately, neutron lacks a concept of operational status for a floating
> IP which would tell clients, including nova (it acts as a client wrt nova
> api), when a floating IP is ready to be used. I started work in this
> direction, but it has been suspended now for a week. If anybody wants to
> take over and deems this a reasonable thing to do, it will be great.

Unless somebody picks it up before I get from the break, I'd like to 
discuss this further with you.

> I think neutron tests checking connectivity might return more meaningful
> failure data if they would gather the status of the various components
> which might impact connectivity.
> These are:
> - The floating IP
> - The router internal interface
> - The VIF port
> - The DHCP agent

I agree wholeheartedly. In fact, I think if we are going to rely on 
timeouts for pass/fail we need to do more for post-mortem details.

> Collecting info about the latter is very important but a bit trickier. I
> discussed with Sean and Maru that it would be great for a starter, grep the
> console log to check whether the instance obtained an IP.
> Other things to consider would be:
> - adding an operational status to a subnet, which would express whether the
> DHCP agent is in sync with that subnet (this information won't make sense
> for subnets with dhcp disabled)
> - working on a 'debug' administrative API which could return, for instance,
> for each DHCP agent the list of configured networks and leases.


> Regarding timeouts, I think it's fair for tempest to define a timeout and
> ask that everything from VM boot to Floating IP wiring completes within
> that timeout.
> Regards,
> Salvatore

I would agree. It would be impossible to have reasonable automated 
testing otherwise.



More information about the OpenStack-dev mailing list