Open Stack

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 <cboylan at sapwetik.org> wrote:

> On Wed, Jan 6, 2016, at 08:48 PM, Henry Gessau wrote:
> > Armando M. <armamig at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160106/2a13cfee/attachment.html>