- 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.
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.