15:05:06 #startmeeting neutron_l3 15:05:07 Meeting started Thu Jan 31 15:05:06 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:10 The meeting name has been set to 'neutron_l3' 15:06:08 hi anybody here for the L3 sub-team meeting? 15:06:17 hi mlavalle I am 15:06:35 o/ 15:06:39 welcome igordc 15:06:50 welcome tidwellr 15:07:09 so let's get started 15:07:21 #topic Announcements 15:08:05 First of next milestone is Stein-3, March 4 - 8 15:08:28 it will be hear before we know it ;-) 15:08:36 here^^^ 15:08:45 oh yeah... 15:09:44 Also, I want to make sure everybody so this nomination: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002195.html 15:10:26 This is expecially relevant for this team because liuyulong places a lot of mephasis in L3 in general 15:10:51 and I expect him to take a more prominent role in leading the L3 sub-team 15:11:12 excellent 15:12:03 He won't be here today because China in general is about to stop for a week for their new lunar year celebration, which they call the Spring Festival 15:12:19 so we won't see much of him until the week of Feb 9th 15:15:13 #topic Bugs 15:15:45 In terms of bugs, I've been working investigating https://bugs.launchpad.net/neutron/+bug/1795870 15:15:46 Launchpad bug 1795870 in neutron "Trunk scenario test test_trunk_subport_lifecycle fails from time to time" [High,In progress] - Assigned to Miguel Lavalle (minsel) 15:16:31 As you can see in the latest note I posted there: https://bugs.launchpad.net/neutron/+bug/1795870/comments/10 15:17:01 This is a two nodes test, where after digging I have found that the L3 agent crashes in the master node 15:17:38 so at that point in time, neutron server deems the agent unreachable 15:17:49 and stops scheduling routeres there 15:18:33 the failure happens in all cases I've seen after a migration is attempeted from HA router to dvr / legacy 15:18:43 digging on that is my next step 15:19:40 I am also working on https://bugs.launchpad.net/neutron/+bug/1812168 15:19:41 Launchpad bug 1812168 in neutron "Neutron doesn't delete Designate entry when port is deleted" [High,New] - Assigned to Miguel Lavalle (minsel) 15:20:02 I have a test environment where I will attempt to reproduce the bug 15:20:26 it is a combination of steps that I don't think we attempt in our tests 15:20:47 so if I confirm the bugs and propose a fix, we also need to increase our tests coverage 15:22:00 Those are all the bugs I have for today 15:22:14 Does anyone else want to bring up other bugs? 15:22:41 not today 15:22:48 I don't have anything 15:23:27 ok, cool 15:23:35 #topic OVS OpenFlow L3 DVR / dvr_bridge agent_mode 15:23:48 igordc, xubozhang: you are up 15:24:12 btw, igordc, welcome to the effort :-) 15:24:36 mlavalle, :) 15:25:00 mlavalle, so I just wanted to reiterate the questions posted on the ML 15:25:28 mlavalle, I personally agree with the replies but would like to hear more from you too (and haleyb but he's not in today) 15:26:17 the big question really is about having another option apart from agent_mode 15:26:40 something like an "agent_backend" to choose between kernel or ovs router implementation 15:26:54 This past Monday I started a new job and was in opientation. My orientation was remote.... and then we discovered that the USA I-9 employment verification form cannot be done remotely in Texas whre I live 15:27:22 so I spent all day long yesterday driving to and from Dallas 15:27:28 3 hours each way 15:27:41 so I didn't have time to look at your email 15:27:47 mlavalle, ah, don't even mention I-9 to me :// 15:28:00 igordc: for what it's worth, something like agent_backend is more palatable to me. The agent mode flag doesn't seem to control this aspect of the agent 15:28:21 I would prefer not to overload it in this way 15:28:59 tidwellr, same 15:29:00 so my point is I didn't have time to look at your message 15:29:15 having said that, in principle I agree with tidwellr 15:29:36 tidwellr: did you chime in the ML thread? 15:30:11 I have not yet, but I will. Still digging out of my holiday/travel/illness backlog :) 15:30:21 please do 15:30:44 tidwellr, thanks 15:31:13 igordc: I'll respond today with my thoughts in the ML. That way we can also have haleyb express his opinion 15:31:33 mlavalle, awesome, thanks 15:31:48 we have drivers meeting tomorow, so if by thn he hasn't responded, I'll poke him a little bit 15:32:12 where are you based out of, igordc? 15:32:33 alright, in the meantime we still have quite a few openflow-related unit testing to do 15:32:43 cool 15:32:44 mlavalle, I am in oregon, so pacific time 15:33:29 ok, cool. I'm glad you have joined the effort. Let's try to get this done by Stein-3 15:33:55 igordc: I'm personally quite interested in this effort, and it does bump into a few thing I'm working on so we should catch up sometime 15:34:20 tidwellr, for sure, we should 15:34:39 igordc: is your plan to finish this by Stein-3? 15:34:54 this is originally davidsha's effort, hopefully this time it will get in 15:35:02 mlavalle, it is 15:35:06 cool 15:35:27 it is in our Stein-3 dashboard, so let's get it in 15:36:05 me and xubozhang are trying to optimize the work items needed to get this by stein-3 15:36:55 anyhting else on this topic? 15:40:20 that is all from me 15:40:37 cool 15:40:43 #topic On demand agenda 15:41:18 DVR-aware BGP https://review.openstack.org/#/c/581098/ could use some eyes 15:41:27 tidwellr, igordc: I am considering moving this meeting 1 hour earlier and probably to Wednesday 15:41:55 tidwellr: added to my pile. Thanks for bringing it up 15:42:04 do you want to comment further on it? 15:42:05 I know some of the sqlalchemy is obscure (I want to refactor this) 15:42:40 but this is ready to go, I think we can easily land this in Stein 15:43:25 tidwellr: LOL. I have a confession to make.... you, John Davidge and carl_baldwin always intimidated me with your SQLAlchemy prowess 15:43:52 mlavalle: necessity breeds innovation :) 15:44:14 there are some pieces in the IPAM code that I always struggle with 15:44:36 but with the advent of OVO and some learning about how BGP performs under load I think this can be refactored so it's not as imposing 15:44:52 cool 15:44:56 will take a look 15:45:22 going back to my previous comment 15:45:58 mlavalle: that time would work for me 15:46:06 would it be too bad if we move this meeting one hour earlier and to Wednesday? 15:46:40 that time slot doesn't work in Thursdays, but it's fine on Wednesdays 15:47:09 when we move back to day saving time, it won't be too bad either 15:47:26 I'm trying to make life easier for liuyulong 15:47:43 he is attending this meeting from 11pm to midnight 15:48:01 ok, I'll propose I patch and I will add you two to the reviews 15:48:08 so you can chime in 15:48:28 anythinbg else we should discuss today? 15:48:44 mlavalle, it's 6am here but actually I usually have conflict at 7am, so it's better for me 15:49:00 igordc: that's perfect. thanks 15:49:08 even on weds 15:49:12 cool 15:49:47 ok, thanks for attending 15:49:55 #endmeeting