Bug 1300693

I suspect that this has nothing to do with DPDK but I want to make sure. Can you check this?

For example:
0) Install regular, non-DPDK openstack
1) Shut down OVS agent
2) Wait until it shows as dead on neutron agent-list (Will take 75 seconds)
3) Spawn a VM, it should enter error state
4) Observe it has a Neutron port
5) Delete the VM
6) Check if the Neutron port was deleted or not

It's possible that the behavior will be different if when you create the VM you:
1) First create a port and pass the port_id to the nova boot command
2) Or just specify a network_id when you boot the VM

Assaf , 
I did what you ask me to run , In this scenario neutron port does not created when VM failed to boot (Error status). 

I also tried to spawn a VM and make it to enter to error status ,
when OVS-agent is enabled and than delete it.I found that the port is still exist.
This means that the issue is not related to DPDK

(In reply to Eran Kuris from comment #3)
> Assaf , 
> I did what you ask me to run , In this scenario neutron port does not
> created when VM failed to boot (Error status). 
> 
> I also tried to spawn a VM and make it to enter to error status ,
> when OVS-agent is enabled and than delete it.I found that the port is still
> exist.
> This means that the issue is not related to DPDK

There's two ways for Nova to interact with Neutron.

1) neutron port-create, pass that port ID to nova boot command
2) nova boot and specify a network-id, and then Nova creates the port for you

Can you say if this bug happens with both scenarios 1 and 2?

Switching to Nova component.

yes happens in 2 scenarios

(In reply to Assaf Muller from comment #4)
> (In reply to Eran Kuris from comment #3)
> > Assaf , 
> > I did what you ask me to run , In this scenario neutron port does not
> > created when VM failed to boot (Error status). 
> > 
> > I also tried to spawn a VM and make it to enter to error status ,
> > when OVS-agent is enabled and than delete it.I found that the port is still
> > exist.
> > This means that the issue is not related to DPDK
> 
> There's two ways for Nova to interact with Neutron.
> 
> 1) neutron port-create, pass that port ID to nova boot command
> 2) nova boot and specify a network-id, and then Nova creates the port for you
> 
> Can you say if this bug happens with both scenarios 1 and 2?

So in case this happens in scenario 1 above - that's the intended behavior. Nova will not delete ports that it did not itself create.

https://review.openstack.org/#/c/126309/

In scenario 2) (as can be seen from the above change), Nova should clean up the ports it did create unless there was some problem with delete.

This bug does not have enough information for me to make a guess as to what happened.

A plausible theory would be that in case of reschedules that are caused by failures to allocate networks, since neutron is broken, the instance goes to ERROR state after retries, meaning that the instance is not registered on any host (can be confirmed by running nova show).

In that case - when deleting the instance, Nova will only do a DB delete and never call out to the compute host or Neutron.

Normally I would ask the reporter for more details on this, but this seems like a minor nuance that has an easy workaround - manually delete ports (please correct me if my assumptions are wrong here). It is also likely the problem on upstream master as well, so considering the overall impact - I would recommend that the reporter tries to reproduce this with upstream master and reports the bug upstream (https://bugs.launchpad.net/nova).

Note: the google doc guide mentioned in the description has been published here:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_configuration_guide/