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