15:00:15 <haleyb> #startmeeting neutron_dvr
15:00:16 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:20 <openstack> The meeting name has been set to 'neutron_dvr'
15:00:20 <haleyb> #chair Swami
15:00:21 <Swami> with time change it is difficult to remember.
15:00:21 <openstack> Current chairs: Swami haleyb
15:01:01 <haleyb> some were automatically moved an hour, some not :-/
15:01:10 <Swami> obondarev: ping
15:01:23 <Swami> haleyb: yes, it is a pain
15:01:33 <obondarev> o/
15:01:47 <haleyb> #topic Announcements
15:02:10 <haleyb> For those not following the neutron channel this morning, seems there is one more patch to land before RC1 is cut
15:02:26 <Swami> haleyb: yes I saw that.
15:03:21 <haleyb> most of the rest of our work here is fixing bugs :( so I'll pass it along
15:03:22 <Swami> haleyb: are we expecting an RC2
15:03:36 <haleyb> Swami: i don't know
15:04:19 <haleyb> 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 <Swami> haleyb: yes the nova side is still out there, I am not sure if it would make it in the Mitaka
15:05:28 <Swami> the bug was downgraded from mitaka-rc-potential recently on nova, so don't know the status at this point.
15:05:54 <haleyb> that's probably not a good sign it will merge
15:06:12 <haleyb> #topic Bugs
15:06:36 <Swami> This week we saw a bunch of bugs land in dvr world
15:06:56 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1557909
15:06:57 <openstack> 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 <Swami> 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 <Swami> This does not cause any SNAT traffic issue, but just a cosmetic issue where the SNAT namespace is still there.
15:10:30 <Swami> The next one in the list is
15:10:34 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1552070
15:10:35 <openstack> 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 <Swami> This seems to be more straight forward for the functional tests not handling the dual stack case.
15:11:36 <Swami> lzklibj is working on it.
15:11:49 <Swami> The next item in the list is.
15:12:03 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1557290
15:12:04 <openstack> Launchpad bug 1557290 in neutron "DVR FIP agent gateway does not pass traffic directed at fixed IP" [Wishlist,Confirmed]
15:12:40 <Swami> 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 <Swami> 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 <haleyb> yes, more of an RFE/enhancement
15:13:52 <Swami> At this point, do we also need to file an RFE for this? What do you think
15:14:58 <haleyb> 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 <Swami> haleyb: agreed
15:15:27 <Swami> The next one in the list is
15:15:30 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1555382
15:15:31 <openstack> Launchpad bug 1555382 in neutron " Queries for DVR-aware floating IP next-hop lookups" [Undecided,Confirmed]
15:15:52 <Swami> This is a documentation bug for the BGP Nexthop queries.
15:16:16 <Swami> 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 <Swami> The next in the list is
15:16:56 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1558046
15:16:57 <openstack> Launchpad bug 1558046 in neutron "DVR functional test fails on devstack" [Undecided,Incomplete]
15:17:23 <Swami> This bug has been triaged as Incomplete since it can't be reproduced. So nothing much to add on it.
15:17:41 <Swami> The next one is
15:17:44 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1558097
15:17:44 <openstack> Launchpad bug 1558097 in neutron "DVR SNAT HA - Documentation for Networking guide" [Undecided,Confirmed]
15:18:16 <Swami> 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 <Swami> That's all with the new bugs.
15:19:10 <Swami> Let us look at the old unresolved bugs.
15:19:48 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1462154
15:19:50 <openstack> 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 <Swami> Currently there are couple of patches to address this same bug from different owners.
15:20:53 <haleyb> regarding the devstack bug 1558046 above, I've seen functional test failures due to bad packages, but continue on
15:20:54 <openstack> bug 1558046 in neutron "DVR functional test fails on devstack" [Undecided,Incomplete] https://launchpad.net/bugs/1558046
15:21:01 <Swami> 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 <Swami> haleyb: got it, thanks.
15:22:11 <Swami> There is currently a discussion in the patch below.
15:22:27 <Swami> #link https://review.openstack.org/#/c/289172/
15:22:58 <haleyb> Swami: yes, this FIP bug has had many patches proposed, I have not caught-up with that patch
15:23:22 <Swami> 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 <Swami> Which does not sound right to me.
15:24:22 <haleyb> 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 <Swami> But I have asked also carl_baldwin to comment on this, since i had a discussion with him regarding this fix.
15:25:26 <Swami> 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 <Swami> This is the behavior we have in DVR.
15:26:31 <obondarev> I guess ssh does not work in this case
15:26:44 <obondarev> and this is a more important bug
15:27:00 <Swami> obondarev: in which case you mean ssh does not work.
15:27:19 <obondarev> when both VMs reside on the same compute node
15:27:30 <obondarev> one with and one without floating ip
15:27:38 <haleyb> 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 <obondarev> not sure, need to check
15:28:17 <Swami> 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 <Swami> 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 <Swami> The next one in the list is
15:30:33 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1541406
15:30:34 <openstack> 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 <haleyb> :(
15:30:49 <Swami> There is a patch out there for review.
15:31:03 <haleyb> there is a parent patch as well that has not merged
15:31:15 <Swami> #link https://review.openstack.org/#/c/277657/
15:31:24 <Swami> haleyb: yes I knew that.
15:31:26 <haleyb> this looks like newton, with backports
15:32:01 <Swami> The next one is
15:32:04 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1445255
15:32:05 <openstack> 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 <Swami> I think haleyb you have already blessed this patch. But I need one more core to take a look at it.
15:33:31 <haleyb> yes, that patch looks good to me
15:35:35 <Swami> haleyb: I saw a mail in upstream yesterday about this patch
15:35:47 <Swami> can it merge for mitaka or is it going to be for newton.
15:36:55 <Swami> The next one in the list is
15:37:01 <haleyb> think it's newton
15:37:29 <Swami> haleyb: thanks
15:37:35 <Swami> The next one in the list is
15:37:41 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1414559
15:37:43 <openstack> 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 <Swami> obondarev: has these patches landed in Mitaka
15:38:07 <obondarev> still on review
15:38:16 <obondarev> gets not much attention
15:38:18 <Swami> obondarev: ok
15:39:07 <Swami> obondarev: let us review it and push it in. Is it delayed on the nova side or neutron side
15:39:22 <obondarev> Swami: both sides
15:39:40 <Swami> obondarev: ok, thanks
15:40:11 <Swami> That's all I had for bugs.
15:40:41 <Swami> haleyb: back to you
15:41:04 <haleyb> thanks Swami
15:41:14 <haleyb> #topic Gate Failures
15:42:09 <haleyb> Things seemed to calm down Monday according to https://goo.gl/L1WODG but multi-node jobs increased today
15:42:37 <Swami> haleyb: yes I saw that.
15:43:33 <haleyb> I don't have an answer, haven't looked into it yet
15:44:09 <Swami> haleyb: do you know what is causing this multi node failure
15:44:19 <obondarev> I saw a couple of timeouts
15:44:28 <obondarev> job timeouts
15:44:42 <Swami> obondarev: ok
15:45:03 <haleyb> obondarev: generic ones not related to neutron?
15:45:42 <obondarev> haleyb: yeah, like not enough time to complete all the tests
15:46:35 <haleyb> so i guess we watch and wait
15:47:03 <Swami> haleyb: ok
15:48:22 <haleyb> 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 <haleyb> #topic Open Discussion
15:48:39 <Swami> haleyb: ok
15:49:06 <haleyb> Anyone have anything else?  Any lurkers? :)
15:49:09 <Swami> I just had a quick question on the live-migration
15:50:05 <Swami> 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 <Swami> What do you guys think. Otherwise it may not move in Nova.
15:50:47 <obondarev> well, actually I think it's not a big deal on nova side
15:51:08 <Swami> obondarev: ok, so you think we can handle just with a bug
15:51:14 <obondarev> it has a framework to wait for neutron events and it should be enough
15:52:00 <obondarev> I think yes, it should be just another place where nova will wait
15:52:30 <obondarev> like in my patch for dropped RARP packets during live migration
15:52:37 <Swami> obondarev: ok I will look into it.
15:53:54 <Swami> that's all I had
15:54:22 <haleyb> ok, let's end it then
15:54:34 <haleyb> #endmeeting