15:01:19 <haleyb> #startmeeting neutron_l3
15:01:20 <openstack> Meeting started Thu Dec  6 15:01:19 2018 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:23 <openstack> The meeting name has been set to 'neutron_l3'
15:01:28 <ralonsoh> hi
15:01:33 <Swami> hi
15:02:08 <tidwellr> hi
15:02:25 <haleyb> hi everyone, lets get started...
15:02:34 <haleyb> #topic Announcements
15:03:28 <haleyb> Just a reminder there is about a month left until Stein-2, Jan 7-11
15:03:36 <Swami> I will have to leave early today by 7.30.
15:04:03 <haleyb> but with US holidays we'll probably not have a full month of people-hours
15:04:12 <haleyb> Swami: ack, we'll do bugs next :)
15:04:43 <haleyb> any other announcements from people?
15:05:21 <haleyb> #topic Bugs
15:05:45 <haleyb> Swami: you want to do bugs?  i see two new ones since last week i think
15:05:53 <Swami> Yes.
15:06:01 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1774459
15:06:02 <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)
15:06:42 <Swami> #link https://review.openstack.org/#/c/601336/
15:07:15 <Swami> I need reviewers to review this patch. It is quite complex patch that involves l2, l2pop and l3.
15:08:05 <haleyb> ack, i should have time later today or tomorrow
15:08:12 <Swami> First I need to know if I am going in the right direction. As far as I know it seems ok, but I wanted to be careful in addressing the OVS flow changes, so that I don't pollute the local_switching table in br_int.
15:08:21 <Swami> haleyb: thanks
15:08:32 <Swami> I will wait for your review.
15:09:06 <tidwellr> swami: I owe you some reviews
15:09:12 <Swami> tidwellr: yes thanks
15:09:32 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1802006
15:09:33 <openstack> Launchpad bug 1802006 in neutron "Floating IP attach/detach fails for non-admin user and unbound port with router in different tenant" [Medium,In progress] - Assigned to Arjun Baindur (abaindur)
15:10:01 <Swami> There is a patch under review. #link https://review.openstack.org/#/c/622623/
15:10:23 <Swami> I think this fix is pretty trivial fix and minor one. So please review it.
15:10:50 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1804327
15:10:51 <openstack> Launchpad bug 1804327 in neutron "occasional connection reset on SNATed after tcp retries" [Medium,In progress] - Assigned to Dirk Mueller (dmllr)
15:11:34 <Swami> There is also a patch up for review for this bug. #link https://review.openstack.org/#/c/618208/
15:12:16 <haleyb> Swami, tidwellr - I know there was a discussion regarding this one?
15:12:19 <Swami> haleyb: you had a question in the bug about if this is related to DVR. I think we have seen this issue in a DVR environment.
15:12:55 <tidwellr> I'll be taking this one over
15:13:19 <haleyb> right, but is it dvr-only?  seems like any floating would have the same issue?
15:13:26 <tidwellr> I think we saw some bad behavior with SNAT, but not sure about FIP traffic
15:13:26 <Swami> tidwellr: ok thanks
15:13:45 <tidwellr> it's not specific to DVR
15:14:39 <Swami> haleyb: do you think that we should also address this fix for the FIP traffic?
15:15:22 <haleyb> tidwellr: ack.  looking i can't remember why that tcp_loose setting is only in the dvr code
15:15:29 <Swami> haleyb: probably where ever the connection tracking is enabled.
15:15:54 <tidwellr> right, the issue is around connection tracking
15:15:57 <Swami> haleyb: yes I did also see the 'tcp_loose' only for the snat namespace.
15:16:10 <haleyb> so more of a general question on if we need to make this happen whereever conntrack is in play
15:16:33 <Swami> haleyb: so in that case also the 'tcp_loose' setting should be applied where ever the connection tracking is enabled.
15:17:02 <tidwellr> halybe: I think so
15:17:40 <Swami> tidwellr: if we agree that it has to be applied to all connection tracking code, then ignore my comment in the patch.
15:17:46 <haleyb> Swami: i think so, maybe we only ever saw a problem with dvr, i think i added that code too
15:18:02 <Swami> haleyb: ok thanks
15:18:57 <Swami> The next one in the list is #link https://bugs.launchpad.net/neutron/+bug/1805456
15:18:58 <openstack> Launchpad bug 1805456 in neutron "[DVR] Neutron doesn't configure multiple external subnets for one network properly" [Medium,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:19:43 <Swami> there is also a patch up for review. #link https://review.openstack.org/#/c/622449/
15:20:01 <Swami> I have not reviewed it yet, and I will review it.
15:20:39 <Swami> The last one in my list is #link https://bugs.launchpad.net/neutron/+bug/1794991
15:20:40 <openstack> Launchpad bug 1794991 in neutron "Inconsistent flows with DVR l2pop VxLAN on br-tun" [Undecided,New]
15:21:23 <Swami> I was not able to reproduce this problem locally. But similar problems have been reported. I will have to see how we can reproduce this locally before we provide a fix.
15:22:01 <haleyb> i have not had any cycles to look myself
15:22:12 <Swami> haleyb: I am not sure if I covered that two new bugs that you mentioned that came in this week. But this is what I had in my list.
15:22:50 <haleyb> Swami: i think there was one more in dhcp code, guess that's still l3 :)
15:22:55 <haleyb> https://bugs.launchpad.net/neutron/+bug/1806770
15:22:56 <openstack> Launchpad bug 1806770 in neutron "DHCP Agent should not release DHCP lease when client ID is not set on port" [Medium,Triaged] - Assigned to Arjun Baindur (abaindur)
15:23:02 <Swami> haleyb: let us prioritize on the ARP responder patch. Once I am freed up from that patch, I can move to other backlog items.
15:23:19 <Swami> haleyb: Is this specific to DVR
15:23:48 <haleyb> no, but bug isn't dvr, just dhcp/ipam
15:24:19 <Swami> haleyb: ok thanks
15:25:14 <haleyb> there are two patches up for review for the dhcp issue, arjun wanted input on which was better, i've been reviewing
15:26:06 <Swami> I need to drop off now. I will catch up in the neutron channel later.
15:26:19 <haleyb> Swami: ack, thanks for attending
15:27:21 <haleyb> any other bugs to discuss from the team?
15:27:47 <tidwellr> nothing from me
15:28:48 <haleyb> #topic Check/gate failures
15:28:52 <haleyb> http://grafana.openstack.org/d/Hj5IHcSmz/neutron-failure-rate?orgId=1
15:29:07 <haleyb> not sure why i got the funky url...
15:29:47 <haleyb> i know miguel wanted to discuss something regarding the dvr job, just don't remember the context, let me look at the page for a second
15:31:06 <haleyb> guessing it had to do with non-voting jobs in check queues, so i'll follow-up with him
15:31:24 <haleyb> the dvr ones actually seem to track the "normal" ones pretty closely
15:32:00 <haleyb> except for the dvr scenario job that is
15:32:25 <haleyb> #topic Open discussion
15:32:31 <tidwellr> I have to say I don't know much about these jobs, is there some redundancy there?
15:32:39 <haleyb> #undo
15:32:40 <openstack> Removing item from minutes: #topic Open discussion
15:33:45 <haleyb> tidwellr: yes, there has always been a little.  the plan a while back was to just have a dvr/ha/multinode job and remove one of the others, it just isn't as stable
15:34:33 <tidwellr> thanks, I assume streamlining this is a goal at some point?
15:35:44 <haleyb> tidwellr: it was a goal that we've never seemed to finish, i'll have to revive or create a new patch to at least make the tempest job voting
15:36:27 <tidwellr> ack
15:36:44 <haleyb> the scenario job will need some investigation into why it's failing, for the past week it's been 2x, but today it looks 10x
15:37:35 <haleyb> #action haleyb to re-propose patch for making dvr-ha-multinode tempest job voting
15:38:28 <haleyb> #action haleyb to investigate why neutron-tempest-plugin-dvr-multinode-scenario job failure rate has jumped
15:38:49 * haleyb assumes the meeting bot recorded that
15:39:20 <haleyb> #topic Open discussion
15:40:07 <tidwellr> haleyb: I'm gonna make a small tweak to https://review.openstack.org/#/c/581098/ today
15:40:24 <tidwellr> haleyb: based off your feedback
15:41:20 <haleyb> tidwellr: ok, great, my eye was just drawn to the nested for loops
15:41:36 <haleyb> make if 0.001 % faster :)
15:41:41 <tidwellr> haleyb: right :)
15:41:43 <haleyb> s/if/it
15:42:14 <tidwellr> but in the worst case on a large external network that can add up
15:43:17 <haleyb> thanks!
15:44:23 <haleyb> xubozhang: are you around?  you had pinged me about https://review.openstack.org/#/c/528336/ earlier, didn't know if you had made progress on failures
15:45:17 <haleyb> i have not had time to try and debug them
15:45:45 <haleyb> guess he's not here
15:46:42 <haleyb> ralonsoh: i saw https://review.openstack.org/#/c/611059/ was in the agenda, but perhaps that is old?  review looks like it's waiting for new neutron-lib
15:47:05 <ralonsoh> yes, it's waiting for n-lib 1.21
15:47:17 <ralonsoh> and the patch for n-lib 1.21 it's almost merged
15:48:13 <haleyb> ralonsoh: ack, i think you can remove the depends-on for that change, as it doesn't exactly work for pulling-in newer lib, right?
15:48:33 <ralonsoh> I'll do it once the lib bump patch is merged
15:49:01 <haleyb> great
15:49:57 <haleyb> anyone have something to discuss?
15:51:13 <haleyb> ok, thanks for attending, have a good weekend everyone
15:51:16 <haleyb> #endmeeting