yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #86815
[Bug 1938972] [NEW] Trunk and port are residual in VM deleting scenario when southbound plugin/agent failed
Public bug reported:
With following reproduce steps, trunk and port will be residual:
1. Operator create trunk , parent port and subport
2. Operator create VM with parent port
3. Port is bound succeed. Host and device information are updated.
4. Operator start to delete VM
5. Due to 3rd party plugin issue, port unbind failed. Host and device information are not updated. Trunk and port binding information are not updated. Port's status is normal and active.
Test result:
1. For nova, it will delete VM ignoring port update failed response code. So VM is deleted successfully.
2. For Neutron, operator's expected behavior is trunk and port will be deleted while the reality is operator fail to delete trunk as port is in bound status.
6315384D-49A8-E88F-E911-0FB32A841FBB:/home/fsp # openstack network trunk delete 8aae96b5-18f1-4b67-b0eb-9fdffb0c9a1b
Failed to delete trunk with name or ID '8aae96b5-18f1-4b67-b0eb-9fdffb0c9a1b': Trunk 8aae96b5-18f1-4b67-b0eb-9fdffb0c9a1b is currently in use.
Neutron server returns request_ids: ['req-3d0dbe95-250f-4791-835f-ef9617ee7871']
1 of 1 trunks failed to delete.
Alternative:
1. Port bound check is ignored when trunk is deleted just as port. When trunk delete is triggered, its trunk_port_validator.can_be_trunked_or_untrunked(context) is removed.
2. Adding a new API:DELETE /v2.0/trunks/{trunk_id}/force_delete_trunk . Since neutron does not support action in POST as nova, we do not have an existing structure to add a parameter to support force delete as nova.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1938972
Title:
Trunk and port are residual in VM deleting scenario when southbound
plugin/agent failed
Status in neutron:
New
Bug description:
With following reproduce steps, trunk and port will be residual:
1. Operator create trunk , parent port and subport
2. Operator create VM with parent port
3. Port is bound succeed. Host and device information are updated.
4. Operator start to delete VM
5. Due to 3rd party plugin issue, port unbind failed. Host and device information are not updated. Trunk and port binding information are not updated. Port's status is normal and active.
Test result:
1. For nova, it will delete VM ignoring port update failed response code. So VM is deleted successfully.
2. For Neutron, operator's expected behavior is trunk and port will be deleted while the reality is operator fail to delete trunk as port is in bound status.
6315384D-49A8-E88F-E911-0FB32A841FBB:/home/fsp # openstack network trunk delete 8aae96b5-18f1-4b67-b0eb-9fdffb0c9a1b
Failed to delete trunk with name or ID '8aae96b5-18f1-4b67-b0eb-9fdffb0c9a1b': Trunk 8aae96b5-18f1-4b67-b0eb-9fdffb0c9a1b is currently in use.
Neutron server returns request_ids: ['req-3d0dbe95-250f-4791-835f-ef9617ee7871']
1 of 1 trunks failed to delete.
Alternative:
1. Port bound check is ignored when trunk is deleted just as port. When trunk delete is triggered, its trunk_port_validator.can_be_trunked_or_untrunked(context) is removed.
2. Adding a new API:DELETE /v2.0/trunks/{trunk_id}/force_delete_trunk . Since neutron does not support action in POST as nova, we do not have an existing structure to add a parameter to support force delete as nova.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1938972/+subscriptions