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