14:01:11 #startmeeting neutron_l3 14:01:12 Meeting started Wed Aug 14 14:01:11 2019 UTC and is due to finish in 60 minutes. The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:16 The meeting name has been set to 'neutron_l3' 14:01:58 hi 14:02:04 hi 14:02:27 hi 14:02:59 OK, my backup liuyulong_ is coming now. 14:03:13 #chair liuyulong_ 14:03:13 Current chairs: liuyulong liuyulong_ 14:03:23 #topic Announcements 14:04:31 I received a early bird Shanghai Summit notify email, it will expire in less than 24 hours. 14:05:28 It has a 30% discount. 14:07:17 Next thing: seems our "U" name polling is started. 14:07:56 #link https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_19e5119b14f86294&akey=0cde542cb3de1b12 14:09:10 It was a very active email discussion thread, and finally we will have an official name. 14:10:08 Any other announcements? 14:10:33 not from me 14:11:17 OK, next topic 14:11:23 #topic Bugs 14:12:12 amotoki send us the email, it has only 3 bugs. 14:12:41 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008436.html 14:12:48 No L3 related. 14:13:14 So let me raise some old ones. 14:14:51 #link https://bugs.launchpad.net/neutron/+bug/1817881 14:14:52 Launchpad bug 1817881 in neutron " [RFE] L3 IPs monitor/metering via current QoS functionality (tc filters)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) 14:15:14 I've subnet the POC of this: https://review.opendev.org/#/c/675654/ 14:15:39 The patch does not consider the default value yet, It only check the filter rules, and do metering. 14:16:22 it's big 14:16:24 An independent patch will be submitted to do the default TC filter installation. 14:16:24 :) 14:17:12 Yes, it is, consider the default TC filter installation, it will get bigger... 14:17:20 hi, sorry i'm late 14:18:37 hi 14:18:43 #chair haleyb 14:18:44 Current chairs: haleyb liuyulong liuyulong_ 14:18:53 liuyulong: so was my comment on that change correct that the metering agent can go away afterwards? 14:19:56 haleyb, no, if user still wants to get some internal east-west traffic usage, the original metering will still be needed. 14:20:59 This is only for floating IP and router gateway IP. Internal gateway traffic will not be considered. 14:21:44 can we enhance this to support that as well? just that the metering agent has not been well maintained, although someone has been trying to fix it 14:22:42 It could, can be another agent extension. 14:24:18 At present, the traffic data of public IP seems to be more necessary. 14:24:30 yes, agreed 14:26:15 OK, next 14:26:37 #link https://bugs.launchpad.net/neutron/+bug/1609217 14:26:38 Launchpad bug 1609217 in neutron "DVR: dvr router ns should not exist in scheduled DHCP agent nodes" [High,In progress] - Assigned to LIU Yulong (dragon889) 14:26:46 The code is here: https://review.opendev.org/#/c/364793/ 14:27:35 We have this code locally for a while, it is really good for large amount of user networks and router. 14:29:03 it would be good to get mlavalle's opinion on that, to see if what i suggested was crazy 14:29:14 or wrong 14:29:15 Otherwise, when the number of routers and networks increases to a certain scale, l3-agent and ovs-agent will not restart normally in the high probability. 14:29:42 haleyb, sure 14:30:51 For now, I may say 300 routers and the connected 300 networks should be the bottleneck. 14:30:59 Or the scale ceiling 14:32:20 For a frequently developing cloud, this is a real pain point. 14:33:25 But for a long stand cloud, should be worrying about is unexpected restart. 14:34:51 liuyulong: agent restart is the largest issue we see frequently as well 14:35:02 When your cloud scale exceed such point, accidental failure recovery will become more difficult. 14:37:46 last one: https://bugs.launchpad.net/neutron/+bug/1826695 14:37:47 Launchpad bug 1826695 in neutron "[L3][QoS] cache does not removed when router is down or deleted" [High,In progress] - Assigned to LIU Yulong (dragon889) 14:38:00 I may say it is ready now. 14:38:51 And the fix should be backported to queens. 14:40:01 any other bugs? 14:40:53 I have one 14:40:56 give me a sec 14:41:21 https://bugs.launchpad.net/neutron/+bug/1818824 14:41:22 Launchpad bug 1818824 in neutron "When a fip is added to a vm with dvr, previous connections loss the connectivity" [Low,In progress] - Assigned to Gabriele Cerami (gcerami) 14:42:22 I'm not an owner of this bug but I wanted to ask You to take a look into it and write Your opinions about it in comments to it 14:43:28 slaweq, sure, go ahead 14:45:06 liuyulong: I already pasted it above :) 14:49:44 It is an feature, IMO, we have such conclusion once. 14:51:03 liuyulong_: what is a feature? Behaviour in dvr case or in non-dvr case? 14:51:05 test 14:52:42 dvr for compute L3 agent only, dvr_no_external may not have such issue as well. 14:56:09 Only when the VM is in a compute node which set the agent mode to 'dvr', the SNAT traffic will be down. But IMO, the traffic can be fixed soon, if your application have nice reconnection mechanism. 14:57:21 slaweq, thanks for bring this up. 14:57:27 we are running out of time. 14:57:40 #topic On demand agenda 14:58:10 mlavalle, tidwellr, wwriverrat: news about routed network to upate? 14:59:06 I assume it is 'no'. 14:59:12 OK, let's end here. 14:59:16 #endmeeting