[openstack-dev] [neutron] Bug deputy report

270162781 270162781 at qq.com
Mon Mar 19 07:27:33 UTC 2018

Hi all,

I'm zhaobo, I was the bug deputy for the last week and I'm afraid that cannot attending the comming upstream meeting so I'm sending out this report:

Last week there are some high priority bugs for neutron . Also some bugs need to attention, I list them here:

High priority

[CI failure] https://bugs.launchpad.net/neutron/+bug/1756301
Tempset DVR HA miltimode tests fails as no FIP connectivity. I suspect that it may be a devstack bug.

In DVR HA scenarios, it will hit the AttributeError if depoly a LB on the network node, and Neutron depolys a DvrEdgeRouter on the network node for LB, when server call "router_update" to agent, agent side want to check whether the router is an ha router. Then hit the error as DvrEdgeRouter doesn't have a attribute named "ha_state". I found Brain and Swaminathan already work around with the bug reporter.

Medium priority
Dvr mac address format may be invalid for non native openflow interface, Swamination has already work on it.

Need attention
As the bug description, the vxlan port on br-tun may miss in L3 DVR+HA large scale env, the probability of failure seems high. I have no idea about this, so need help from L3 team experts, then setting the priority.

plugins.ml2.plugin.Ml2Plugin#_bind_port_if_needed There is a concurrency issue here, it will lead to a missing RPC notification which in turn result in a port stuck in DOWN status following a live-migration. I think we can check the details in the Bug descrption, it is enough to explain what the problem is.

In l2pop scenarios, linux bridge agent want to rpc to server with "update_port_down", server will call list_router_ids_on_host with l3plugin, then it raise the error, agent will get the remote rpc error.So the process may looks like NeutronServer try to find l3 agent on compute node and failed. This bug is reported for a long time, as the reporter said he still hit the same issue on Queen/master, so I think it is worth to raise here. 

This sounds like a enhancement for routing function. So need to raise it and discuss with our L3 experts about whether we need the "metric".

Trunk bridge residue if restart the nove-compute before remove the vm in ovs-dpdk. As armando said, it may be related DPDK process. Armando mark it as Incomplete now for need more description about the issue condition.

Best Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180319/6c98029b/attachment.html>

More information about the OpenStack-dev mailing list