15:01:51 <haleyb> #startmeeting neutron_dvr
15:01:52 <openstack> Meeting started Wed May 18 15:01:51 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:56 <openstack> The meeting name has been set to 'neutron_dvr'
15:02:27 <haleyb> #topic Announcements
15:03:59 <haleyb> N1 is approaching, but we don't have anything critical to get in besides bug fixes
15:04:12 <Swami> yes that's what I hoped.
15:04:23 <haleyb> #topic Bugs
15:04:25 <Swami> when is N1.
15:04:35 <haleyb> let me look
15:04:56 <Swami> ok.
15:05:32 <haleyb> it was discussed at the networking meeting monday, need to find the link
15:05:44 <haleyb> just a meta-comment on bugs
15:05:54 <Swami> it saw two dates, july 4th and May 30th.
15:06:00 <Swami> I was not sure what was the right one.
15:06:20 <haleyb> it's been a slow week or two getting merges through jenkins, a couple of changes are helping, saw another one today
15:06:43 <Swami> ok let us move on to the bugs.
15:07:11 <Swami> This week we did not have any new bugs. There was one bug that was tagged with l3_dvr_backlog, but was incomplete.
15:07:21 <haleyb> https://review.openstack.org/#/c/318116/ is reverting a keystone change that has caused a lot of failures, so should help
15:08:00 <haleyb> that was the #1 infra issue
15:08:14 <haleyb> Swami: continue, should have had that copy/paste read
15:08:24 <Swami> No not the infra one.
15:09:12 <Swami> There is one bug that has a patch that needs review. https://bugs.launchpad.net/neutron/+bug/1581348
15:09:13 <openstack> Launchpad bug 1581348 in neutron "Can't delete a v4 csnat port when there is a v6 router interface attached" [Medium,In progress] - Assigned to Hong Hui Xiao (xiaohhui)
15:09:37 <Swami> #link https://review.openstack.org/#/c/315926/
15:09:52 <haleyb> yeah, that link was meant to go with my previous comment :)
15:11:20 <Swami> haleyb: did you get a chance to recheck this patch. #link https://review.openstack.org/#/c/300358/
15:13:17 <haleyb> Swami: i did look, and talked to carl_baldwin - i think there's still a window where a race could happen between exists() and ip_lib call
15:13:36 <Swami> are we planning to address it in this patch or as a follow on patch.
15:14:08 <haleyb> i think it would be better to try/except where possible, but let's discuss
15:14:24 <Swami> haleyb: ok thanks
15:16:05 <Swami> There is one more patch that needs to be merged, I think I addressed all comments from Oleg. #link https://review.openstack.org/#/c/300268/17
15:16:07 <haleyb> Swami: there's no de-facto doc that says "always try, and deal with the failure gracefully", but if we can do that here it would remove the race completely.  There are still cases where we have to call netns.exists() of course, and possibly re-create the namespace ?
15:17:57 <Swami> please post your comments on the patch on where you wanted to have it try/catch captured and were not.
15:18:12 <haleyb> ok, will do that
15:19:08 <Swami> thanks
15:20:18 <haleyb> regarding ^^^ i'll look once jenkins is done with it
15:20:28 <Swami> Another thing that I wanted to discuss is the 'allowed_address_pair' and floatingip when the allowed_address_pair is associated to multiple active ports.
15:20:53 <Swami> This patch is still waiting. #link https://review.openstack.org/#/c/304905/
15:21:18 <haleyb> i thought there was an issue with lbaas ?
15:21:32 <Swami> Yes, that is the one that is related to this patch.
15:22:04 <Swami> We need to have some sort of blueprint worked out for this unique use case, since it deviates from the DVR design model.
15:22:40 <haleyb> Right, because it's too slow on fail-over, correct?
15:23:22 <Swami> Yes, also they don't have a model were they can only have ACTIVE and passive logged into the DB that the neutron can take advantage of.
15:24:03 <Swami> This is like, DVR should proactively create routers and floatingip on all the nodes, where they have the allowed_address_pair configured for the VM.
15:24:35 <haleyb> So that sounds like a spec/RFE.  is it something they can do, or falls on us?
15:24:56 <Swami> haleyb: it might be on both sides.
15:25:37 <Swami> The reason is if they have assigned allowed_address_pair for multiple VM on multiple nodes, is it ok for neutron to start routers on all nodes and increase the control plane activity.
15:26:15 <haleyb> Swami: could we alternately put this FIP on the controller as well in this case?  I know that's a regression from DVR
15:26:50 <Swami> haleyb: Yes that is kind of going back to centralized, which we don't want to do, unless required.
15:28:04 <haleyb> i see it as a last resort to solve this particular problem
15:28:06 <Swami> Ok, let me think through it and probably will add an RFE to address this issue.
15:28:46 <haleyb> ok, thanks
15:29:33 <Swami> but, I think irrespective of this issue, we should still pursue the patch shown below, since this would be usefull for people who are configuring allowed_address_pair just for ACTIVE and PASSIVE.
15:29:44 <Swami> #link https://review.openstack.org/#/c/304905/
15:30:35 <haleyb> ok, let me recheck the patch, but think i was fine with it last week
15:30:57 <Swami> haleyb: yes I think I have addressed all your comments on it.
15:31:05 <Swami> that's all I have with respect to bugs.
15:31:13 <haleyb> yes, i think i was just waiting based on our lbaas meeting
15:32:00 <haleyb> #topic Gate failures
15:32:41 <haleyb> As I mentioned earlier, there were some issues out of our control causing Check queue failures
15:32:51 <haleyb> https://review.openstack.org/#/c/318116/ (keystone fernet token issue) was one
15:33:04 <haleyb> There is also an ongoing OVS issue being chased
15:33:19 <Swami> multinode is still not happy
15:34:25 <haleyb> dvr is lower than "regular" :)
15:34:49 <Swami> haleyb: dvr is always opposite to neutron-full.
15:35:09 <haleyb> Swami: have you seen any particular string in failures you've seen?
15:35:51 <Swami> not much. I need to look more closely.
15:36:30 <haleyb> use logstash too, that helped track-down the other failures i saw
15:36:45 <Swami> will do
15:38:05 <haleyb> #topic Stable backports
15:38:54 <haleyb> Swami: i fixed a merge issue in https://review.openstack.org/#/c/314790/ and re-based the other two on-top
15:39:00 <Swami> haleyb: i have a bunch of patches for stable backport.
15:39:26 <Swami> what was the error, I could not figure out the issue.
15:39:27 <haleyb> And I am working on back-porting OVS support for IPv6 endpoints manually
15:39:54 <haleyb> Swami: an iptables NAT addition line got removed, so a few tests were failing
15:40:12 <Swami> haleyb: thanks
15:40:51 <haleyb> Swami: feel free to add me to any other backports you start
15:40:59 <Swami> ok, will do.
15:41:11 <haleyb> I also need to check the backport dashboard and update it
15:41:21 <Swami> Congrats! are you officially the stable core now.
15:42:00 <haleyb> Thanks, it might take a week to fully happen and get the +2
15:42:06 <Swami> ok.
15:43:23 <haleyb> https://etherpad.openstack.org/p/stable-bug-candidates-from-master is the stable bug dashboard btw
15:44:06 <haleyb> #topic Open Discussion
15:44:10 <Swami> ok will add mine to the list
15:44:20 <haleyb> anyone have anything else they want to talk about ?
15:45:02 <Swami> no I don't have any other topics to discuss at this time.
15:45:41 <haleyb> ok, and since noone else seems to be here, i'll end it
15:45:47 <haleyb> #endmeeting