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