Bug 1197470 - sriov ports not deleted with the instance
Summary: sriov ports not deleted with the instance
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 7.0 (Kilo)
Hardware: x86_64
OS: All
unspecified
unspecified
Target Milestone: ---
: 7.0 (Kilo)
Assignee: lpeer
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-01 14:11 UTC by Alon Dotan
Modified: 2016-04-27 04:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-26 08:35:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Alon Dotan 2015-03-01 14:11:18 UTC
Description of problem:
if creation of instance failed and instance go error state, than when trying
to delete the instance the sr-iov port will not be deleted

Version-Release number of selected component (if applicable):


How reproducible:
the flow is like that:
* create SR-IOv port via neutron port-create 
* attach the port to instance, if the instance managed to boot OK the port will be assignd and when the instance will be deleted the port also will be deleted, BUT if the instance going to ERROR state than the port will not be deleted when the instance wil be deleted


Steps to Reproduce:
1.
2.
3.

Actual results:
the sriov port not deleted

Expected results:
if sriov port are attached to instance he should be deleted with the instance

Additional info:

Comment 3 Itzik Brown 2015-03-11 15:53:04 UTC
Does it happen with non SR-IOV port?
I think this is not related to SR-IOV.
If you create a normal port, launch an instance with this port attached and the instance moves to error state - deleting the instance doesn't remove the port.

Comment 4 Brent Eagles 2015-04-22 18:20:19 UTC
Itzik is correct. This is by design and effectively not a bug - the port should simply be updated to remove the host and instance info. I recommend closing as NOTABUG

Comment 5 Nir Yechiel 2015-04-26 08:35:00 UTC
Closing per comment #4. This is the expected behavior when using this flow.

Nir


Note You need to log in before you can comment on or make changes to this bug.