Ah, that was a bit misleading. We're not leaking any floating IPs. The create method for them adds them to a list that is cleaned up on teardown.
The issue was that the get_unused_ip method was iterating over v4 and v6 subnets. So if it happened to pick a v6 subnet, it would cause the test to request a floating IP address with a v6 IP address, which isn't valid. Fix is up here: https://review.openstack.org/264599 On Wed, Jan 6, 2016 at 10:03 PM, Kevin Benton <blak...@gmail.com> wrote: > I spoke too soon. The test is racey and needs to be fixed, but that wasn't > the cause of this failure. Floating IPs are being leaked as Clark > suggested. I'm looking into it now. > > On Wed, Jan 6, 2016 at 9:09 PM, Kevin Benton <blak...@gmail.com> wrote: > >> Ugh, this test is racey. I should have paid closer attention before I >> +2'ed, my bad. >> >> It just iterates external ports and uses an IP not in that list so if >> another test grabbed the same IP, the floating IP creation request >> specifying that IP will fail. >> >> Revert proposed here: https://review.openstack.org/#/c/264573/ >> >> On Wed, Jan 6, 2016 at 9:00 PM, Clark Boylan <cboy...@sapwetik.org> >> wrote: >> >>> On Wed, Jan 6, 2016, at 08:48 PM, Henry Gessau wrote: >>> > Armando M. <arma...@gmail.com> wrote: >>> > > Hi folks, >>> > > >>> > > Due to [1], Neutron related jobs (api, and lbaas) are failing. >>> Please hold >>> > > your +A button until the issue is resolved. >>> > > >>> > > Thanks, >>> > > Armando >>> > > >>> > > [1] https://review.openstack.org/#/c/256164/ >>> > >>> > That fix has merged, but now we have a new issue [2] in the api job. :( >>> > >>> > [2] https://bugs.launchpad.net/neutron/+bug/1531706 >>> > >>> It appears that that test class at least is allocating unused floating >>> IPs in resource_setup(). At the very least you can probably stop >>> overallocating to give yourself some breathing room. I do not think this >>> explains how an entire /24 of IPs gets used up so there may be a leak >>> elsewhere. >>> >>> Clark >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Kevin Benton >> > > > > -- > Kevin Benton > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev