15:01:19 #startmeeting neutron_l3 15:01:20 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:23 The meeting name has been set to 'neutron_l3' 15:01:28 hi 15:01:33 hi 15:02:08 hi 15:02:25 hi everyone, lets get started... 15:02:34 #topic Announcements 15:03:28 Just a reminder there is about a month left until Stein-2, Jan 7-11 15:03:36 I will have to leave early today by 7.30. 15:04:03 but with US holidays we'll probably not have a full month of people-hours 15:04:12 Swami: ack, we'll do bugs next :) 15:04:43 any other announcements from people? 15:05:21 #topic Bugs 15:05:45 Swami: you want to do bugs? i see two new ones since last week i think 15:05:53 Yes. 15:06:01 #link https://bugs.launchpad.net/neutron/+bug/1774459 15:06:02 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 #link https://review.openstack.org/#/c/601336/ 15:07:15 I need reviewers to review this patch. It is quite complex patch that involves l2, l2pop and l3. 15:08:05 ack, i should have time later today or tomorrow 15:08:12 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 haleyb: thanks 15:08:32 I will wait for your review. 15:09:06 swami: I owe you some reviews 15:09:12 tidwellr: yes thanks 15:09:32 #link https://bugs.launchpad.net/neutron/+bug/1802006 15:09:33 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 There is a patch under review. #link https://review.openstack.org/#/c/622623/ 15:10:23 I think this fix is pretty trivial fix and minor one. So please review it. 15:10:50 #link https://bugs.launchpad.net/neutron/+bug/1804327 15:10:51 Launchpad bug 1804327 in neutron "occasional connection reset on SNATed after tcp retries" [Medium,In progress] - Assigned to Dirk Mueller (dmllr) 15:11:34 There is also a patch up for review for this bug. #link https://review.openstack.org/#/c/618208/ 15:12:16 Swami, tidwellr - I know there was a discussion regarding this one? 15:12:19 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 I'll be taking this one over 15:13:19 right, but is it dvr-only? seems like any floating would have the same issue? 15:13:26 I think we saw some bad behavior with SNAT, but not sure about FIP traffic 15:13:26 tidwellr: ok thanks 15:13:45 it's not specific to DVR 15:14:39 haleyb: do you think that we should also address this fix for the FIP traffic? 15:15:22 tidwellr: ack. looking i can't remember why that tcp_loose setting is only in the dvr code 15:15:29 haleyb: probably where ever the connection tracking is enabled. 15:15:54 right, the issue is around connection tracking 15:15:57 haleyb: yes I did also see the 'tcp_loose' only for the snat namespace. 15:16:10 so more of a general question on if we need to make this happen whereever conntrack is in play 15:16:33 haleyb: so in that case also the 'tcp_loose' setting should be applied where ever the connection tracking is enabled. 15:17:02 halybe: I think so 15:17:40 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 Swami: i think so, maybe we only ever saw a problem with dvr, i think i added that code too 15:18:02 haleyb: ok thanks 15:18:57 The next one in the list is #link https://bugs.launchpad.net/neutron/+bug/1805456 15:18:58 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 there is also a patch up for review. #link https://review.openstack.org/#/c/622449/ 15:20:01 I have not reviewed it yet, and I will review it. 15:20:39 The last one in my list is #link https://bugs.launchpad.net/neutron/+bug/1794991 15:20:40 Launchpad bug 1794991 in neutron "Inconsistent flows with DVR l2pop VxLAN on br-tun" [Undecided,New] 15:21:23 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 i have not had any cycles to look myself 15:22:12 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 Swami: i think there was one more in dhcp code, guess that's still l3 :) 15:22:55 https://bugs.launchpad.net/neutron/+bug/1806770 15:22:56 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 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 haleyb: Is this specific to DVR 15:23:48 no, but bug isn't dvr, just dhcp/ipam 15:24:19 haleyb: ok thanks 15:25:14 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 I need to drop off now. I will catch up in the neutron channel later. 15:26:19 Swami: ack, thanks for attending 15:27:21 any other bugs to discuss from the team? 15:27:47 nothing from me 15:28:48 #topic Check/gate failures 15:28:52 http://grafana.openstack.org/d/Hj5IHcSmz/neutron-failure-rate?orgId=1 15:29:07 not sure why i got the funky url... 15:29:47 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 guessing it had to do with non-voting jobs in check queues, so i'll follow-up with him 15:31:24 the dvr ones actually seem to track the "normal" ones pretty closely 15:32:00 except for the dvr scenario job that is 15:32:25 #topic Open discussion 15:32:31 I have to say I don't know much about these jobs, is there some redundancy there? 15:32:39 #undo 15:32:40 Removing item from minutes: #topic Open discussion 15:33:45 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 thanks, I assume streamlining this is a goal at some point? 15:35:44 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 ack 15:36:44 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 #action haleyb to re-propose patch for making dvr-ha-multinode tempest job voting 15:38:28 #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 #topic Open discussion 15:40:07 haleyb: I'm gonna make a small tweak to https://review.openstack.org/#/c/581098/ today 15:40:24 haleyb: based off your feedback 15:41:20 tidwellr: ok, great, my eye was just drawn to the nested for loops 15:41:36 make if 0.001 % faster :) 15:41:41 haleyb: right :) 15:41:43 s/if/it 15:42:14 but in the worst case on a large external network that can add up 15:43:17 thanks! 15:44:23 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 i have not had time to try and debug them 15:45:45 guess he's not here 15:46:42 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 yes, it's waiting for n-lib 1.21 15:47:17 and the patch for n-lib 1.21 it's almost merged 15:48:13 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 I'll do it once the lib bump patch is merged 15:49:01 great 15:49:57 anyone have something to discuss? 15:51:13 ok, thanks for attending, have a good weekend everyone 15:51:16 #endmeeting