14:01:10 <liuyulong> #startmeeting neutron_l3
14:01:11 <openstack> Meeting started Wed Feb 19 14:01:10 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:15 <openstack> The meeting name has been set to 'neutron_l3'
14:01:18 <liuyulong> hi there
14:01:45 <liuyulong> #topic Announcements
14:01:53 <liuyulong> #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-02-17-21.00.log.html
14:02:19 <liuyulong> Since we have networking team meeting, I may have no announcement here.
14:02:57 <ralonsoh> hi
14:03:38 <liuyulong> Just some reminding: https://etherpad.openstack.org/p/neutron-victoria-ptg
14:03:42 <liuyulong> ralonsoh, hi
14:04:53 <liuyulong> OK, let's move to next topic.
14:04:59 <liuyulong> #topic Bugs
14:05:34 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012610.html
14:05:57 <liuyulong> Akihiro Motoki was our bug deputy last week.
14:06:55 <liuyulong> First one:
14:06:56 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1863110
14:06:57 <openstack> Launchpad bug 1863110 in neutron "2/3 snat namespace transitions to master" [Undecided,New]
14:08:11 <liuyulong> slaweq and haleyb|away had replied on the bug, maybe a bug from low version keepalived.
14:08:32 <slaweq> hi, sorry for being late
14:08:50 <slaweq> I have another meeting in the same time, so I will be only lurking here today, sorry
14:09:39 <liuyulong> slaweq, sure, no worries
14:10:30 <liuyulong> And the Marek Grudzinski had left the version of the keepalived, it is 1.3.9.
14:11:25 <liuyulong> The version is higher than my test ENV.
14:12:14 <liuyulong> So I guess maybe the VRRP heartbeats were dropped between the hosts for their LVS clusters.
14:12:30 <liuyulong> I will leave this comment to the bug.
14:14:25 <liuyulong> More about that could be: 1. security group rules
14:14:32 <liuyulong> 2. port security
14:14:39 <liuyulong> 3. allowed address pair
14:15:55 <liuyulong> OK, let's filter the next one...
14:17:31 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1863213
14:17:32 <openstack> Launchpad bug 1863213 in neutron "Spawning of DHCP processes fail: invalid netcat options" [Undecided,New] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:17:40 <liuyulong> I met this issue also.
14:17:50 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1863830
14:17:51 <openstack> Launchpad bug 1863213 in neutron "duplicate for #1863830 Spawning of DHCP processes fail: invalid netcat options" [Undecided,New] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:18:06 <ralonsoh> I reverted the patch merged
14:18:10 <liuyulong> So I will try that revert locally.
14:18:55 <ralonsoh> And I've submitted a patch to mark those tests as unstable
14:19:03 <liuyulong> ralonsoh, yes, I just marked it as duplicated.
14:19:20 <ralonsoh> I still need to know why, sometimes, the netcat rootwrap filters don't work
14:19:29 <ralonsoh> most of the time do
14:20:15 <liuyulong> I run dsvm-functional case locally, it fails 100% times.
14:20:41 <liuyulong> http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%20%5C%22Exit%20code:%202%3B%20Stdin:%20%3B%20Stdout:%20%3B%20Stderr:%20Ncat:%20Invalid%20-w%20timeout%20(must%20be%20greater%20than%200).%20QUITTING.%5C%22
14:20:56 <liuyulong> We have lots of these logs.
14:21:44 <ralonsoh> that was solved in https://review.opendev.org/#/c/707786/
14:22:44 <liuyulong> ralonsoh, yes, I know that revert patch. : )
14:22:52 <liuyulong> I'm going to try that locally
14:24:56 <liuyulong> Next one:
14:24:58 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1863091
14:24:58 <openstack> Launchpad bug 1863091 in neutron "IPVS setup fails with openvswitch firewall driver, works with iptables_hybrid" [Undecided,New]
14:25:30 <liuyulong> Alright, it is not so related to L3...
14:26:50 <liuyulong> But I have to say for the LVS(ipvs) loadbalancer, it the mode was DR (direct routing), the LVS server and real server may have some config in different.
14:27:53 <liuyulong> The LVS server (frontend) should disable the security group and port_security.
14:28:30 <liuyulong> The real server (backend) should add allowed address pair with VIP, and set this VIP to the lo device.
14:28:55 <liuyulong> OK, I will leave this to the bug.
14:30:16 <liuyulong> OK, next one:
14:30:43 <liuyulong> #link https://launchpad.net/bugs/1859832
14:30:45 <openstack> Launchpad bug 1859832 in neutron "L3 HA connectivity to GW port can be broken after reboot of backup node" [Medium,In progress] - Assigned to LIU Yulong (dragon889)
14:31:02 <liuyulong> I just want to add the fix from me here:
14:31:03 <liuyulong> #link https://review.opendev.org/#/c/707406/
14:31:33 <liuyulong> A totally L3 side change for this bug.
14:33:10 <liuyulong> Just update and rebase the code.
14:33:20 <liuyulong> OK, no more bugs from me then.
14:33:23 <liuyulong> Any updates?
14:33:49 <ralonsoh> no
14:35:35 <liuyulong> OK, let's move on.
14:35:41 <liuyulong> #topic OVN_L3
14:36:24 <ralonsoh> maciejjozefczyk, lucasagomes ping
14:36:34 <ralonsoh> any update this week in OVN L3?
14:37:23 <lucasagomes> hi there, I don't think I have any updates
14:37:35 <lucasagomes> same as last week, we still having some problems while merging the functional tests patch
14:37:58 <ralonsoh> just one topic: we are reviewing the extensions (including L3 ones) just to know which are really supported
14:38:06 <ralonsoh> that's all from me
14:38:17 <lucasagomes> oh yeah, that as well
14:40:35 <liuyulong> I have on question: the migrated networking-ovn code in neutron repo can run full L2/L3 functionalities?
14:40:45 <liuyulong> s/on/one
14:41:45 <ralonsoh> dhcp, FIP, DVR, qos (partially)...
14:44:05 <liuyulong> All have been aligned to networking-ovn?
14:44:25 <ralonsoh> that is the goal
14:44:42 <liuyulong> I mean no gaps between neutron-ovn (a temporary name) and networking-ovn?
14:44:51 <liuyulong> OK
14:45:05 <liuyulong> Thank you for the information. : )
14:45:12 <ralonsoh> yw
14:46:28 <liuyulong> So we have a name for the OVN extensions/drivers/mechanism/plugins in Neutron? I just gave us one: neutron-ovn. : )
14:47:34 <ralonsoh> in L3 ovn-router
14:48:50 <liuyulong> https://review.opendev.org/#/q/topic:bp/neutron-ovn-merge+(status:open+OR+status:merged) so I will put eyes on this bp.
14:48:55 <liuyulong> #link https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge
14:49:22 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1855912
14:49:23 <openstack> Launchpad bug 1855912 in neutron "MariaDB 10.1 fails during alembic migration" [High,Confirmed]
14:49:29 <liuyulong> I have a question on this.
14:51:18 <liuyulong> This could cause an upgrading issue if user try to update the neutron DB schema with 10.1 mariadb.
14:51:31 <ralonsoh> yes
14:51:40 <ralonsoh> no, not an upgrade
14:51:52 <ralonsoh> but neutron server will fail during runtime
14:52:31 <ralonsoh> sorry sorry, yes, during upgrade
14:52:38 <ralonsoh> alembic migration
14:53:04 <liuyulong> For a cloud deployment, we should warn users that they should check their DB version before upgrading neutron.
14:53:29 <ralonsoh> we could add a sanity check
14:53:52 <liuyulong> ralonsoh, yes, this could cause the upgrading failure.
14:54:02 <liuyulong> ralonsoh, that's a good approach.
14:55:04 <liuyulong> But anyway, if user need to upgrade the basic components, all there neutron server and agent may have a potential long down time.
14:56:46 <liuyulong> So I have another idea, something like the "--subproject" for neutron-db-manage.
14:57:14 <liuyulong> If users' deployment is not OVN and will not upgrade to use OVN, so these tables will not be used.
14:57:58 <liuyulong> Maybe we could add a independent upgrade branch for OVN DB schemas only.
14:57:58 <ralonsoh> liuyulong, not, but there are plenty of other tables that, by default, are not used
14:58:10 <ralonsoh> no, this is a risk
14:58:33 <ralonsoh> having different DB upgrade paths could lead to errors in a future
14:58:37 <ralonsoh> due to convergence problems
14:58:51 <ralonsoh> this is backend problem, not Neutron
14:59:08 <ralonsoh> same as other problems in OVS, dnsmasq, iproute2, etc
15:01:21 <ralonsoh> (time goes by so slowly)
15:01:31 <liuyulong> ralonsoh, it is just like the current networking-ovn, vpnaas, fwaas, and so on.
15:02:10 <liuyulong> We have no Xaas, so we have no tables for that.
15:02:55 <liuyulong> alright, time is up.
15:03:05 <liuyulong> Let end here.
15:03:06 <liuyulong> #endmeeting