[nova][neutron][ptg] Summary: Leaking resources when ports are deleted out-of-band

Balázs Gibizer balazs.gibizer at ericsson.com
Thu May 9 09:19:02 UTC 2019

On Wed, May 8, 2019 at 6:18 PM, Matt Riedemann <mriedemos at gmail.com> 
> On 5/4/2019 11:57 AM, Balázs Gibizer wrote:
>> The failure to detach a port via nova while the nova-compute is down
>> could be a bug on nova side.
> Depends on what you mean by detach. If the compute is down while 
> deleting the server, the API will still call the (internal to nova) 
> network API code [1] to either (a) unbind ports that nova didn't 
> create or (2) delete ports that nova did create.

This sentence based on the reported bug [2]. The reason while Octavia 
is unbinding the port in Neutron instead of via Nova is that Nova fails 
to detach the interface and unbind the port if the nova-compute is 
down. In that bug we discussing if it would be meaningful to do a local 
interface detach (unvind port in neutron + deallocate port resource in 
placement) in the nova-api if the compute is done similar to the local 
server delete.

[2] https://bugs.launchpad.net/nova/+bug/1827746

> For the policy change where the port has to be unbound to delete it, 
> we'd already have support for that, it's just an extra step.
> At the PTG I was groaning a bit about needing to add another step to 
> delete a port from the nova side, but thinking about it more we have 
> to do the exact same thing with cinder volumes (we have to detach 
> them before deleting them), so I guess it's not the worst thing ever.

As soon as somebody from Neutron states that the neutron policy patch 
is on the way I can start working on the Nova side of this.


> [1] 
> https://protect2.fireeye.com/url?k=56f34fb5-0a7a9599-56f30f2e-0cc47ad93da2-193a4612d9e0575f&u=https://github.com/openstack/nova/blob/56fef7c0e74d7512f062c4046def10401df16565/nova/compute/api.py#L2291
> --
> Thanks,
> Matt

More information about the openstack-discuss mailing list