db_plugin.delete_ports() can lead to long transaction if plugin.deleete_port talks with external system
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
High
|
Akihiro Motoki |
Bug Description
db_plugin.
it is observed first in nec plugin (bug 1282922), but it affects multiple plugins/drivers.
Note that it is about delete_ports and not about delete_port.
The detail is described in bug 1282922. Quoted from the original bug report.
----
The case I observed is that delete-port from dhcp-agent (release_dhcp_port RPC call) and delete-port from delete-network API request are run in parallel. plugin.delete-port in nec plugin calls REST API call to an external controller in addition to operates on neutron database.
After my investigation and testing, db_plugin.
https:/
This means the transaction continues over API calls to external controller and it leads to a long transaction.
When plugin.
----
description: | updated |
tags: | added: ml2 nec |
Changed in neutron: | |
milestone: | icehouse-3 → icehouse-rc1 |
Changed in neutron: | |
status: | Fix Committed → Fix Released |
Changed in neutron: | |
milestone: | icehouse-rc1 → 2014.1 |
The adhoc approach is to remove the transaction from db_plugin. delete_ ports() .
This removes long transaction even when plugin.delete_port talks with external systems.
At now I believe it works because only release_dhcp_port() in db/dhcp_rpc_base which handle dhcp-agent RPC and dhcp-port will be cleaned up in delete_network even if some dhcp ports are not deleted successfully in release_dhcp_port.
Better fix is to support bulk operations in plugin. delete_ ports() .
It will provide a more consistent way to handle multiple resources at one operation.
Thought?