15:00:07 #startmeeting neutron_l3 15:00:08 Meeting started Thu Jun 15 15:00:07 2017 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:11 The meeting name has been set to 'neutron_l3' 15:00:23 #chair haleyb Swami 15:00:27 Current chairs: Swami haleyb mlavalle 15:00:33 hi 15:00:36 hi 15:01:03 in case somebody disconnects, we have redundant charis :-) 15:01:10 chairs^^^^ 15:01:21 #topic Announcements 15:01:54 I need to leave early today. Just for your info. 15:02:04 ok 15:02:26 We are well on our way to Pike-3 15:02:35 #link https://releases.openstack.org/pike/schedule.html 15:02:44 any other announcements? 15:03:22 ok 15:03:27 #topic Bugs 15:03:50 let's start with dvr bugs, so Swami can leave early.... 15:04:11 mlavalle: thanks 15:05:04 New bug this week. 15:05:07 #link https://bugs.launchpad.net/neutron/+bug/1695140 15:05:08 Launchpad bug 1695140 in neutron "SRC without FIP,DEST with FIP case is broken for dvr-multinode" [Undecided,New] - Assigned to Brian Haley (brian-haley) 15:06:12 I saw the comment in there from brian and it seems that it might be due to the regression. I will monitor that in the coming week. 15:06:37 Swami: now that we re-merged https://review.openstack.org/#/c/470063/ we should re-check 15:06:50 er, just merged 15:07:22 There is one issue that I found with this patch. The functional test is failing with the ha combination. 15:07:34 I will try to push a patch to fix that test case. 15:07:49 is it a problem with the test or the code? 15:08:02 It is the problem with the test. 15:08:27 In the case of ha, there are two snat nodes and the host binding is not matching. 15:08:52 I will push in a patch that fixes the test case. 15:09:05 I just tested it and it is running fine. 15:10:09 http://logs.openstack.org/07/474007/2/check/gate-neutron-dsvm-functional-ubuntu-xenial/4eee227/testr_results.html.gz 15:10:25 here is the info about that test failure in gate. 15:11:11 The next one in the list is 15:11:14 #link https://bugs.launchpad.net/neutron/+bug/1696983 15:11:15 Launchpad bug 1696983 in neutron "ovs-fw: flows on br-int are overlapping with dvr flows" [Undecided,In progress] - Assigned to Jakub Libosvar (libosvar) 15:12:05 libosvar has already pushed in patch to address this issue. 15:12:19 #link https://review.openstack.org/#/c/472691/ 15:12:54 I will review it. I have not reviewed it yet and I do see brian had already reviewed it. 15:13:13 I recently reviewed a spec that is going to help with this kind of problems 15:13:15 yes, it looked ok to me 15:13:24 #link https://review.openstack.org/#/c/320439/ 15:13:49 for the time, though, we need libosvar's patchset 15:13:56 time being^^^ 15:14:27 mlavalle: makes sense 15:15:00 Those are the only new bugs this week. 15:15:10 there is also https://bugs.launchpad.net/neutron/+bug/1696796 15:15:11 Launchpad bug 1696796 in neutron "No fip connectivity after switch to legacy mode from dvr_snat" [Undecided,Incomplete] 15:15:24 I was about to ask about that 15:15:26 that seems like an invalid config to me 15:15:30 haleyb: yes I saw that and it seems to be an operation error. 15:15:55 i will put a note and close as invalid, can't run a dvr router on a legacy node 15:15:57 The user just changed the agent mode and did not convert the dvr router. 15:16:05 they need to convert first 15:16:10 haleyb: yes 15:16:50 mlavalle: haleyb: This patch is up for review again. #link https://review.openstack.org/#/c/474007/ 15:17:20 This was reverted recently for the error log. This was partially caused by the regression on the snat namespace. 15:17:56 Swami: yes, saw that. Is the error gone? 15:17:59 is that Jenkins failure something you need to fix or just re-check? 15:18:02 Also I found another issue where the check_for_address_scopes were not checking for 'None'. 15:18:25 haleyb: yes I don't see the error anymore in my environment. But I will check again in the gate tests. 15:19:00 mlavalle: That jenkins failure is the one that I will fix, and it is due to the test case failure that I spoke above in combination with ha and dvr. 15:19:12 LOL 15:19:22 tripping ourselves 15:19:36 mlavalle: :) 15:20:39 That's all I have for the DVR bugs, there are still the monitoring bug related to DVR and I have not started my work on it, since I was focussing on the regression. 15:21:01 s/monitoring/metering 15:21:24 Thanks Swami. how did the move go? 15:21:46 All big items have moved. Just some items here and there. 15:21:55 But it was hard after 11 years. 15:21:57 Swami: let me know if you want me to pick-up a patch, there are a few in progress that might need updates and it would be good to get them in 15:22:06 think i had started one and ran into a rebase 15:22:21 haleyb: no problem, I will reach out to you. 15:22:47 ok 15:22:51 moving on 15:23:12 https://bugs.launchpad.net/neutron/+bug/1655567 15:23:13 Launchpad bug 1655567 in neutron "DHCPv6 failures with "address already allocated in subnet" error" [High,In progress] - Assigned to Miguel Lavalle (minsel) 15:23:28 I need to leave now. I will catch up later on the neutron channel. 15:23:47 Swami: Thanks for the update 15:24:06 This bug has a fix proposed: 15:24:15 #link https://review.openstack.org/#/c/469669/ 15:24:46 I think it is good to go, so please review when you have a chance 15:24:56 mlavalle: it looks good to me, but ihar had one question - "is solution working for agentless dhcp drivers?" 15:25:15 haleyb: that question was based on the previous approach 15:25:43 oh, i just never saw an answer, or a +2 from him so was waiting 15:26:08 to skip assigment of auto addr for dhcp ports, on the assumption that the agent was going to assign it 15:26:26 after he made that comment, I had an irc conversation with him 15:26:39 and adopted the current approach 15:27:00 ok, great 15:27:10 namely, if the address has been assigned and it is a DHCP port, assume the agent already took care of it 15:27:20 makes sense? 15:27:31 yes, makes sense 15:28:03 that way we don't run the risk of breaking agentless plugins 15:29:34 Next is a new one https://bugs.launchpad.net/neutron/+bug/1697925 15:29:35 Launchpad bug 1697925 in neutron "as a tenant user not able to create a subnetpool associating with a shared address scope" [High,In progress] - Assigned to Roey Chen (roeyc) 15:29:57 haleyb: have you seen it before? 15:30:30 mlavalle: no, haven't seen it. there's a review up now 15:30:46 I spent time with it this morning 15:31:16 in the bug, it is somewhat suggested that this might be a regresion 15:31:34 that in the past, this was possible 15:32:05 I dug out the original patchset that implemented address scopes, and it is always been like it is today: 15:32:26 #link https://review.openstack.org/#/c/197552/15/neutron/db/db_base_plugin_v2.py@707 15:34:04 so do you consider it a bug? 15:34:20 haleyb: based on this, I want to take this with caution. There may be a good reason we are enforcing this 15:34:33 it seems more a rfe to me as of now 15:35:03 I commented in the bug, but I am not sure it is design decision or a bug. I wonder what is the purpose of 'shared' flag of address scope. 15:35:44 amotoki: yeah I saw you comments. It was implemented like that originally: https://review.openstack.org/#/c/197552/15/neutron/db/db_base_plugin_v2.py@707 15:35:50 based on the concept of address scope, it looks like a valid use case but I might be missing somethign 15:36:26 it seems also to me like a reasonable use case 15:36:46 but the fact that it was implmented like that since the beginning moves me to be cuatious 15:36:55 cautious 15:37:03 me too 15:37:44 it's not that it was possible to do this in a previous release and now we have a regression 15:38:04 it is a new use case. I lean towards treating this as a rfe 15:39:01 agree. perhaps is is a new use case. as you say, it was impossible in the past releases. 15:39:40 I will go through the original patchset and try to glean out from the comments if something was said about this 15:39:56 haleyb: do you have any recollections from this review?^^^ 15:40:51 mlavalle: not down to that level of detail, no 15:41:36 cool, I'll comment in the bug that we are open to discuss this, but that we are going to move with caution given what we just discussed 15:41:47 haleyb, amotoki: is that ok? 15:42:07 mlavalle: agree 15:42:33 mlavalle: i don't believe the current patch removing the check is correct at least 15:42:42 btw, I went through the chapter in the networking guide and it doesn't provides any specific guidance 15:43:02 haleyb: yeah, seems a bit rash 15:43:11 at best we check for shared as well, but like you said, be cautious 15:44:11 amotoki: thanks for your comments 15:45:33 Next one is https://bugs.launchpad.net/neutron/+bug/1683227 15:45:35 Launchpad bug 1683227 in neutron "test_connection_from_same_address_scope failed with: Cannot find device "qg-74372988-7f"" [High,Confirmed] - Assigned to Miguel Lavalle (minsel) 15:46:08 I intended to work on this one, but got distracted by the previous one. I will get back to it 15:47:37 Finally, for today, we have https://bugs.launchpad.net/neutron/+bug/1694764 15:47:38 Launchpad bug 1694764 in neutron "test_metadata_proxy_respawned failed to spawn metadata proxy" [High,Confirmed] 15:47:52 This one has no owner yet 15:48:33 any other bugs we should discuss today? 15:48:55 i had none 15:49:06 ok, moving on 15:49:11 #topic DNS 15:49:46 haleyb: here I want to say that I have finish coding this, including unit tests 15:50:10 I hit a weird python 3.5 unit test failure 15:50:20 the test case passes python 2.7 15:50:28 but if fails in 3.5 15:50:44 so as soon as I fix that, I'll bug you for reviews :-) 15:51:06 do you have a link to it or is this local? 15:51:15 usually it's the other way around, fails on 3.5 15:51:24 yeah, failed in 3.5 15:51:41 oh, i must be dyslexic :) 15:52:17 davidsha_: it is the failure here: https://review.openstack.org/#/c/468697/ 15:52:40 The patchset adds the test case that fails in the 3.5 job 15:53:30 but passes in 2.7, that's weird, was expecting an attribute error or something. 15:53:33 #topic Open Agenda 15:54:06 Just on the reason why there was a lock on tenants earlier: https://review.openstack.org/#/c/197552/3/neutron/db/db_base_plugin_v2.py@743 15:55:07 It seems the spec will be the place to find out. 15:55:45 davidsha_: yeah, I was looking for something like that 15:55:56 Thanks! 15:56:49 davidsha_: I still have to take time to look at your PoC 15:57:01 I will do my best over the next few days :-) 15:57:40 mlavalle: No problem, working on a follow on, there are a few issues with ipv6 so I'll try to have those fixed asap. 15:57:50 cool 15:57:55 any other topics? 15:58:07 the spec mentioned in the comment: https://review.openstack.org/#/c/180267/ 15:58:38 perfect, thanks! 15:58:50 let's call it a day, then 15:58:57 Tnanks for attending 15:59:03 #endmeeting