<div dir="ltr">Hello neutrinos,<div><br></div><div>last week we started a new bug deputy rotation, opening this round here are the bugs reported in week 11.</div><div><br></div><div>This was relatively quiet (for new bugs count), and most bugs have active discussion or suggested fix</div><div><br></div><div>Critical</div><div>* [security] Add allowed-address-pair <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> to one port will open all others' protocol under same security group - <a href="https://bugs.launchpad.net/neutron/+bug/1867119" target="_blank">https://bugs.launchpad.net/neutron/+bug/1867119</a></div><div>  A follow-up to security bug <a href="https://bugs.launchpad.net/neutron/+bug/1793029" target="_blank">https://bugs.launchpad.net/neutron/+bug/1793029</a> (which was fixed in documentation)</div><div>  Potential code fix at <a href="https://review.opendev.org/712632" target="_blank">https://review.opendev.org/712632</a> - reviews and opinions most welcome</div><div><br></div><div>Medium</div><div>* Restart neutron-linuxbridge-agent service led to all ports status changed - <a href="https://bugs.launchpad.net/neutron/+bug/1866743" target="_blank">https://bugs.launchpad.net/neutron/+bug/1866743</a></div><div>  Reported on Pike/Queens, pretty standard configuration, may be l2pop</div><div>  Related gerrit question: <a href="https://review.opendev.org/713156" target="_blank">https://review.opendev.org/713156</a></div><div>* MTU too large error presented on create but not update - <a href="https://bugs.launchpad.net/neutron/+bug/1867214" target="_blank">https://bugs.launchpad.net/neutron/+bug/1867214</a></div><div>  Suggested fix: <a href="https://review.opendev.org/712801" target="_blank">https://review.opendev.org/712801</a></div><div><br></div><div>Low</div><div>* Packets incorrectly marked as martian - <a href="https://bugs.launchpad.net/neutron/+bug/1866615" target="_blank">https://bugs.launchpad.net/neutron/+bug/1866615</a></div><div>  Martian packets logged with some specific setup, VMs are working fine though, switching to ovs firewall workarounds the issue</div><div>* Deployment has security group with empty tenant id - <a href="https://bugs.launchpad.net/neutron/+bug/1867101" target="_blank">https://bugs.launchpad.net/neutron/+bug/1867101</a></div><div>  Some master devstacks deployments like networking-odl get empty project ID for default security group</div><div>* Unnecessary network flapping while update floatingip without port or fixed ip changed - <a href="https://bugs.launchpad.net/neutron/+bug/1867122" target="_blank">https://bugs.launchpad.net/neutron/+bug/1867122</a></div><div>  OVN mech driver only, some discussion about relevant use-case for FIP update in LP and patch <a href="https://review.opendev.org/712641" target="_blank">https://review.opendev.org/712641</a></div><div><br></div><div>Incomplete</div><div>* router-update for internal networking not correct when restarting ovs-agent - <a href="https://bugs.launchpad.net/neutron/+bug/1866635" target="_blank">https://bugs.launchpad.net/neutron/+bug/1866635</a></div><div>  Missing flows on restart, I asked for more logs - may be missing tunnel during restart</div><div><br></div><div>Update from previous week</div><div>* br-int bridge in one compute can't learn MAC addresses of VMs in other compute nodes - <a href="https://bugs.launchpad.net/neutron/+bug/1866445" target="_blank">https://bugs.launchpad.net/neutron/+bug/1866445</a></div><div>  Was closed as duplicate of bug #1732067 but they do not use OVS firewall</div><div>  Patch for iptables_hybrid proposed: <a href="https://review.opendev.org/712640" target="_blank">https://review.opendev.org/712640</a></div><div><br></div><div>Last bug I triaged is 1867214, handing over the deputy baton to slaweq<br clear="all"><div><br></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr">Bernard Cafarelli<br></div></div></div></div>