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

Frittoli, Andrea (Cloud Services) frittoli at hp.com
Thu Dec 19 15:15:45 UTC 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6202 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131219/bde7b3e8/attachment.bin>


More information about the OpenStack-dev mailing list