13:59:32 <liuyulong> #startmeeting neutron_l3
13:59:33 <openstack> Meeting started Wed Dec 11 13:59:32 2019 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:37 <openstack> The meeting name has been set to 'neutron_l3'
13:59:40 <liuyulong> #chair liuyulong_
13:59:41 <openstack> Current chairs: liuyulong liuyulong_
14:00:21 <ralonsoh> hi
14:00:48 <slaweq> hi
14:01:20 <liuyulong> hi
14:01:25 <liuyulong> #chair slaweq
14:01:26 <openstack> Current chairs: liuyulong liuyulong_ slaweq
14:01:50 <liuyulong> OK, let's start
14:01:55 <liuyulong> #topic Announcements
14:04:03 <liuyulong> bad connection....
14:04:05 <liuyulong> #link https://releases.openstack.org/ussuri/schedule.html
14:04:29 <liuyulong> We have this release schedule。
14:04:54 <liuyulong> Ussuri-1 is on Dec 09 - Dec 13
14:07:14 <liuyulong> #link https://launchpad.net/neutron/+milestone/ussuri-1
14:07:37 <liuyulong> Only one bug was marked for U-1.
14:08:41 <slaweq> liuyulong: this bug is actually RFE
14:08:50 <liuyulong> slaweq, I think that ovs-agent egress-packet-flood issue should be target on U-1, lots of users have encountered that issue, what do you think?
14:09:14 <slaweq> U-1 is this week so I don't think we can fix it as fast
14:09:20 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1732067
14:09:20 <openstack> Launchpad bug 1732067 in OpenStack Security Advisory "openvswitch firewall flows cause flooding on integration bridge" [Undecided,Incomplete]
14:09:27 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1841622
14:09:27 <openstack> Launchpad bug 1732067 in OpenStack Security Advisory "duplicate for #1841622 openvswitch firewall flows cause flooding on integration bridge" [Undecided,Incomplete]
14:09:50 <liuyulong> And I've updated the fix: https://review.opendev.org/#/c/666991/
14:10:38 <liuyulong> My fault, haha
14:11:27 <slaweq> liuyulong: Your fix is this fix which don't work for some dvr cases, do I remember that correctly from Shanghai?
14:12:30 <liuyulong> HA router mixed with compute service
14:13:20 <liuyulong> Since we have normal flows, and the qg-device can be hosted in HA-router scheduled nodes.
14:14:28 <slaweq> ok, I will review that patch asap
14:15:49 <liuyulong> So should I change the Milestone of the bug?
14:17:36 <slaweq> I will set it
14:18:08 <liuyulong> Great
14:18:41 <slaweq> done
14:19:34 <liuyulong> So IMO, if there are some more technical issues, we may mark them all. So the end users, may find something more easily when they want to find some thing useful or backporting something.
14:21:17 <liuyulong> I will try to make that fix 666991 light to make it easy to backport.
14:21:27 <liuyulong> OK, let's move on
14:21:34 <liuyulong> #topic Bugs
14:21:54 <liuyulong> No bug deputy mail this week.
14:22:11 <liuyulong> So let's scan the list.
14:22:48 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1855919
14:22:48 <openstack> Launchpad bug 1855919 in neutron "broken pipe errors cause neutron metadata agent to fail" [Undecided,New]
14:23:41 <ralonsoh> I don't think (without having any other log), that this is a problem with the DB
14:23:47 <ralonsoh> but with the MQ
14:24:08 <ralonsoh> could be useful to debug the MQ status and to have the server logs
14:24:35 <liuyulong> From my experiences, if the RPC client did not send the heart beat to the rabbit-server, rabbit-server will close the connection.
14:24:59 <liuyulong> But the client still consider that the connection is alive.
14:25:11 <ralonsoh> so do you think this is related to https://bugs.launchpad.net/neutron/+bug/1853071?
14:25:11 <openstack> Launchpad bug 1853071 in neutron "AMQP disconnects, q-reports-plugin queue grows, leading to DBDeadlocks while trying to update agent heartbeats" [High,In progress] - Assigned to Arjun Baindur (abaindur)
14:25:13 <ralonsoh> as suggested
14:25:22 <liuyulong> So the broken-pipe errors come.
14:25:24 <slaweq> but those errors "Timeout in RPC method get_ports" could be also caused by some issue on neutron-server side
14:25:31 <slaweq> maybe it's overloaded simple
14:25:35 <ralonsoh> sure
14:25:48 <slaweq> we should ask for neutron-server logs from the same time too
14:25:48 <ralonsoh> that's why it should be useful to have both MQ and server logs
14:25:56 <slaweq> ralonsoh++
14:27:35 <liuyulong> Some time, the long loop (without sleep 0) in the agent will cause the coroutines not switching. Then the heart beat greenlet will do nothing.
14:28:17 <liuyulong> One sec
14:28:51 <slaweq> I added comment there and I set this bug as incomplete for now
14:28:59 <slaweq> lets wait for additional data from reporter
14:32:52 <liuyulong> Sure
14:34:11 <liuyulong> There are some config options from oslo_messaging, like heartbeat_interval, can be tuned for some heavy load use case.
14:35:14 <liuyulong> seems no more bugs related to this meeting.
14:36:01 <liuyulong> Any other bugs?
14:36:50 <liuyulong> OK, let's move on.
14:38:03 <liuyulong> #topic OVN_L3
14:40:23 <liuyulong> One concern from me, last week we abandoned the floating IP QoS support patch for networking-ovn.
14:40:29 <liuyulong> #link https://review.opendev.org/#/c/539826/
14:41:11 <liuyulong> Is there any plan for this feature?
14:41:26 <slaweq> I abandoned it automaticaly with script
14:41:41 <ralonsoh> once we have it in Neutron repo, we can propose it again, but in Neutron
14:41:44 <slaweq> if You or anyone else wants to continue work on this, we can always restore it
14:42:04 <liuyulong> Yes, it should be done in neutron.
14:42:21 <liuyulong> #link https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge
14:42:28 <liuyulong> What's the status of this now?
14:42:43 <ralonsoh> we are still dealing with CI problems
14:42:50 <ralonsoh> but is just a matter of rechecking
14:42:51 <liuyulong> There is a table I remember.
14:43:09 <ralonsoh> most of the code is almost proposed in gerrit
14:43:25 <ralonsoh> and FTs are being testing right now
14:43:41 <ralonsoh> along with the scripts needed for this
14:43:58 <ralonsoh> that's all from me
14:44:23 <liuyulong> #link https://review.opendev.org/#/q/topic:bp/neutron-ovn-merge+(status:open+OR+status:merged)
14:45:04 <liuyulong> They are all here now. Only 5 open patches.
14:45:33 <ralonsoh> the most important ones
14:45:43 <ralonsoh> the ovsdb code, the mech driver and FTs
14:45:51 <ralonsoh> (and trunk driver)
14:46:24 <liuyulong> ralonsoh, thank you for the information. : )
14:46:50 <ralonsoh> yw
14:47:15 <liuyulong> Almost the entire core team is now on this BP. LOL
14:47:50 <liuyulong> OK, any updates for OVN l3?
14:48:05 <ralonsoh> not from my side
14:48:17 <liuyulong> #topic On demand agenda
14:49:35 <liuyulong_> I have some interesting topics.
14:50:25 <liuyulong_> Anyone who tried to run DVR with bare metal services?
14:50:48 <ralonsoh> no
14:51:20 <liuyulong_> I mean your network is VLAN type, and you have physical hosts provisioned from ironic which also in such VLAN.
14:52:43 <liuyulong_> So if you have many VM from many compute nodes, then your bare metal instances may have tons of gateways with same IP and MAC in these computes nodes.
14:54:48 <liuyulong_> Another topic is to run DVR with L2 gateway services to connect the VXLAN network to the  bare metal switches?
14:58:27 <liuyulong_> OK, I think this can be very interesting no matter neutron-agents or OVN try to make it come true.
14:59:42 <liuyulong_> Time is up.
14:59:49 <liuyulong_> #endmeeting