Open Stack

I think this bug was considered fixed because at the time once the patch
addressing was merged, the bug automatically went into fix committed.
It should therefore be re-opened. Even if tweaking sql pool parameters
avoids the issue, this should be considered more of a mitigation rather
than a permanent fix; and I'm not sure the issue and mitigation have been
properly documented.

However, I think we still need to fully understand why the effect of this
issue is two interfaces on the same instance.
Even if sql session management is improved, there could always be a chance
of pool exhaustion; not making this happen is up to the deployer (who needs
appropriate documentation to the aim).
But in case of pool exhaustion ("TimeoutError: QueuePool limit of size 5
overflow 10 reached, connection timed out, timeout 30") the effect should
probably be a 500 error when performing the neutron operation - not what's
being observed by bug 1160442.

Salvatore



On 3 December 2013 16:16, Maru Newby <marun at redhat.com> wrote:

> I recently ran into this bug while trying to concurrently boot a large
> number (75) of VMs:
>
> https://bugs.launchpad.net/neutron/+bug/1160442
>
> I see that the fix for the bug added configuration of SQLAlchemy QueuePool
> parameters that should prevent the boot failures I was seeing.  However, I
> don't see a good explanation on the bug as to what values to set the
> configuration to or why the defaults weren't updated to something sane.  If
> that information is available somewhere, please share!  I'm not sure why
> this bug is considered fixed if it's still possible to trigger it with no
> clear path to resolution.
>
>
> Maru
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/964e2f7e/attachment.html>