Bug 1197470

Summary: sriov ports not deleted with the instance
Product: Red Hat OpenStack Reporter: Alon Dotan <alon1.dotan>
Component: openstack-neutronAssignee: lpeer <lpeer>
Status: CLOSED NOTABUG QA Contact: Ofer Blaut <oblaut>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: beagles, chrisw, itbrown, nyechiel, yeylon
Target Milestone: ---   
Target Release: 7.0 (Kilo)   
Hardware: x86_64   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-26 08:35:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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