<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 March 2015 at 13:16, Sławek Kapłoński <span dir="ltr"><<a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Today I found bug <a href="https://bugs.launchpad.net/neutron/+bug/1314614" target="_blank">https://bugs.launchpad.net/neutron/+bug/1314614</a> because I<br>
have such problem on my infra.<br></blockquote><div><br></div><div>(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.)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I saw that bug is "In progress" but change is abandoned quite long time ago. I<br>
was wondering is it possible that neutron will send notification to nova that<br>
such port was deleted in neutron? I know that in Juno neutron is sending<br>
notifications to nova when port is UP on compute node so maybe same mechanism<br>
can be used to notify nova that port is no longer exists and nova should<br>
delete it?<br></blockquote><div><br></div><div>What behaviour are you looking for?  <br><br>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.<br><br></div><div>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.<br></div><div><br>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.<br><br>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).<br></div><div>-- <br></div><div>Ian.<br></div></div></div></div>