Looks like my initial analysis in not fully correct. So now it looks like this error is observed due to using nested transaction in allocate block of reference ipam driver [1]:
Resulting error:
2016-04-13 12:15:04.685 18292 ERROR oslo_db.sqlalchemy.exc_filters [req-15281429-cfa8-4b9f-a904-0105fc947933 admin -] DBAPIError exception wrapped from (pymysql.err.InternalError) (1305, u'SAVEPOINT sa_savepoint_3 does not exist') [SQL: u'ROLLBACK TO SAVEPOINT sa_savepoint_3']
Original error:
<class 'oslo_db.exception.DBDeadlock'> (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') [SQL: u'INSERT INTO ipamallocations (ip_address, status, ipam_subnet_id) VALUES (%(ip_address)s, %(status)s, %(ipam_subnet_id)s)'] [parameters: {'status': 'ALLOCATED', 'ip_address': u'2001:db8::4e', 'ipam_subnet_id': u'1c084441-cec0-4865-848a-a75f01711e36'}]
When DBDeadlock is raised inside nested transaction block, nested transaction wrapper tries to rollback to safepoint where nested transaction was initiated. But looks like in DBDeadlock case this is not possible.
Looks like my initial analysis in not fully correct. So now it looks like this error is observed due to using nested transaction in allocate block of reference ipam driver [1]:
Resulting error: sqlalchemy. exc_filters [req-15281429- cfa8-4b9f- a904-0105fc9479 33 admin -] DBAPIError exception wrapped from (pymysql. err.InternalErr or) (1305, u'SAVEPOINT sa_savepoint_3 does not exist') [SQL: u'ROLLBACK TO SAVEPOINT sa_savepoint_3']
2016-04-13 12:15:04.685 18292 ERROR oslo_db.
Original error: exception. DBDeadlock' > (pymysql. err.InternalErr or) (1213, u'Deadlock found when trying to get lock; try restarting transaction') [SQL: u'INSERT INTO ipamallocations (ip_address, status, ipam_subnet_id) VALUES (%(ip_address)s, %(status)s, %(ipam_ subnet_ id)s)'] [parameters: {'status': 'ALLOCATED', 'ip_address': u'2001:db8::4e', 'ipam_subnet_id': u'1c084441- cec0-4865- 848a-a75f01711e 36'}]
<class 'oslo_db.
When DBDeadlock is raised inside nested transaction block, nested transaction wrapper tries to rollback to safepoint where nested transaction was initiated. But looks like in DBDeadlock case this is not possible.
[1] https:/ /github. com/openstack/ neutron/ blob/2dc9d67f6e 0fbec8272dc1dfd b594d05378536d5 /neutron/ ipam/drivers/ neutrondb_ ipam/driver. py#L338