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
__________________________________________________________________________ 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
