<div dir="ltr">Before starting this post I confess I did not read with the required level of attention all this thread, so I apologise for any repetition.<div><br></div><div>I just wanted to point out that floating IPs in neutron are created asynchronously when using the l3 agent, and I think this is clear to everybody.</div>
<div>So when the create floating IP call returns, this does not mean the floating IP has actually been wired, ie: IP configured on qg-interface and SNAT/DNAT rules added.</div><div><br></div><div>Unfortunately, neutron lacks a concept of operational status for a floating IP which would tell clients, including nova (it acts as a client wrt nova api), when a floating IP is ready to be used. I started work in this direction, but it has been suspended now for a week. If anybody wants to take over and deems this a reasonable thing to do, it will be great.</div>
<div><br></div><div>I think neutron tests checking connectivity might return more meaningful failure data if they would gather the status of the various components which might impact connectivity.</div><div>These are:</div>
<div>- The floating IP</div><div>- The router internal interface</div><div>- The VIF port</div><div>- The DHCP agent</div><div><br></div><div>Collecting info about the latter is very important but a bit trickier. I discussed with Sean and Maru that it would be great for a starter, grep the console log to check whether the instance obtained an IP.</div>
<div>Other things to consider would be:</div><div>- adding an operational status to a subnet, which would express whether the DHCP agent is in sync with that subnet (this information won't make sense for subnets with dhcp disabled)</div>
<div>- working on a 'debug' administrative API which could return, for instance, for each DHCP agent the list of configured networks and leases.</div><div><br></div><div>Regarding timeouts, I think it's fair for tempest to define a timeout and ask that everything from VM boot to Floating IP wiring completes within that timeout.</div>
<div><br></div><div>Regards,</div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 December 2013 16:15, Frittoli, Andrea (Cloud Services) <span dir="ltr"><<a href="mailto:frittoli@hp.com" target="_blank">frittoli@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My 2 cents:<br>
<br>
In the test the floating IP is created via neutron API and later checked via<br>
nova API.<br>
<br>
So the test is relying here (or trying to verify?) the network cache refresh<br>
mechanism in nova.<br>
This is something that we should test, but in a test dedicated to this.<br>
<br>
The primary objective of test_network_basic_ops is to verify the network<br>
plumbing and end-to-end connectivity, so it should be decoupled from things<br>
like network cache refresh.<br>
<br>
If the floating IP is associated via neutron API, only the neutron API will<br>
report the associated in a timely manner.<br>
Else if the floating IP is created via the nova API, this will update the<br>
network cache automatically, not relying on the cache refresh mechanism, so<br>
both neutron and nova API will report the associated in a timely manner<br>
(this did not work some weeks ago, so it something tempest tests should<br>
catch).<br>
<span class="HOEnZb"><font color="#888888"><br>
andrea<br>
</font></span><div class="im HOEnZb"><br>
-----Original Message-----<br>
From: Brent Eagles [mailto:<a href="mailto:beagles@redhat.com">beagles@redhat.com</a>]<br>
Sent: 19 December 2013 14:53<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
</div><div class="im HOEnZb">Subject: Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the<br>
"FloatingIPChecker" control point<br>
<br>
</div><div class="HOEnZb"><div class="h5">Hi,<br>
<br>
Yair Fried wrote:<br>
> I would also like to point out that, since Brent used<br>
> compute.build_timeout as the timeout value ***It takes more time to<br>
> update FLIP in nova DB, than for a VM to build***<br>
><br>
> Yair<br>
<br>
Agreed. I think that's an extremely important highlight of this discussion.<br>
Propagation of the floating IP is definitely bugged. In the small sample of<br>
logs (2) that I checked, the floating IP assignment propagated in around 10<br>
seconds for test_network_basic_ops, but in the cross tenant connectivity<br>
test it took somewhere around 1 minute for the first assignment and<br>
something over 3 (otherwise known as simply-too-long-to-find-out). Even if<br>
the querying of once a second were excessive - which I do not feel strong<br>
enough about to say is anything other than a *possible* contributing factor<br>
- it should not take that long.<br>
<br>
Cheers,<br>
<br>
Brent<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>