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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
