15:00:45 <haleyb> #startmeeting neutron_dvr
15:00:46 <openstack> Meeting started Wed Apr 19 15:00:45 2017 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:49 <openstack> The meeting name has been set to 'neutron_dvr'
15:00:52 <haleyb> #chair Swami
15:00:53 <openstack> Current chairs: Swami haleyb
15:01:08 <haleyb> #topic Announcements
15:01:38 <haleyb> Summit is fast approaching, May 8th
15:01:54 <Swami> haleyb: yep
15:02:31 <haleyb> Swami: guess we need to get that presentation started :)
15:03:00 <Swami> haleyb: yes I agree, I will put some time this week to start the google slide deck
15:03:30 <Swami> haleyb: totally swamped with internal bugs and fixes.
15:04:17 <haleyb> Swami: yes, same here
15:04:53 <haleyb> #topic Bugs
15:05:06 <Swami> haleyb: thanks
15:05:14 <Swami> This week we had two bugs reported.
15:05:41 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1682228
15:05:42 <openstack> Launchpad bug 1682228 in neutron "can't cross address scopes with DVR " [Undecided,New]
15:06:30 <Swami> I read this bug, but I was not sure about the issue.
15:07:15 <haleyb> Swami: there was a doc review posted that was related, let me find it
15:07:21 <Swami> I thought with the dvr fast_path_exit, even if the fixed_ip resides in a different host, the traffic can reach the fixed ip.
15:07:44 <Swami> haleyb: yes, the bug is pointing to a devref that states the limitation.
15:08:16 <Swami> haleyb: Does it mean should we update the devref or still we have an issue even with the fast-path.
15:09:05 <haleyb> https://review.openstack.org/#/c/289794/ was the doc review, which i think is correct (it merged the other day)
15:10:26 <Swami> haleyb: I don't get it.
15:13:15 <haleyb> i'm re-reading the bug
15:14:37 <Swami> Yes, this docref holds good, without the fast path exit.
15:14:57 <Swami> But with the fast-path-exit patch this may not be true anymore. That is my understanding.
15:15:27 <Swami> Because we now add rules in the fipnamespace based on the private network address and not based on a specific ip.
15:16:52 <haleyb> Swami: right, I was a little trigger happy updating that doc based on the current code, we can revert or update once the patch merges
15:16:53 <Swami> haleyb: I will read it again and see if it makes sense.
15:17:05 <Swami> haleyb: ok thanks.
15:17:28 <Swami> Ok, let us move on.
15:17:38 <haleyb> perhaps even update in that patch
15:18:01 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1682345
15:18:03 <openstack> Launchpad bug 1682345 in neutron "neutron metering agent does not work in DVR mode" [Undecided,Confirmed]
15:18:58 <Swami> I did review this bug, it seems that we might have to make changes to the metering_rpc_agent_api.py to provide the notification to the specific hosts. Right now it does notify all the agents associated with the router.
15:19:39 <Swami> haleyb: since we don't anymore schedule the router to the agents and only notify the agents to start the router in the specific node.
15:20:01 <haleyb> so it should work?  but can be less invasive by notifying just the correct agents?
15:20:04 <Swami> This seems to be a valid bug, based on the information.
15:20:43 <Swami> haleyb: right now what the bug says is it is not getting notified to the compute nodes where the routers are hosted.
15:21:06 <Swami> By default it is getting notified only to the dvr_snat nodes, since they are scheduled.
15:22:30 <haleyb> hmm, i thought this worked based on https://review.openstack.org/#/c/424285/ but could be wrong
15:23:11 <haleyb> but if you see the problem then there's a bug
15:23:32 <Swami> haleyb: Yes this patch fixed the issue of configuring the iptables in the snat namespace and router namespace respectively
15:23:55 <Swami> haleyb: But I am not sure about the notification in case of multinode scenario.
15:24:09 <Swami> haleyb: I will re-examine this.
15:24:26 <Swami> haleyb: But for now I have updated the bug.
15:24:33 <haleyb> ok, thanks
15:24:43 <Swami> That's all I have for bugs today.
15:24:59 <Swami> Do you have any other bugs, if I missed for discussion.
15:25:43 <haleyb> no, i didn't have any others
15:25:49 <Swami> haleyb: before we move on to the next section.
15:25:51 <Swami> #link https://review.openstack.org/#/c/355062/
15:26:13 <Swami> I do see that there is a tempest test that is failing with respect to the dual_slaac
15:26:33 <Swami> I am not sure what is going on there. Do you see similar failures in the gate this week.
15:27:34 <Swami> This is the test that is failing. "test_dualnet_multi_prefix_slaac"
15:27:54 <Swami> This is one of the vulnerable tests for DVR and I thought it was dormant for a while.
15:28:02 <Swami> Not sure what is triggering it again.
15:28:03 <haleyb> Swami: that looks like an ongoing issue we've been chasing, even internally, at least I know we've seen ssh failures before
15:28:33 <Swami> haleyb: yes I agree.
15:29:16 <Swami> that's all I had for bugs this week.
15:29:28 <haleyb> i'll see if i can find the bug, might be in the c-i recheck list
15:31:29 <haleyb> don't see it in http://status.openstack.org/elastic-recheck/ i'll look after meeting
15:32:21 <Swami> haleyb: ok thanks
15:32:57 <haleyb> Swami: this was merged recently to try and diagnose a similar problem, https://review.openstack.org/#/c/453334/
15:33:52 <haleyb> don't know if that will give more info in the console
15:34:01 <Swami> haleyb: ok thanks will take a look at it.
15:34:58 <haleyb> https://review.openstack.org/#/c/454892/ is the other one that's in-progress
15:35:38 <haleyb> but basically, there's not enough debug info to get much further
15:36:22 <Swami> haleyb: Yes the ssh connection timeout is a nightmare and involves multiple projects.
15:38:04 <haleyb> #topic Gate
15:38:24 <haleyb> http://grafana.openstack.org/dashboard/db/neutron-failure-rate
15:38:52 <haleyb> the DVR job in the gate has been fine this week
15:39:14 <haleyb> the check jobs are ok, except for the scenario one
15:39:20 <Swami> haleyb: that is good news.
15:41:29 <haleyb> i mean, we can't expect the check queue to be at 0% anyways, as a bad patch is a failure, but the 90% one is showing something, i will look and see if it's just the test
15:42:33 <Swami> haleyb: thanks for the update.
15:43:29 <haleyb> #topic Stable
15:44:39 <Swami> haleyb: I had a question with respect to backport. Is this one backportable. https://review.openstack.org/#/c/283757/
15:45:02 <Swami> I knew that we had a doc change for this patch and I am not sure if we can do a backport of this patch.
15:47:10 <haleyb> since it's an RFE i would think not, since it could consume more IP addresses for the routers
15:47:18 <haleyb> is someone asking for it?
15:48:42 <Swami> haleyb: just checking with you.
15:49:30 <Swami> I don't think I have any pending stable/backports at this point. There is one, waiting for jenkins to clear up.
15:49:43 <haleyb> the neutron dashboard has a nice link to stable branch reviews, https://docs.openstack.org/developer/neutron/dashboards/index.html
15:49:51 <haleyb> i don't see any DVR ones on the list
15:50:50 <Swami> haleyb: ok
15:51:00 <haleyb> #topic Open Discussion
15:51:20 <haleyb> Anything else?  I had nothing
15:51:43 <Swami> haleyb: Nothing else.
15:52:17 <haleyb> alright, thanks for the updates, we'll get that final fast-exit patch merged soon :)
15:52:30 <Swami> haleyb: ok
15:52:39 <haleyb> #endmeeting