15:01:50 <haleyb> #startmeeting neutron_dvr
15:01:52 <openstack> Meeting started Wed Nov 30 15:01:50 2016 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:55 <openstack> The meeting name has been set to 'neutron_dvr'
15:02:01 <haleyb> #chair Swami
15:02:01 <openstack> Current chairs: Swami haleyb
15:02:09 <haleyb> #topic Announcements
15:02:11 <jschwarz> I have a meeting in 30 minutes so will have to drop after
15:02:35 <Swami> jschwarz: no problem.
15:03:11 <Swami> haleyb: jschwarz: I have been offline for a while now after the summit.
15:03:29 <jschwarz> Swami, we missed you :)
15:03:48 <haleyb> i guess i don't have any real announcements, i'm assuming people have seen the HPE one, but that isn't DVR-specific :)
15:03:48 <Swami> haleyb: jschwarz: bare with me if I have missed any.
15:04:01 <Swami> haleyb: :)
15:04:02 <haleyb> #topic Bugs
15:04:26 * haleyb goes looking for other dvr bugs, thought he saw one the other day
15:05:13 <haleyb> nope, just an l3 bug, Swami it's all yours
15:05:25 <Swami> haleyb: thanks
15:05:36 <jschwarz> haleyb, Swami, am I to understand you guys are back to working on openstack fulltime?
15:06:07 <Swami> jschwarz: hope so
15:06:23 <Swami> The first in the list is #link https://bugs.launchpad.net/neutron/+bug/1644231
15:06:23 <openstack> Launchpad bug 1644231 in neutron "fip router config is not created if the vm ports attached to FIPs have no device_owner" [Low,Triaged] - Assigned to Zhixin Li (lizhixin)
15:06:35 <Swami> This bug seems to have been triaged.
15:07:32 <Swami> I have not personnely test this bug, but will try to look into it since it does not have a patch yet, if it is a valid bug.
15:07:56 <jschwarz> Swami, It's valid - ajo tried to create some "fake machines" without an actual VM
15:08:03 <Swami> haleyb: I see your comments on it.
15:08:07 <jschwarz> so created a port and assigned everything but device_owner
15:08:15 <jschwarz> it took him a while to figure out why it wasn't working
15:08:16 <haleyb> Swami: yes, it might be a doc issue/user error
15:08:38 <Swami> jschwarz: yes, I got it. we expect a device_owner and that's how we provide the dvr service ports.
15:08:52 <Swami> haleyb: I agree it should be documented.
15:09:41 <Swami> The next one in the list is #link https://bugs.launchpad.net/neutron/+bug/1641535
15:09:41 <openstack> Launchpad bug 1641535 in neutron "FIP failed to remove in router's standby node" [High,In progress] - Assigned to Dongcan Ye (hellochosen)
15:10:20 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1644415 This bug seems to be a duplicate of the former one.
15:10:20 <openstack> Launchpad bug 1644415 in neutron "dvr_edge_ha_router disassociates floatingip incompletely" [High,Triaged] - Assigned to Zhixin Li (lizhixin)
15:11:24 <haleyb> jschwarz: and i see you looked at the patch
15:11:47 <haleyb> or i thought you did, guess i just added you to https://review.openstack.org/#/c/404571/
15:12:00 <jschwarz> haleyb, will add it to my queue
15:13:13 <Swami> haleyb: jschwarz: need more triaging to figure out if these are same symptoms or different one.
15:13:51 <Swami> But the former one has a patch up for review. #link https://review.openstack.org/397092
15:14:57 <jschwarz> I remember looking into 397092 a few days past
15:15:00 <Swami> The later one also has a patch up for review.
15:15:04 <jschwarz> it looked reasonable, it looks good to me
15:15:08 <haleyb> Swami: yes, that needs a little thought as the commit message mentions "another solution"
15:15:50 <haleyb> but it looked fine assuming jschwarz is good with it
15:15:52 <Swami> The later one also has a patch up for review. #link  https://review.openstack.org/404571
15:16:09 <jschwarz> haleyb, I'm good, just responded on the patch
15:16:54 <haleyb> jschwarz: thanks!
15:17:18 <Swami> The next in the list are the high priority bugs.
15:17:22 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1631513
15:17:22 <openstack> Launchpad bug 1631513 in neutron "DVR: Fix race conditions when trying to add default gateway for fip gateway port." [Undecided,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:17:52 <Swami> This is work in progress, we did see that there was a gate test failure that is keeping this patch from merging.
15:18:44 <haleyb> Swami: i just added oleg to the review since it needs another +2, i'm not impartial
15:18:50 <Swami> haleyb: has that patch been reverted or merged that was posted my Armando.
15:19:10 <Swami> haleyb::)
15:19:13 <jschwarz> Swami, it was just merged
15:19:28 <jschwarz> sadly, it's a revert of a patch I wrote
15:19:30 <haleyb> Swami: i think the linux bridge fixes are in
15:19:33 <jschwarz> (so I broke the gate)
15:19:39 <Swami> haleyb: ok thanks
15:20:23 <haleyb> jschwarz: some would say that's a bug in the system, surprised jenkins didn't catch it
15:20:52 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1506567
15:20:52 <openstack> Launchpad bug 1506567 in neutron "No information from Neutron Metering agent" [High,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:20:56 <jschwarz> haleyb, "A glitch in the matrix"
15:21:08 <haleyb> deja-vu :)
15:21:36 <Swami> #link https://review.openstack.org/#/c/377108/ - patch up for review. haleyb had reviewed it and need more reviewers.
15:22:41 <Swami> Any questions on this patch or bug. Can we move on.
15:23:11 <haleyb> Swami: i have a couple of your patches to go through again, including that one
15:23:46 <Swami> haleyb: take your time to review the patches, no worries. I keep rebasing and addressing any merge conflicts.
15:24:09 <Swami> The next in the list is
15:24:13 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1571676
15:24:13 <openstack> Launchpad bug 1571676 in neutron "After binding a floating IP to VM, the static route can't work in DVR." [Undecided,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:24:44 <Swami> #link https://review.openstack.org/#/c/308068/ - patch for review.
15:25:48 <Swami> jschwarz: before you leave the meeting, do you have any bugs that you wanted to discuss.
15:26:08 <jschwarz> Swami, only https://bugs.launchpad.net/neutron/+bug/1645716
15:26:08 <openstack> Launchpad bug 1645716 in neutron "Migrating HA routers to Legacy doesn't update interface's device_owner" [High,In progress] - Assigned to John Schwarz (jschwarz)
15:26:25 <jschwarz> it's a L3 HA bug but it was effecting us where trying to migrate from HA to DVR
15:26:31 <jschwarz> the fix is already on the gate queue
15:27:33 <Swami> jschwarz: ok good to know.
15:28:05 <Swami> The next in the list is
15:28:09 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1612804
15:28:09 <openstack> Launchpad bug 1612804 in neutron "test_shelve_instance fails with sshtimeout" [High,Confirmed]
15:28:22 <Swami> This is the gate failure one. Are we seeing this bug still in gate.
15:28:27 <Swami> haleyb: any update.
15:29:20 <haleyb> Swami: i'll look again and update it, didn't see any a couple of weeks ago
15:30:04 <Swami> haleyb: thanks
15:30:09 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1629539
15:30:09 <openstack> Launchpad bug 1629539 in neutron "Broken distributed virtual router w/ lbaas v1" [Undecided,Incomplete]
15:30:40 <Swami> This is an lbaasv1 bug reported in mitaka, I need to triage it in master and see if has issues. Will triage it this week.
15:32:05 <Swami> That's all I have for bugs today.
15:32:14 <jschwarz> Swami, I don't think lbaas v1 is in the master tree
15:32:22 <jschwarz> It has been deprecated and removed a while back
15:32:30 <jschwarz> so you won't be able to reproduce it
15:32:43 <Swami> jschwarz: yes you are right.
15:33:00 <Swami> There are couple of patches for the RFE, that also needs review.
15:33:19 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1577488
15:33:19 <openstack> Launchpad bug 1577488 in neutron "[RFE]"Fast exit" for compute node egress flows when using DVR" [Wishlist,In progress] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:33:26 <jschwarz> so about the RFE
15:33:44 <jschwarz> Swami, when I read it a while back, I seemed to have understood that this basically kills the whole "dvr+ha" idea
15:33:52 <jschwarz> am I correct in understanding this?
15:34:13 <Swami> dvr+ha is only for the dvr_snat node and not for other compute nodes.
15:34:26 <jschwarz> right
15:34:45 <jschwarz> but now if every compute node will have a "fast exit" then why is the dvr_snat node even needed?
15:35:28 <Swami> jschwarz: The dvr_snat node is still required for traffic originating from vms on different address scopes.
15:35:39 <jschwarz> ahh I see
15:35:51 <jschwarz> OK, will make sure to re-read it and look at the patches again :)
15:35:52 <jschwarz> thanks Swami
15:36:07 <Swami> jschwarz: it is tightly coupled with address_scopes. Only if address_scopes match the traffic will be using the fast exit.
15:37:05 <Swami> That's all I had.
15:37:13 <Swami> haleyb: back to you
15:37:50 <haleyb> #topic Gate failures
15:39:13 <haleyb> sorry, shiny things nearby :)
15:39:31 <Swami> haleyb: :)
15:40:00 <haleyb> I can't say dvr has been blocking the gate recently, http://grafana.openstack.org/dashboard/db/neutron-failure-rate
15:41:17 <haleyb> i will put it on my list to propose the job for voting by end of O cycle unless something changes
15:41:22 <Swami> haleyb: that is good.
15:41:34 <Swami> haleyb: agreed
15:42:03 <haleyb> #topic Open discussion
15:42:13 <haleyb> skipping stable as i didn't see anything there
15:42:49 <haleyb> kevin benton has been fixing a lot of the DB code, for example https://review.openstack.org/#/c/399479/
15:42:49 <Swami> haleyb: we need to have a discussion on how to have dvr and unbound port support for FIP.
15:43:09 <haleyb> Swami: ok
15:43:54 <Swami> haleyb: may be we should have a separate timeslot to discuss and brain storm the ideas.
15:43:56 <haleyb> Swami: of you look at that review you'll see others related, good things to know going forward as it will impact backports
15:44:45 <haleyb> basically, he's removing a lot of the DVR overrides, instead having a callback to tweak the DB afterwards
15:45:10 <Swami> haleyb: let me take a look at it today and see if there is any impact for backports.
15:46:10 <haleyb> Swami: there will be.  We're pushing one of jschwarz 's changes in first, since afterwards it will be difficult to backport.
15:46:54 <haleyb> others in the series have merged already btw
15:47:06 <Swami> haleyb: is it possible for us to push the race patch today.
15:48:23 <haleyb> Swami: i added oleg, but will ping him in neutron channel after meeting.  or i'll go down the list of cores until someone relents :)
15:48:53 <Swami> haleyb: thanks that would help. I hope that patch can be backported.
15:49:18 <haleyb> Swami: i didn't have anything else, did you want to talk about unbound FIP ports?
15:50:20 <Swami> haleyb: Right now the only option we have is to poll on the "arp" change and take necessary action.
15:51:00 <haleyb> is there a bug or review, not exactly following
15:51:31 <Swami> haleyb: there is a bug that we have filed for the unbound allowed address pair support with Ocatavia.
15:52:00 <Swami> #link https://bugs.launchpad.net/neutron/+bug/1583694
15:52:00 <openstack> Launchpad bug 1583694 in neutron "[RFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports" [Wishlist,Triaged] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
15:52:09 <haleyb> oh, that bug, right
15:52:38 <Swami> This is the RFE that we filed last cycle, but the approach that we took in implementing the floatingip on the snat_node was not liked by all.
15:53:02 <Swami> So we need to figure out what would be best approach to deal with this issue.
15:54:57 <haleyb> Swami: i can't think of another option, will re-read the bug
15:54:59 <Swami> That's all I had. Take a look at the RFE again and we can brainstorm during the week.
15:55:55 <haleyb> Ok, thanks.
15:56:11 <Swami> haleyb: Think about 'arpwatch', seems to be a good use, where we can register for the IP and mac and if it changes then it would report or update the syslog, we can either tap it and take necessary action to create the floatingip.
15:56:45 <Swami> haleyb: that's all I had.
15:57:11 <haleyb> Swami: yes, i see there's arpwatch and arpalert, haven't used either
15:58:07 <haleyb> anything else?
15:58:34 <Swami> haleyb: no
15:58:54 <haleyb> ok, until next week...
15:58:58 <haleyb> #endmeeting