https://review.openstack.org/#/c/540441/ is an attempt at addressing this bug
the operation that fails above, now succeeds with this change.
However I've got many OVO tests that now fail with this kind of error:
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such savepoint: sa_savepoint_1 [SQL: u'ROLLBACK TO SAVEPOINT sa_savepoint_1'] (Background on this error at: http://sqlalche.me/e/e3q8)
The other approach we discussed with Ihar was to try to see if we could find the code using the new-DB-facade for IPAllocations that gets triggered in the codepath trigerring the notifications that lead to this bug, and selectively switch this code back to using the old-DB-facade. After some research I see the following: assuming the code triggering the event callback is the L3 DB code add_interface_by_subnet, this code ends up triggering an IPAllocation by calling the core_plugin.create_port with a fixed IP, code which is using the new DB facade. I guess it is not reasonable to talk about "selectively switching back to old-DB-facade" if we talk about create_port ...
I'm currenly out of ideas on how to tackle this bug, except having the base Neutron OVO code changed to use the new DB facade.
https:/ /review. openstack. org/#/c/ 540441/ is an attempt at addressing this bug
the operation that fails above, now succeeds with this change.
However I've got many OVO tests that now fail with this kind of error:
sqlalchemy. exc.Operational Error: (sqlite3. OperationalErro r) no such savepoint: sa_savepoint_1 [SQL: u'ROLLBACK TO SAVEPOINT sa_savepoint_1'] (Background on this error at: http:// sqlalche. me/e/e3q8)
( http:// logs.openstack. org/41/ 540441/ 2/check/ openstack- tox-py27/ 7c414dd/ testr_results. html.gz )
I don't know how to solve these errors.
The other approach we discussed with Ihar was to try to see if we could find the code using the new-DB-facade for IPAllocations that gets triggered in the codepath trigerring the notifications that lead to this bug, and selectively switch this code back to using the old-DB-facade. After some research I see the following: assuming the code triggering the event callback is the L3 DB code add_interface_ by_subnet, this code ends up triggering an IPAllocation by calling the core_plugin. create_ port with a fixed IP, code which is using the new DB facade. I guess it is not reasonable to talk about "selectively switching back to old-DB-facade" if we talk about create_port ...
I'm currenly out of ideas on how to tackle this bug, except having the base Neutron OVO code changed to use the new DB facade.