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.
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. 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. 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. 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. These are: - The floating IP - The router internal interface - The VIF port - The DHCP agent 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. Other things to consider would be: - 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) - working on a 'debug' administrative API which could return, for instance, for each DHCP agent the list of configured networks and leases. 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. Regards, Salvatore On 19 December 2013 16:15, Frittoli, Andrea (Cloud Services) < fritt...@hp.com> wrote: > My 2 cents: > > In the test the floating IP is created via neutron API and later checked > via > nova API. > > So the test is relying here (or trying to verify?) the network cache > refresh > mechanism in nova. > This is something that we should test, but in a test dedicated to this. > > The primary objective of test_network_basic_ops is to verify the network > plumbing and end-to-end connectivity, so it should be decoupled from things > like network cache refresh. > > If the floating IP is associated via neutron API, only the neutron API will > report the associated in a timely manner. > Else if the floating IP is created via the nova API, this will update the > network cache automatically, not relying on the cache refresh mechanism, so > both neutron and nova API will report the associated in a timely manner > (this did not work some weeks ago, so it something tempest tests should > catch). > > andrea > > -----Original Message----- > From: Brent Eagles [mailto:beag...@redhat.com] > Sent: 19 December 2013 14:53 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the > "FloatingIPChecker" control point > > Hi, > > Yair Fried wrote: > > 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 > > Agreed. I think that's an extremely important highlight of this discussion. > Propagation of the floating IP is definitely bugged. In the small sample of > logs (2) that I checked, the floating IP assignment propagated in around 10 > seconds for test_network_basic_ops, but in the cross tenant connectivity > test it took somewhere around 1 minute for the first assignment and > something over 3 (otherwise known as simply-too-long-to-find-out). Even if > the querying of once a second were excessive - which I do not feel strong > enough about to say is anything other than a *possible* contributing factor > - it should not take that long. > > Cheers, > > Brent > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev