14:01:34 #startmeeting neutron_l3 14:01:35 Meeting started Wed Mar 27 14:01:34 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:38 The meeting name has been set to 'neutron_l3' 14:01:47 o/ 14:01:51 hi 14:02:48 how are you all? 14:03:01 hi 14:03:07 Very well! 14:03:42 hi 14:03:54 igordc: hi, welcome 14:04:01 I'm alright, thanks 14:04:16 #topic Announcements 14:05:29 Two announcements: 14:06:08 1) We cut RC-1 over the weekend and yesterday during the Neutron weekly meeting we decided that there won't be another RC this cycle 14:06:24 so we are merging code to master as normal again 14:07:12 2) We have an etherpad to propose topics for the PTG in Denver: https://etherpad.openstack.org/p/openstack-networking-train-ptg 14:08:17 I can see that 13 people have already registered and 11 confirmed attendance to social event Friday night 14:08:21 \o/ 14:08:33 davidsha is attending! 14:08:38 hi 14:08:48 igordc: are you planning to be in Denver? 14:09:06 Looking forward to seeing davidsha again! 14:09:16 mlavalle, no, manjeets will be covering for me 14:09:44 igordc, what a pity... 14:10:00 ralonsoh, so close but so far... :) 14:11:12 igordc: ok, please look at line 47 of the etherpad. We want to review DVR openflow. the idea is that I would like to merge the code as eary as possible in the cycle, ideally before T-1, so we can debug it for the rest of the cycle 14:11:33 manjeets should be ready to discuss the status in Denver 14:11:40 mlavalle, yep 14:11:48 igordc: cool 14:12:08 any other announcements? 14:12:19 mlavalle, I'm also going to stay on etherpad and IRC during the PTG.. any plans for attempting live streaming like those few times before? 14:13:29 igordc: we have done that before. I will try it again this time aorund. Worst case, we can have a hangout with you on the dvr topic 14:14:20 mlavalle, awesome 14:14:21 njohnston: nice topic: IPAM... I agree 14:15:07 ok next topic... 14:15:12 #topic Bugs 14:15:17 I'm interested in the DVR openflow discussion as well. I'm especially interested in how we can manage the complexity of having so many kinds of DVR and supporting them all adequately. I think the instability of the DVR+L3HA job shows us that there is real operational and cognitive overhead there. 14:16:23 njohnston: also agree 14:16:39 and that includes lack of documentation 14:17:05 njohnston, I can see how dvr openflow can potentially also make things a bit more stable since there are less moving parts overall 14:17:29 It may needs more dev cycle to make it stable. Please follow the team and trace the bug to make it steady. 14:17:37 njohnston, but to get to feature parity with classic backend would still take a long while 14:17:53 liuyulong, yep 14:18:22 ok, first bug today: 14:18:24 https://bugs.launchpad.net/neutron/+bug/1789434 14:18:25 Launchpad bug 1789434 in neutron "neutron_tempest_plugin.scenario.test_migration.NetworkMigrationFromHA failing 100% times" [High,In progress] - Assigned to Miguel Lavalle (minsel) 14:18:54 I think we can close this one with the merge of https://review.openstack.org/636710 14:19:18 and done 14:19:53 Next one is https://bugs.launchpad.net/neutron/+bug/1821912 14:19:54 Launchpad bug 1821912 in neutron "intermittent ssh failures in various scenario tests" [High,Confirmed] 14:20:14 This is a bug report that we talke about yesterday during the CI meeting 14:20:20 yes 14:20:25 it is intended to be a collective effort 14:20:52 since at this point we haven't found a unifying pattern 14:21:16 so slaweq and I will be using the logstash query to find cases and then dig deeper in them 14:21:24 others are welcome to do the same 14:21:41 there is a lot of such examples in logstash, so it's easy to find :) 14:22:13 slaweq: thanks for filing it 14:22:22 yw mlavalle :) 14:22:57 we also have https://bugs.launchpad.net/neutron/+bug/1774459 14:22:58 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:23:18 progress on this has stalled since early January 14:24:05 I'll send a message to swami today and ask about it 14:24:24 if anyone wants to tackle this, please feel free 14:25:03 those are all the bugs I have today 14:25:10 any other bugs we should discuss? 14:26:14 I have 14:26:15 https://launchpad.net/bugs/1819160 14:26:17 Launchpad bug 1819160 in neutron "Functional tests for dvr ha routers are broken" [High,In progress] - Assigned to LIU Yulong (dragon889) 14:26:44 For now, I think we have found the root cause of this failure. 14:26:46 https://review.openstack.org/#/c/647784/ 14:26:48 oh I've been a victim of that one 14:27:20 That HA failover bridges veth pair devices were not set UP during the test. 14:27:54 This causes the VRRP advertisement packet can not pass to each HA port. So they set themselves all 'master'. 14:27:58 liuyulong: but it is needed together with https://review.openstack.org/#/c/642220/4 IIUC 14:28:12 slaweq, Yes 14:28:15 ok 14:28:40 For this patch https://review.openstack.org/#/c/642220/, we are going to give each HA case a specific VRRP id. 14:28:58 And each HA port a independent IP address. 14:29:45 https://review.openstack.org/#/c/642220/4/neutron/tests/functional/agent/l3/test_dvr_router.py There are some more cases need to add such IP, not only the failover cases. 14:30:46 ralonsoh's patch may also be needed. 14:31:13 https://review.openstack.org/#/c/645225/ 14:31:21 so we need 1) the veth links up, 2) make the IP different and 3) check both routers status 14:31:54 ralonsoh++ 14:31:55 ralonsoh, yes 14:32:33 ralonsoh's patch handled the situation is router2 can also be 'master' during the test. 14:32:33 is this latter patch rebased on one of the former two? 14:32:53 I'll rebase my patch to yours, liuyulong 14:33:00 ralonsoh: +++ 14:33:00 ralonsoh's patch can be independent. 14:33:23 is it worth doing some manual testing of this? any recommendations to try and make it fail? 14:34:26 igordc, I just run tox locally 14:35:41 anything else on this bug? 14:36:39 any other bugs? 14:36:52 Not from me 14:37:10 mlavalle, if I suspect a bug, is this a good place to mention it or just I first report it in launchpad always? 14:37:11 ok, let's move on 14:37:31 or should I first* 14:37:54 igordc: just report it in launchpad at tag it l3-dvr-backlog 14:38:09 and^^^ 14:38:24 mlavalle, what's the tag for non dvr? 14:38:43 l3-ipam-dhcp 14:39:05 mlavalle, thanks 14:39:14 ok, moving on 14:39:22 #topic openflow dvr 14:39:32 igordc: you are up 14:39:43 xubozhang also in the house 14:40:03 anyway, we've been polishing what we have 14:40:33 I've personally started the implemention of legacy for dvr, but am facing some issues and doubts regarding existing DNAT and SNAT in the openflow dvr patch 14:41:14 I don't see any risk for the scope we discussed on the mailing list except the scenario job, for so I'd like to ask whether merging every needed patch without a scenario job is something acceptable before train-1.... and later work on the scenario job? 14:42:16 I think that's ok 14:42:39 let's just try to keep things close to T-1 14:43:08 I'm also moving to other work at the moment, but will continue to hold the l3 agent refactor.. xubozhang will mostly hold the openflow dvr patch 14:43:21 mlavalle, yep 14:43:53 please review https://review.openstack.org/#/c/639605/ once I rebase it again 14:44:08 I expect it will be controversial due to the existing agent changes, so time will be needed to address things 14:44:49 yes, that is why I want to do this early 14:45:01 are thse all the patches: https://review.openstack.org/#/q/topic:openflow-based-dvr+(status:open+OR+status:merged) 14:45:28 mlavalle, that's right, that is the new topic per liuyulong's recommendation 14:45:46 mlavalle, we will tag the commit with it too so it doesn't reset the topic 14:45:49 ok I will add it to the blueprint in launchpad 14:45:58 Yes, it is based on the BP name. 14:46:20 that way it is easy to find the patches 14:47:18 also something that might not be clear: 14:47:42 the refactor patch actually depends on yang's router factory patch: https://review.openstack.org/#/c/620349 14:48:23 ahh good point 14:50:05 maybe we should put this patch under the samae topic 14:50:17 gerrit topic^^^^ 14:51:15 anything else? 14:51:56 haleyb, what's the state of neutron + ovn + dvr today? 14:53:00 I don't think he is in the meeting today 14:53:17 alright 14:53:21 that's all from my side 14:53:36 thanks for the update igordc 14:53:47 #topic On demand agenda 14:54:04 anything else we should discuss today? 14:55:01 ok, thanks for attending 14:55:22 especially you liuyulong and igordc. These are odd hours for you 14:55:29 thank you! 14:55:37 #endmeeting