Open Stack

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

----- Original Message -----
From: "Sean Dague" <sean at dague.net>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Sent: Thursday, December 19, 2013 12:42:56 PM
Subject: Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point

On 12/19/2013 03:31 AM, Yair Fried wrote:
> Hi Guys,
> I run into this issue trying to incorporate this test into
> cross_tenant_connectivity scenario:
> launching 2 VMs in different tenants
> What I saw, is that in the gate it fails half the time (the original
> test passes without issues) and ONLY on the 2nd VM (the first FLIP
> propagates fine).
> https://bugs.launchpad.net/nova/+bug/1262529
> 
> I don't see this in:
> 1. my local RHOS-Havana setup
> 2. the cross_tenant_connectivity scenario without the control point
> (test passes without issues)
> 3. test_network_basic_ops runs in the gate
> 
> So here's my somewhat less experienced opinion:
> 1. this happens due to stress (more than a single FLIP/VM)
> 2. (as Brent said) Timeout interval between polling are too short
> 3. FLIP is usually reachable long before it is seen in the nova DB (also
> from manual experience), so blocking the test until it reaches the nova
> DB doesn't make sense for me. if we could do this in different thread,
> then maybe, but using a Pass/Fail criteria to test for a timing issue
> seems wrong. Especially since as I understand it, the issue is on IF it
> reaches nova DB, only WHEN.
> 
> I would like to, at least, move this check from its place as a blocker
> to later in the test. Before this is done, I would like to know if
> anyone else has seen the same problems Brent describes prior to this
> patch being merged.
>
> Regarding Jay's scenario suggestion, I think this should not be a part
> of network_basic_ops, but rather a separate stress scenario creating
> multiple VMs and testing for FLIP associations and propagation time.

+1 there is no need to overload that one scenario. A dedicated one would
be fine.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev