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 ma...@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@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
