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