----- Original Message ----- > From: "Brent Eagles" <beag...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Monday, December 23, 2013 10:48:50 PM > Subject: Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the > "FloatingIPChecker" control point > > Salvatore Orlando wrote: > > 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. > > Unless somebody picks it up before I get from the break, I'd like to > discuss this further with you. > > > 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 I wrote something addressing at least some of these points: https://review.openstack.org/#/c/55146/ > > I agree wholeheartedly. In fact, I think if we are going to rely on > timeouts for pass/fail we need to do more for post-mortem details. > > > 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. > > Interesting! > > > 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 > > I would agree. It would be impossible to have reasonable automated > testing otherwise. > > 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