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


-----Original Message-----
From: Brent Eagles [] 
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


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.



OpenStack-dev mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature

OpenStack-dev mailing list

Reply via email to