15:00:15 #startmeeting neutron_dvr 15:00:16 Meeting started Wed Mar 16 15:00:15 2016 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:20 The meeting name has been set to 'neutron_dvr' 15:00:20 #chair Swami 15:00:21 with time change it is difficult to remember. 15:00:21 Current chairs: Swami haleyb 15:01:01 some were automatically moved an hour, some not :-/ 15:01:10 obondarev: ping 15:01:23 haleyb: yes, it is a pain 15:01:33 o/ 15:01:47 #topic Announcements 15:02:10 For those not following the neutron channel this morning, seems there is one more patch to land before RC1 is cut 15:02:26 haleyb: yes I saw that. 15:03:21 most of the rest of our work here is fixing bugs :( so I'll pass it along 15:03:22 haleyb: are we expecting an RC2 15:03:36 Swami: i don't know 15:04:19 Oh, I guess one other announcement is that the neutron side of the live migration work merged, thanks for sticking with it Swami 15:04:54 haleyb: yes the nova side is still out there, I am not sure if it would make it in the Mitaka 15:05:28 the bug was downgraded from mitaka-rc-potential recently on nova, so don't know the status at this point. 15:05:54 that's probably not a good sign it will merge 15:06:12 #topic Bugs 15:06:36 This week we saw a bunch of bugs land in dvr world 15:06:56 #link https://bugs.launchpad.net/neutron/+bug/1557909 15:06:57 Launchpad bug 1557909 in neutron "SNAT namespace is not getting cleared after the manual move of SNAT with dead agent" [Medium,Confirmed] 15:08:27 This issue is not seen in master and only seen in liberty, I need re-confirm this with liberty and then see what might be causing the problem. This happens when the agent dies and there is an snat namespace already in the node. By the time the agent restarts, the snat is moved and the stale SNAT namespace is still in this node. 15:09:28 This does not cause any SNAT traffic issue, but just a cosmetic issue where the SNAT namespace is still there. 15:10:30 The next one in the list is 15:10:34 #link https://bugs.launchpad.net/neutron/+bug/1552070 15:10:35 Launchpad bug 1552070 in neutron "Two functional test method in TestDvrRouter don't work to dual_stack case" [Low,In progress] - Assigned to ZongKai LI (lzklibj) 15:11:22 This seems to be more straight forward for the functional tests not handling the dual stack case. 15:11:36 lzklibj is working on it. 15:11:49 The next item in the list is. 15:12:03 #link https://bugs.launchpad.net/neutron/+bug/1557290 15:12:04 Launchpad bug 1557290 in neutron "DVR FIP agent gateway does not pass traffic directed at fixed IP" [Wishlist,Confirmed] 15:12:40 This is not a bug as such but a requirement by BGP to forward traffic to private IP without using the FIP IP from the fip namespace. 15:13:20 This should be a wishlist item and let see how we can make it to work in newton, otherwise we might have an issue with North-South routing and BGP. 15:13:26 yes, more of an RFE/enhancement 15:13:52 At this point, do we also need to file an RFE for this? What do you think 15:14:58 let's keep as a bug for now, but we'll need something to track "direct routing" for tenant private networks since there is also the IPv6 case 15:15:16 haleyb: agreed 15:15:27 The next one in the list is 15:15:30 #link https://bugs.launchpad.net/neutron/+bug/1555382 15:15:31 Launchpad bug 1555382 in neutron " Queries for DVR-aware floating IP next-hop lookups" [Undecided,Confirmed] 15:15:52 This is a documentation bug for the BGP Nexthop queries. 15:16:16 I will check with tidwellr and see if he has a patch for it. I know that he was working on a patch. 15:16:53 The next in the list is 15:16:56 #link https://bugs.launchpad.net/neutron/+bug/1558046 15:16:57 Launchpad bug 1558046 in neutron "DVR functional test fails on devstack" [Undecided,Incomplete] 15:17:23 This bug has been triaged as Incomplete since it can't be reproduced. So nothing much to add on it. 15:17:41 The next one is 15:17:44 #link https://bugs.launchpad.net/neutron/+bug/1558097 15:17:44 Launchpad bug 1558097 in neutron "DVR SNAT HA - Documentation for Networking guide" [Undecided,Confirmed] 15:18:16 This is again a documentation bug for the DVR SNAT HA. Adolfo is working on a doc patch and will update the bug with that patch. 15:18:25 That's all with the new bugs. 15:19:10 Let us look at the old unresolved bugs. 15:19:48 #link https://bugs.launchpad.net/neutron/+bug/1462154 15:19:50 Launchpad bug 1462154 in neutron "With DVR Pings to floating IPs replied with fixed-ips if VMs are on the same network" [High,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan) 15:20:16 Currently there are couple of patches to address this same bug from different owners. 15:20:53 regarding the devstack bug 1558046 above, I've seen functional test failures due to bad packages, but continue on 15:20:54 bug 1558046 in neutron "DVR functional test fails on devstack" [Undecided,Incomplete] https://launchpad.net/bugs/1558046 15:21:01 We may have to decide the behavior. This use case itself is a corner case were someone is trying to ping a VM on the same network using thier floatingIP. 15:21:37 haleyb: got it, thanks. 15:22:11 There is currently a discussion in the patch below. 15:22:27 #link https://review.openstack.org/#/c/289172/ 15:22:58 Swami: yes, this FIP bug has had many patches proposed, I have not caught-up with that patch 15:23:22 It is claimed that if the VMs reside on the same network, even if we ping with the FloatingIP the traffic should not go out. 15:23:59 Which does not sound right to me. 15:24:22 how can a VM ping with its FIP? it has to be off-fixed-network for NAT to trigger, VM has no control 15:24:22 But I have asked also carl_baldwin to comment on this, since i had a discussion with him regarding this fix. 15:25:26 Yes, if the VM has NAT enabled, should the traffic go out of SNAT gw port and come in on FIP gateway port. 15:25:53 This is the behavior we have in DVR. 15:26:31 I guess ssh does not work in this case 15:26:44 and this is a more important bug 15:27:00 obondarev: in which case you mean ssh does not work. 15:27:19 when both VMs reside on the same compute node 15:27:30 one with and one without floating ip 15:27:38 i think so, even though it doesn't seem optimal it just follows routing. is ssh not working an MTU issue? or? 15:27:59 not sure, need to check 15:28:17 with the patch that i posted above, it seems the ssh is working, since we removed the ip on the 'rfp' interface. 15:29:59 Ok, let us have more discussion on the patch for now and let us move on. This behavior has to be fixed, whichever is the right one. 15:30:30 The next one in the list is 15:30:33 #link https://bugs.launchpad.net/neutron/+bug/1541406 15:30:34 Launchpad bug 1541406 in neutron "IPv6 prefix delegation does not work with DVR" [Medium,In progress] - Assigned to Ritesh Anand (ritesh-anand) 15:30:41 :( 15:30:49 There is a patch out there for review. 15:31:03 there is a parent patch as well that has not merged 15:31:15 #link https://review.openstack.org/#/c/277657/ 15:31:24 haleyb: yes I knew that. 15:31:26 this looks like newton, with backports 15:32:01 The next one is 15:32:04 #link https://bugs.launchpad.net/neutron/+bug/1445255 15:32:05 Launchpad bug 1445255 in neutron "DVR FloatingIP to unbound allowed_address_pairs does not work" [Low,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan) 15:32:53 I think haleyb you have already blessed this patch. But I need one more core to take a look at it. 15:33:31 yes, that patch looks good to me 15:35:35 haleyb: I saw a mail in upstream yesterday about this patch 15:35:47 can it merge for mitaka or is it going to be for newton. 15:36:55 The next one in the list is 15:37:01 think it's newton 15:37:29 haleyb: thanks 15:37:35 The next one in the list is 15:37:41 #link https://bugs.launchpad.net/neutron/+bug/1414559 15:37:43 Launchpad bug 1414559 in neutron "OVS drops RARP packets by QEMU upon live-migration - VM temporarily disconnected" [Medium,In progress] - Assigned to Oleg Bondarev (obondarev) 15:38:00 obondarev: has these patches landed in Mitaka 15:38:07 still on review 15:38:16 gets not much attention 15:38:18 obondarev: ok 15:39:07 obondarev: let us review it and push it in. Is it delayed on the nova side or neutron side 15:39:22 Swami: both sides 15:39:40 obondarev: ok, thanks 15:40:11 That's all I had for bugs. 15:40:41 haleyb: back to you 15:41:04 thanks Swami 15:41:14 #topic Gate Failures 15:42:09 Things seemed to calm down Monday according to https://goo.gl/L1WODG but multi-node jobs increased today 15:42:37 haleyb: yes I saw that. 15:43:33 I don't have an answer, haven't looked into it yet 15:44:09 haleyb: do you know what is causing this multi node failure 15:44:19 I saw a couple of timeouts 15:44:28 job timeouts 15:44:42 obondarev: ok 15:45:03 obondarev: generic ones not related to neutron? 15:45:42 haleyb: yeah, like not enough time to complete all the tests 15:46:35 so i guess we watch and wait 15:47:03 haleyb: ok 15:48:22 and i see grafana doesn't have the multi-node jobs, must only have voting jobs. If i find a failure I'll look into it 15:48:36 #topic Open Discussion 15:48:39 haleyb: ok 15:49:06 Anyone have anything else? Any lurkers? :) 15:49:09 I just had a quick question on the live-migration 15:50:05 We decided that we will add the status notification to nova as a follow up. Since this one requires that the nova should wait for the live migration to happen, probably we should put together a blueprint for nova-neutron communication. 15:50:26 What do you guys think. Otherwise it may not move in Nova. 15:50:47 well, actually I think it's not a big deal on nova side 15:51:08 obondarev: ok, so you think we can handle just with a bug 15:51:14 it has a framework to wait for neutron events and it should be enough 15:52:00 I think yes, it should be just another place where nova will wait 15:52:30 like in my patch for dropped RARP packets during live migration 15:52:37 obondarev: ok I will look into it. 15:53:54 that's all I had 15:54:22 ok, let's end it then 15:54:34 #endmeeting