[neutron] bug deputy report (the week of Aug 5)

Sean Mooney smooney at redhat.com
Tue Aug 13 14:44:07 UTC 2019


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

i you look at the nova spec 
https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neutron-new-port-binding-api.html#proposed-change
 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.
> - https://bugs.launchpad.net/bugs/1839595
> 
> Thanks,
> Akihiro
> 




More information about the openstack-discuss mailing list