Open Stack

On 6 March 2015 at 13:16, Sławek Kapłoński <slawek at kaplonski.pl> wrote:

> Hello,
>
> Today I found bug https://bugs.launchpad.net/neutron/+bug/1314614 because
> I
> have such problem on my infra.
>

(For reference, if you delete a port that a Nova is using - it just goes
ahead and deletes the port from Neutron and leaves the VIF in an odd state,
disconnected and referring to a port that no longer exists.)

I saw that bug is "In progress" but change is abandoned quite long time
> ago. I
> was wondering is it possible that neutron will send notification to nova
> that
> such port was deleted in neutron? I know that in Juno neutron is sending
> notifications to nova when port is UP on compute node so maybe same
> mechanism
> can be used to notify nova that port is no longer exists and nova should
> delete it?
>

What behaviour are you looking for?

The patch associated with the bug falls attempts to stop deletion of used
ports.  It falls far short of implementing consistent behaviour, which
would have to take into account everything that used ports (including DHCP,
L3, network services, etc.), it would probably need to add an 'in-use' flag
to the port itself, and it changes the current API behaviour rather
markedly.  We could go there but there's much more code to be written.

Someone on the bug suggests removing the VIF from the instance if the port
is deleted, but I don't think that's terribly practical - for some instance
containers it would not be possible.

The current behaviour does seem to be consistent and logical, if perhaps
unexpected and a bit rough around the edges.  I'm not sure orphaning and
isolating a VIF is actually a bad thing if you know it's going to happen,
though it needs to be clear from the non-Neutron side that the VIF is no
longer bound to a port, which is where things seem to fall down right now.

I've also found no documentation about when delete should work and when it
shouldn't, or what happens if the port is bound (the API and CLI document
say that the operation 'deletes a port' and not much else).
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150308/b1343d01/attachment.html>