Small update on the issue. I managed to reproduce it in my virtual lab using subsequent calls to boot and delete. It turned out that deletion of interface itself is happening when nova receives the 'network-vif-deleted' event from neutron, but if the instance doesn't exist by that moment, nova fails to delete the interface. The neutron-openvswitch-agent plugin does not create or delete interfaces of the instance itself, but it manages interface's properties like VLANs. If the instance does not exist (what happens after deletion) it cannot bind the created interface to any meaningful VLAN and set it to DEAD_VLAN (4095). This is expected behavior. What we see if we delete an instance right after the request of its creation IMO is predictable. Neutron cannot get in time sending the network-vif-deleted event after a port destruction, and nova drops that event. Not sure if this is fixable at all, therefore I've asked Vladylav Drok to kindly take a look on this issue.
Small update on the issue. I managed to reproduce it in my virtual lab using subsequent calls to boot and delete. It turned out that deletion of interface itself is happening when nova receives the 'network- vif-deleted' event from neutron, but if the instance doesn't exist by that moment, nova fails to delete the interface. The neutron- openvswitch- agent plugin does not create or delete interfaces of the instance itself, but it manages interface's properties like VLANs. If the instance does not exist (what happens after deletion) it cannot bind the created interface to any meaningful VLAN and set it to DEAD_VLAN (4095). This is expected behavior. What we see if we delete an instance right after the request of its creation IMO is predictable. Neutron cannot get in time sending the network-vif-deleted event after a port destruction, and nova drops that event. Not sure if this is fixable at all, therefore I've asked Vladylav Drok to kindly take a look on this issue.