14:00:26 #startmeeting neutron_l3 14:00:27 Meeting started Wed May 29 14:00:26 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:30 The meeting name has been set to 'neutron_l3' 14:00:40 o/ 14:00:51 o/ 14:00:52 hi 14:00:57 hi 14:02:10 #topic Announcements 14:03:26 We almost made it to the Train-1 milestone 14:03:35 it will take place nest week 14:03:53 hi 14:04:07 #link https://releases.openstack.org/train/schedule.html 14:04:43 any other annoucements from the team? 14:06:39 ok, let's move on 14:06:50 #topic Bugs 14:07:09 First one I have is https://bugs.launchpad.net/neutron/+bug/1824571 14:07:10 Launchpad bug 1824571 in neutron "l3agent can't create router if there are multiple external networks" [Critical,Fix released] - Assigned to Miguel Lavalle (minsel) 14:07:44 yesterday the fix was merged in master: https://review.opendev.org/#/c/661509/ 14:08:12 and the backport to stable/stein is here: https://review.opendev.org/#/c/661835/ 14:08:28 it only needs to be backported to stable/stein 14:08:43 I was thinking eralier today if I should add a release note 14:08:50 what do you think? 14:09:16 We have test cases to cover such issue? 14:09:30 we have a unit test 14:09:44 and I'm planning to add a tempest test case 14:10:33 Cool 14:12:10 Next bug is https://bugs.launchpad.net/neutron/+bug/1774459 14:12:11 Launchpad bug 1774459 in neutron "Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,Confirmed] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan) 14:13:16 Swami has patches for it: https://review.opendev.org/#/c/616272/ and here https://review.opendev.org/#/c/601336/ 14:13:32 the first one seems to be ready for review 14:13:54 Please take a look if you have time 14:14:23 the first might need an update or rebase 14:14:46 i last looked may 2nd and it hasn't changed 14:14:49 ack 14:14:55 Next one is https://bugs.launchpad.net/neutron/+bug/1821912 14:14:56 Launchpad bug 1821912 in neutron "intermittent ssh failures in various scenario tests" [High,In progress] - Assigned to LIU Yulong (dragon889) 14:15:41 yesterday slaweq and I did an analysis of one of the failures and we ruled out problems on the nova side with the metadata mechanism 14:16:32 does anyone have other updates? 14:16:41 yup 14:16:51 ralonsoh asked me to bring https://bugs.launchpad.net/neutron/+bug/1826419 to this meeting for discussion 14:16:53 Launchpad bug 1826419 in neutron "dhcp agent configured with mismatching domain and host entries" [Undecided,In progress] - Assigned to Miguel Lavalle (minsel) 14:17:20 #link https://review.opendev.org/#/c/657806/ 14:18:20 that's the associated review which reverts the dns_domain attribute usage back to the pre-queens behaviour 14:18:49 but feels like there is still some debate needed as to what the actual behaviour should be 14:19:46 we are talking about the network's dns_domain attribute? 14:19:52 yup 14:20:06 historically used for external dns integration via designate 14:20:19 i.e. floating ip's for instances get external DNS entries for example 14:20:30 let me provide some historical background 14:20:45 FYI: I have a patch try to disable such dhcp related dvr local router, https://review.opendev.org/#/c/601336/ 14:21:16 there were two specs to define dns integration: 14:21:18 Wrong link, sorry, https://review.opendev.org/#/c/364793/ 14:22:00 liuyulong: that seems like a different issue 14:22:37 I think this problem is more "trivial", if I can say it 14:22:38 as I comment in https://review.opendev.org/#/c/657806/1/neutron/agent/linux/dhcp.py@598, the domain set in the dnsmasq server is correctly sent via DHCP request 14:23:04 IMO, the problem is how the port dns_assignment is assigned 14:23:27 1) internal DNS integartion: https://specs.openstack.org/openstack/neutron-specs/specs/liberty/internal-dns-resolution.html. This had to do with making Neutron's internal DNS (dnsmasq) friendlier commands in the instances such as hostname -f 14:24:06 in this case we use the neutron config option dns_domain 14:25:16 2) Then we specified external DNS integration: https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/external-dns-resolution.html. This had to do with integrating Neutron with Designate (and potentially other DNSaaS) 14:27:52 that's where we added dns_domain attribute to network and floating ips and dns_name 14:27:58 haleyb, yes, it is, a headache for large deployment. 14:28:17 in order to be able to send those data to the external dns service 14:28:19 liuyulong: lets finish the dns domain discussion first 14:28:53 so up to this point there is a clear separation between spec 1 and 2, right? 14:31:12 and that's the bahavior that jamespage proposes to restore 14:31:15 correct? 14:31:28 I believe so 14:31:56 the bahavior that was implemented as a consequence of specs 1 and 2 14:32:31 then last year we got this patch, that srambled the status quo: https://review.opendev.org/#/c/571546/ 14:34:00 so I am inclined to revert https://review.opendev.org/#/c/571546/ as jamespage proposes 14:34:19 becasue that's what specified for internal DNS integration in 1 14:34:33 what am I missing? 14:36:00 and by the way, restores the specied behavior for the dns_domain attribute in 2 14:37:12 I'm OK with this 14:38:18 mlavalle: so is there a better way to fix https://bugs.launchpad.net/neutron/+bug/1774710 ? 14:38:19 Launchpad bug 1774710 in neutron "DHCP agent doesn't do anything with a network's dns_domain attribute" [Medium,Fix released] - Assigned to Assaf Muller (amuller) 14:38:55 haleyb: that's what I meant when I asked if I was missing something. let me explain.... 14:39:57 was that bug / fix proposed because we forgot the separation between dns_domain (config option) and dns_domain (network / fip attribute)? 14:40:31 reading the bug (https://bugs.launchpad.net/neutron/+bug/1774710) it looks like it 14:40:32 Launchpad bug 1774710 in neutron "DHCP agent doesn't do anything with a network's dns_domain attribute" [Medium,Fix released] - Assigned to Assaf Muller (amuller) 14:41:25 mlavalle: yes, looks like it 14:41:34 isn't this confusing that we have two settings with same name? 14:41:46 and both are used for something else? 14:42:14 I don't see any other rationale besides having the dns_domain attribute correspond to what there is in the network attribute 14:42:26 It should have a priority 14:42:35 slaweq: we can have that discussion 14:42:58 IMHO config option should be renamed to "internal_dns_domain" for example 14:43:05 going forward 14:43:29 but for the time being we have 2 specs to comply with 14:43:43 and that's jamespage's point 14:43:47 do we agree? 14:44:42 yes, I think so :) 14:45:08 +1 14:45:11 yes 14:46:12 ok cool, I think we have a consensus here 14:46:28 thanks to jamespage for his patience 14:46:45 and also to the team for putting up with my ling explanation ;-) 14:46:51 long^^^ 14:47:16 that explanation finally made this clear for me, thx :) 14:47:37 +1 great thanks for taking the time to discuss :) 14:47:56 any other bugs we should discuss today? 14:48:04 I have one 14:48:16 I wanted to ask about https://bugs.launchpad.net/neutron/+bug/1830554 - basically there is mismatch between api definition and api-ref description, so I wanted to ask what we should change to match both 14:48:17 Launchpad bug 1830554 in neutron "Port forwarding require always internal_ip_address to be given" [Low,Confirmed] - Assigned to Slawek Kaplonski (slaweq) 14:49:44 I think we should fix the api ref 14:49:53 mlavalle: that will be much easier :) 14:49:53 to reflect what the code says 14:49:59 ok, thx 14:50:08 I just wanted to have such confirmation 14:50:10 Since one port can have multiple fixed IPs, so internal_ip_address is needed. 14:50:27 most likely, yours truly introduced that error 14:50:52 I remeber that when zhaobo pushed the code, he didn't have api ref 14:50:58 so I did it over a weekend 14:51:17 so blame me 14:51:22 mlavalle: ok :) 14:51:37 anything else? 14:51:49 to discuss today? 14:51:53 You fixed my bug with external networks so I will fix "Your" bug in api-ref :P 14:52:01 LOL 14:52:10 I have 14:52:45 https://bugs.launchpad.net/neutron/+bug/1830014 14:52:46 Launchpad bug 1830014 in neutron "[RFE] add API for neutron debug tool "probe"" [Undecided,New] 14:53:08 A new RFE which comes from bug 1821912 14:53:09 bug 1821912 in neutron "intermittent ssh failures in various scenario tests" [High,In progress] https://launchpad.net/bugs/1821912 - Assigned to LIU Yulong (dragon889) 14:53:57 It does not approve yet, but I want to know what the team think. 14:55:07 It's something like, we should make sure neutron do everything fine 14:57:48 Marking this as " 14:57:48 Opinion" in lauchpad, you guys can leave comments there. 14:58:11 so let's have the team read and comment it 14:58:38 I'll do just that tomorrow as part of my preparation for the drivers meeting on Friday 14:58:42 We are running out of time, I have another bug: https://bugs.launchpad.net/neutron/+bug/1828494 14:58:44 Launchpad bug 1828494 in neutron "[RFE][L3] l3-agent should have its capacity" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) 14:59:06 And I submit the code here: https://review.opendev.org/#/c/661492/ 14:59:29 for this one spec is proposed, IMO lets discuss in spec review for now 14:59:30 Maybe we can discuss these in drivers meeting this week. 14:59:33 ok, thanks for bringing it up 14:59:41 liuyulong: I will also look at it 14:59:42 OK 15:00:19 if by Friday you see any of those RFEs tagged as "rfe-triaged", then we will discuss on Friday 15:00:35 if not, I and others will leave questions in the RFE 15:00:35 Sure 15:00:37 ok? 15:00:47 #endmeeting