[openstack-dev] [neutron] Seeing db lockout issues in neutron add_router_interface

Divya divya.hc at gmail.com
Wed May 11 06:17:03 UTC 2016


Thanks Kevin for the response.
Kevin, this is stable/kilo (customer is still on stable/kilo),is pymysql
supported in stable/kilo??

Thanks & Regards,
Divya

On Tue, May 10, 2016 at 10:36 PM, Kevin Benton <kevin at benton.pub> wrote:

> In addition to what Mike said, "Lock wait timeout exceeded" sounds like an
> error from the C-based mysql driver that eventlet couldn't recognize
> yielding calls on. We have moved away from that upstream for quite some
> time now. Ensure your DB connection string starts with 'mysql+pymysql://'
> to use the pymysql one.
>
> On Tue, May 10, 2016 at 4:54 PM, Mike Bayer <mbayer at redhat.com> wrote:
>
>>
>>
>> On 05/10/2016 04:57 PM, Divya wrote:
>>
>>> Hi,
>>>     I am trying to run this rally test on stable/kilo
>>>
>>> https://github.com/openstack/rally/blob/master/samples/tasks/scenarios/neutron/create_and_delete_routers.json
>>>
>>> with concurrency 50 and iterations 2000.
>>>
>>> This test basically cretaes routers and subnets
>>> and then calls
>>> router-interface-add
>>> router-interface-delete
>>>
>>>
>>> And i am running this against 3rd party Nuage plugin.
>>>
>>> In the NuagePlugin:
>>>
>>> add_router_interface is something like this:
>>> ----------------------------
>>> super().add_router_interface
>>> try:
>>>    some calls to external rest server
>>>    super().delete_port
>>> except:
>>>
>>> remove_router_interface:
>>> -----------------------------------
>>> super().remove_router_interface
>>> some calls to external rest server
>>> super().create_port()
>>> some calls to external rest server
>>>
>>>
>>> If i comment delete_port in the add_router_interface, i am not hitting
>>> the db lockout issue.
>>> delete_port or any other operations are not within any transaction.
>>> So not sure, why this is leading to db lock timeouts in insert to
>>> routerport
>>>
>>> error trace
>>> http://paste.openstack.org/show/496626/
>>>
>>>
>>>
>>> Really appreciate any help on this.
>>>
>>
>>
>> I'm not on the Neutron team, but in general, Openstack applications
>> should be employing retry logic internally which anticipates database
>> deadlocks like these and retries the operation.  I'd report this stack
>> trace (especially if it is reproducible) as a bug to this plugin's
>> launchpad project.
>>
>>
>>
>>
>>> Thanks,
>>> Divya
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160510/c0a731b0/attachment.html>


More information about the OpenStack-dev mailing list