<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'>Hi Guys, <br>I run into this issue trying to incorporate this test into cross_tenant_connectivity scenario: <br>launching 2 VMs in different tenants <br>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). <br>https://bugs.launchpad.net/nova/+bug/1262529 <br><br>I don't see this in: <br>1. my local RHOS-Havana setup <br>2. the cross_tenant_connectivity scenario without the control point (test passes without issues) <br>3. test_network_basic_ops runs in the gate <br><br>So here's my somewhat less experienced opinion: <br>1. this happens due to stress (more than a single FLIP/VM) <br>2. (as Brent said) Timeout interval between polling are too short <br>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. <br><br>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. <br><br>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. <br><br>Regards Yair <br>(Also added my comments inline) <br><br><hr id="zwchr"><div style="color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Jay Pipes" <jaypipes@gmail.com><br><b>To: </b>openstack-dev@lists.openstack.org<br><b>Sent: </b>Thursday, December 19, 2013 5:54:29 AM<br><b>Subject: </b>Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point<br><br>On 12/18/2013 10:21 PM, Brent Eagles wrote:<br>> Hi,<br>><br>> Yair and I were discussing a change that I initiated and was<br>> incorporated into the test_network_basic_ops test. It was intended as a<br>> configuration control point for floating IP address assignments before<br>> actually testing connectivity. The question we were discussing was<br>> whether this check was a valid pass/fail criteria for tests like<br>> test_network_basic_ops.<br>><br>> The initial motivation for the change was that test_network_basic_ops<br>> had a less than 50/50 chance of passing in my local environment for<br>> whatever reason. After looking at the test, it seemed ridiculous that it<br>> should be failing. The problem is that more often than not the data that<br>> was available in the logs all pointed to it being set up correctly but<br>> the ping test for connectivity was timing out. From the logs it wasn't<br>> clear that the test was failing because neutron did not do the right<br>> thing, did not do it fast enough, or is something else happening?  Of<br>> course if I paused the test for a short bit between setup and the checks<br>> to manually verify everything the checks always passed. So it's a timing<br>> issue right?<br>><br><br>DID anyone else see experience this issue? locally or on the gate?<br><br>> Two things: adding more timeout to a check is as appealing to me as<br>> gargling glass AND I was less "annoyed" that the test was failing as I<br>> was that it wasn't clear from reading logs what had gone wrong. I tried<br>> to find an additional intermediate control point that would "split"<br>> failure modes into two categories: neutron is too slow in setting things<br>> up and neutron failed to set things up correctly. Granted it still is<br>> adding timeout to the test, but if I could find a control point based on<br>> "settling" so that if it passed, then there is a good chance that if the<br>> next check failed it was because neutron actually screwed up what it was<br>> trying to do.<br>><br>> Waiting until the query on the nova for the floating IP information<br>> seemed a relatively reasonable, if imperfect, "settling" criteria before<br>> attempting to connect to the VM. Testing to see if the floating IP<br>> assignment gets to the nova instance details is a valid test and,<br>> AFAICT, missing from the current tests. However, Yair has the reasonable<br>> point that connectivity is often available long before the floating IP<br>> appears in the nova results and that it could be considered invalid to<br>> use non-network specific criteria as pass/fail for this test.<br><br>But, Tempest is all about functional integration testing. Using a call <br>to Nova's server details to determine whether a dependent call to <br>Neutron succeeded (setting up the floating IP) is exactly what I think <br>Tempest is all about. It's validating that the integration between Nova <br>and Neutron is working as expected.<br><br>So, I actually think the assertion on the floating IP address appearing <br>(after some timeout/timeout-backoff) is entirely appropriate.<br><br>Blocking the connectivity check until DB is updated doesn't make sense to me, since we know FLIP is reachable well before nova DB is updated (this is seen also in manual mode, not just by automation timing standards)<br><br>> In general, the validity of checking for the presence of a floating IP<br>> in the server details is a matter of interpretation. I think it is a<br>> given that it must be tested somewhere and that if it causes a test to<br>> fail then it is as valid a failure than a ping failing. Certainly I have<br>> seen scenarios where an IP appears, but doesn't actually work and others<br>> where the IP doesn't appear (ever, not just in really long while) but<br>> magically works. Both are bugs. Which is more appropriate to tests like<br>> test_network_basic_ops?<br><br>I believe both assertions should be part of the test cases, but since <br>the latter condition (good ping connectivity, but no floater ever <br>appears attached to the instance) necessarily depends on the first <br>failure (floating IP does not appear in the server details after a <br>timeout), then perhaps one way to handle this would be to do this:<br><br>a) create server instance<br>b) assign floating ip<br>c) query server details looking for floater in a timeout-backoff loop<br>c1) floater does appear<br>  c1-a) assert ping connectivity<br>c2) floater does not appear<br>  c2-a) check ping connectivity. if ping connectivity succeeds, use a <br>call to testtools.TestCase.addDetail() to provide some "interesting" <br>feedback<br>  c2-b) raise assertion that floater did not appear in the server details<br><br>IMO This should be a different stress scenario and not part of network_basic_ops<br><br>> Currently, the polling interval for the checks in the gate should be<br>> tuned. They are borrowing other polling configuration and I can see it<br>> is ill-advised. It is currently polling at an interval of a second and<br>> if the intent is to wait for the entire system to settle down before<br>> proceeding then polling nova that quickly is too often. It simply<br>> increases the load while we are waiting to adapt to a loaded system. For<br>> example in the course of a three minute timeout, the floating IP check<br>> polled nova for server details 180 times.<br><br>Agreed completely.<br><br>Best,<br>-jay<br><br>> All this aside it is granted that checking for the floating IP in the<br>> nova instance details is imperfect in itself. There is nothing that<br>> assures that the presence of that information indicates that the<br>> networking backend is done its work.<br>><br>> Comments, suggestions, queries, foam bricks?<br>><br>> Cheers,<br>><br>> Brent<br>><br>> _______________________________________________<br>> OpenStack-dev mailing list<br>> OpenStack-dev@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br><br><br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div><br></div></body></html>