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" <[email protected]> To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> 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 [email protected] / [email protected] http://dague.net _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
