14:00:12 #startmeeting neutron_l3 14:00:13 Meeting started Wed Oct 23 14:00:12 2019 UTC and is due to finish in 60 minutes. The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:17 The meeting name has been set to 'neutron_l3' 14:00:19 #chair liuyulong_ 14:00:20 Current chairs: liuyulong liuyulong_ 14:00:29 #chair haleyb 14:00:30 Current chairs: haleyb liuyulong liuyulong_ 14:00:33 #chair slaweq 14:00:34 Current chairs: haleyb liuyulong liuyulong_ slaweq 14:00:38 hi 14:00:44 hi 14:00:48 Just in case... 14:01:41 #topic Announcements 14:02:24 I received the QR code of the Shanghai Summit ticket on Tuesday. 14:02:45 Maybe you guys may also have that now. 14:03:07 So only one important thing is see you guys in Shanghai. 14:04:19 And I'd like to cancel the L3 meeting next week, because we will have totally three day times to discuss things in the PTG meetings. 14:04:32 +1 from me 14:05:53 OK, that's all from me about the announcement. 14:06:59 OK, let's move on. 14:07:05 #topic Bugs 14:07:17 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010249.html 14:07:39 Hongbin was our bug deputy last week, and thanks. 14:08:32 First one 14:08:48 #link https://bugs.launchpad.net/neutron/+bug/1848187 14:08:48 Launchpad bug 1848187 in neutron "DHCP agent timing out spawning dnsmasq" [Medium,In progress] - Assigned to Will Szumski (willjs) 14:09:18 * slaweq is just lurking here 14:09:49 The patch is abandoned, https://review.opendev.org/#/c/688693/ 14:10:38 Seems the root cause is still unclear. 14:12:12 So let's wait to see if the bug reporter can supply more details as slaweq requested. 14:13:04 IMO this bug can be closed now, it was the issue with ulimits in containers AFAIU 14:13:23 I don't think we should do anything with that on Neutron's side 14:16:04 One interesting thing is that we disable the root-wrapper-deamon for DHCP-agent also, it will have a better performance during processing networks. 14:16:31 slaweq, so you have the right to disable it right now, :) 14:16:45 next 14:16:47 #link https://bugs.launchpad.net/neutron/+bug/1848738 14:16:47 Launchpad bug 1848738 in neutron "Sometimes dnsmasq may not be restarted after adding new subnet" [Medium,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:16:52 https://review.opendev.org/#/c/689515/ 14:17:13 The fix is getting merged. 14:17:13 So thank you slaweq for the fix. 14:17:40 liuyulong: about which fix You are now talking about? 14:18:09 slaweq, this one 1848738 14:18:20 ahh, it's still in the gate 14:18:25 not merged yet 14:18:30 and it is only partial fix 14:18:48 I will still have to investigate why this happens sometimes that dnsmasq isn't restarted when it should be 14:21:27 we met some DHCP agent issues locally in stable/queens. There will be one race condition between R/W of the DHCP agent resource cache. 14:22:54 And finally cause the port processint timeout, or the IP/mac info of the dnsmasq config failed to install. 14:23:01 s/processing 14:23:44 I mean the DHCP related processing, aka config the dnsmasq for DHCP. 14:24:33 use_helper_for_ns_read = False and root_helper_daemon= can also be used for DHCP agent. 14:25:08 OK, let's scan the LP bug list. 14:25:46 #link https://bugs.launchpad.net/neutron/+bug/1849392 14:25:46 Launchpad bug 1849392 in neutron "Neutron - Stein - Having two external networks will prevent the router from being created." [Undecided,New] 14:26:11 that one is confusing me as I though we already fixed it some time ago 14:26:21 so I plan to take a look into that ASAP 14:26:39 slaweq, cool 14:27:04 slaweq, master branch does not have such issue, right? 14:27:14 liuyulong: I don't know 14:27:23 if so, it would mean that we just missed some backport 14:27:28 I will check that 14:28:26 slaweq, Exactly 14:30:28 Next 14:30:31 #link https://bugs.launchpad.net/neutron/+bug/1847763 14:30:31 Launchpad bug 1847763 in neutron "cannot reuse floating IP as port's fixed-ip" [Undecided,Incomplete] 14:31:14 This looks like not the Neutron bug. 14:31:45 The new port was using that floating IP address. 14:32:31 More like a guest DHCP client config issue, something like NetworkManager, Cloud-init or network-scripts. 14:34:08 One more strange thing we noticed locally is, the external network is have a empty DHCP schedule entry in the DB no matter the enable-dhcp is True or False. 14:35:14 And this bug is more like that, the DHCP is enabled for external network floating IP subnet. 14:35:32 liuyulong: the DB entry for the network has dhcp blank? 14:36:35 haleyb, yes, in stable/queens we noticed that. 14:37:04 neutron dhcp-agent-list-hosting-net , you will see an schedule instance. 14:38:01 no matter enable dhcp or not. 14:39:13 I'd like to ask if we could add some config to disable such DHCP behavior for external network by default. 14:39:40 i guess that should be Ok 14:40:51 If someone wants to enable, or boot VM in external network, they should change that config to clearly know what they are doing. 14:41:38 OK, that's all bugs from me. 14:41:50 I have one moew 14:41:52 Any additions? 14:42:02 (one sec) 14:42:12 ralonsoh, sure, please go ahead. 14:42:18 #link https://bugs.launchpad.net/neutron/+bug/1849502 14:42:18 Launchpad bug 1849502 in neutron "[DHCP] Check the dnsmasq process status after enabling the process" [Undecided,New] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 14:42:23 just a heads-up 14:42:25 filled 10 mins ago 14:42:31 but I think I have the solution 14:42:40 I'll push the patch today 14:42:42 that's all 14:42:54 * liuyulong reading... 14:43:22 long story short: dnsmasq started with 1 subnet 14:43:29 network updated with 2 more subnets 14:44:05 the dhcp agent do not find the process (when stopping it) and then, when starting it, the process is active (so the agent do not start ir again) 14:45:47 looks a bit like the race condition I just mentioned in the meeting. ^^^ 14:45:55 data inconsistence between agent and neutron DB. : ) 14:46:05 kind of 14:46:08 ralonsoh: is this related to the other bug slaweq was fixing with tags too? 14:46:09 the DB is ok in this case 14:46:17 haleyb, not exactly 14:46:29 IMO, the tags patch is not needed 14:46:35 but I left a comment on it 14:46:45 maybe i'm missing something in this patch 14:48:23 "Sometimes dnsmasq may not be restarted after adding new subnet" this is the bug title reported by slaweq. 14:48:27 bug 1848738 14:48:27 bug 1848738 in neutron "Sometimes dnsmasq may not be restarted after adding new subnet" [Medium,In progress] https://launchpad.net/bugs/1848738 - Assigned to Slawek Kaplonski (slaweq) 14:48:34 yes 14:48:41 the tags patch makes things a little simpler, with the subnet-id in the tag 14:48:44 I know, but I don't think the patch solves this problem 14:48:51 at least the one described in my bug 14:49:09 the problem I found is not related with the tags 14:49:26 but with detecting or not the status of the dnsmasq process (running or not) 14:49:50 ack 14:50:32 OK, so you have any reproduce steps? 14:50:55 kind of 14:51:09 we have an automated deployment system, using tripleo 14:51:12 I could not open the site pastebin.test.redhat.com 14:51:31 May you use the paste.openstack.org? 14:51:34 When using several subnets (and segments), this bug occurs 14:51:44 sure, I'll change the links 14:54:05 ralonsoh, we are running out of time, so please add some reproduce step in the bug or pastebin, we can test it locally. 14:54:19 Next topic 14:54:20 #topic On demand agenda 14:54:32 I'd like to update some IPv6 test status. 14:55:20 One thing is that we will not use SLAAC for ipv6 subnets. 14:55:38 Because for multiple ipv6 subnets in one network 14:56:28 The created port will have all IPv6 subnets address automatically by default. 14:57:19 We can change the neutron DB code to let it have one IP only, but the router RA advise will send out randomly. 14:57:49 So the IPv6 prefix may be wrong with the port real IPv6 address. 14:57:50 liuyulong: the RA should have both prefixes, correct? 14:58:00 Inside the VM 14:58:40 haleyb, yes, it will 14:59:52 i guess i don't understand the issue yet 15:00:02 but we are out of time 15:00:20 OK, I will create a bug for detail. 15:00:26 #endmeeting