[RFE] preventing from deleting a port used by an instance (locked instance can be rendered broken by deleting port)

[George Shuklin]

'server lock' is indented to protect instance from simple mistakes (like removing the wrong instance, or shut-downing it). It does prevent shutdown, destruction and port detachment.

But if port is removed via `openstack port delete` it silently get removed from locked instance, effectively, breaking it.

Steps to reproduce:
```
openstack server create foo
openstack server lock foo
openstack port delete {id of the port of the instance}
```

Expected behavior: error message, rejecting to delete port, used by locked instance.

Actual behavior: port is removed, leaving locked instance without network.

I was able to reproduce it on nova 17.0.12, but newer versions may be affected too.

[Artom Lifshitz (notartom)]

It's a valid bug, but as ports are Neutron's responsibility, I'm not sure what can be done in this case. Neutron is free to delete a port without checking anything about the instance it's attached to. Perhaps this can be changed to the Neutron component, to see if folks there have an idea?

[Oleg Bondarev (obondarev)]

Perhaps nova could set some flag in port's binding_profile (or some other field) which neutron would check on each port delete?

[Akihiro Motoki (amotoki)]

The current neutron rejects deletion of a port used as a router interface. We can do a similar check for a port with device_owner in general, but it will changes the current behavior of port-delete a lot. It looks good to discuss it as RFE.

[Slawek Kaplonski (slaweq)]

Let's discuss it on the next drivers meeting 02.07.2021

[Slawek Kaplonski (slaweq)]

Personally I like Oleg's idea - we could add some flag which Nova could set when instance is locked and then we would forbid deleting port. Or we could change device_owner to something like compute:nova_locked - or something like that.

[Akihiro Motoki (amotoki)]

I agree that locked instances should not be affected. What I am not sure is we need to distinguish locked and non-locked instances from neutron perspective. Do we want to block ports used by locked instances only or block ports used all instances?

[Slawek Kaplonski (slaweq)]

We discussed that RFE on today's drivers meeting: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-02-14.00.log.html

We see 2 possible solution for that issue:

- add new neutron api extension "port lock". In such case nova will be able to lock port during server lock process. It won't be possible to update/delete such locked port in neutron. That solution will require new API extension on Neutron's side. Question for Nova is - how to mark ports of already locked instances during e.g. upgrade. Plus of that solution is that it will not require any temporary config options to make e.g. older nova compatible with new neutron or vice-versa.

- add new neutron extension and forbid deletion of ports which are "in use". We are already forbidding that for e.g. router ports. Plus of that is that it would be more consistent with e.g. how Cinder works with volumes. But it will require changes in Nova so Nova during deletion of instance will first need to update (unbind) port and then delete it. This will require some temporary config option on Neutron side to make possible to disable this new behavior during e.g. upgrade process. Other potential issue is that we don't know how it will work for other projects (e.g. Octavia) and if we will not break them.
Plus of that solution is that it would work not only for locked instances so users wouldn't be able to break connectivity to their vms by accident by deleting bound port.

We decided to approve that rfe and now Miguel Lavalle will propose spec with detailed description of both those potential solutions. We will continue discussion to choose the best one in the review of the spec.