Hi,
On 13 Aug 2019, at 16:44, Sean Mooney smooney@redhat.com wrote:
On Tue, 2019-08-13 at 22:30 +0900, Akihiro Motoki wrote:
Hi neutrinos,
I was a bug deputy for last week (Aug 5 to Aug 11). We got a few new bug last week.
Two bugs are in the undecided state.
https://bugs.launchpad.net/neutron/+bug/1834045 Live-migration double binding doesn't work with OVN New, Undecided, No assignee (in neutron) NOTE: 'neutron' was added to the affected projects last week. This is related to the double binding feature on non-agent based drivers like networking-ovn. networking-ovn already has a workaround for this. Is any further work needed in neutron side? More input would be appreciated.
Form a nova and neutron perspective my understanding is that all drivers are required to implement this feature. The nova implementation certenly requires that all neutron backends support it if neutron reports support for the portbinding-extended extension. Given that neutron does not support disabling this extension that in trun implies that this has been a required extension for all ml2 drivers to support. It is my understanding at least that this was not intended to be optional.
As an interim workaround nova supports disabling treating the lack of a vif plugged event as fatal for live migrations. https://docs.openstack.org/nova/latest/configuration/config.html#compute.liv... however we do want to eventually remove that and it should also be noted that we intent to use the multiple port binding in other code paths which means some nova feature will not be available with ovn until support is added.
i have not updated the bug but i personal tend to be live it should be marked as invalid against nova. the issue to me seams to be that neutron is reporting support for an extension that not supported by networking-ovn. and networking-ovn is not implementing a mandatory extention that cannot be disabled.
IIUC bug report correctly, problem is that during live-migration nova is doing inactive binding on destination host and waits for "network-vif-plugged” even about port on destination host before it will start migration. And that is IMO wrong as this even should be IMO send after migration as then vif is really plugged and configured on dest host. It works currently for ML2/OVS case because during creation of inactive binding neutron is doing port update which triggers neutron-ovs-agent on source host and this triggers sending this notification. IMO there should be different notification for this case or nova should maybe check in some other way if inactive binding is done on destination host or not. But I wasn’t the one who was debugging it so my understanding might be wrong here. Adding Maciek in CC as he was debugging this issue on networking-ovn side and he reported this bug originally.
i you look at the nova spec https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neu... it states
"Note: The new neutron API extension will be implemented in the ml2 plugin layer, above the ml2 driver layer so if the extension is exposed it will be supported for all ml2 drivers. Monolithic plugins will have tThere is no additional configuration for deployers. The use of multiple bindings will be enabled automatically. We decide whether to use the new or old API flow, if both compute nodes support this feature and based on the available Neutron API extensions. We cache extensions support in the usual way utilizing the existing neutron_extensions_cache.
Note: The new neutron API extension will be implemented in the ml2 plugin layer, above the ml2 driver layer so if the extension is exposed it will be supported for all ml2 drivers. Monolithic plugins will have to implement the extension separately and will continue to use the old workflow until their maintainers support the new neutron extension."
This statement about implementing the exteion in the ml2 plugin layer came organically form conversations with miguel lavalle when he took over the implemantion of https://review.opendev.org/#/c/414251/ and we discuss this and the existence of the extention being report being the contract by which nova detect support of this feature at before codifying it at the nova spec.
this contract was estrablish specificaly to ensure that we could ensure out of tree drivers would still work by falling back to the old flow with the expectation that they would all be updated eventurally.
https://bugs.launchpad.net/neutron/+bug/1839658 "subnet" register in the DB can have network_id=NULL New, Undecided, Assigned to ralonsoh NOTE: I could not reproduce it yet. It looks like a corner case and more code investigation might be needed.
The following new bugs have been fixed.
Thanks, Akihiro
— Slawek Kaplonski Senior software engineer Red Hat