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

Salvatore Orlando sorlando at nicira.com
Fri Dec 20 01:24:19 UTC 2013


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.

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

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


On 19 December 2013 16:15, Frittoli, Andrea (Cloud Services) <
frittoli at hp.com> wrote:

> My 2 cents:
>
> In the test the floating IP is created via neutron API and later checked
> via
> nova API.
>
> So the test is relying here (or trying to verify?) the network cache
> refresh
> mechanism in nova.
> This is something that we should test, but in a test dedicated to this.
>
> The primary objective of test_network_basic_ops is to verify the network
> plumbing and end-to-end connectivity, so it should be decoupled from things
> like network cache refresh.
>
> If the floating IP is associated via neutron API, only the neutron API will
> report the associated in a timely manner.
> Else if the floating IP is created via the nova API, this will update the
> network cache automatically, not relying on the cache refresh mechanism, so
> both neutron and nova API will report the associated in a timely manner
> (this did not work some weeks ago, so it something tempest tests should
> catch).
>
> andrea
>
> -----Original Message-----
> From: Brent Eagles [mailto:beagles at redhat.com]
> Sent: 19 December 2013 14:53
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the
> "FloatingIPChecker" control point
>
> Hi,
>
> Yair Fried wrote:
> > I would also like to point out that, since Brent used
> > compute.build_timeout as the timeout value ***It takes more time to
> > update FLIP in nova DB, than for a VM to build***
> >
> > Yair
>
> Agreed. I think that's an extremely important highlight of this discussion.
> Propagation of the floating IP is definitely bugged. In the small sample of
> logs (2) that I checked, the floating IP assignment propagated in around 10
> seconds for test_network_basic_ops, but in the cross tenant connectivity
> test it took somewhere around 1 minute for the first assignment and
> something over 3 (otherwise known as simply-too-long-to-find-out). Even if
> the querying of once a second were excessive - which I do not feel strong
> enough about to say is anything other than a *possible* contributing factor
> - it should not take that long.
>
> Cheers,
>
> Brent
>
> _______________________________________________
> 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/20131220/66cc024f/attachment.html>


More information about the OpenStack-dev mailing list