15:00:40 <haleyb> #startmeeting neutron_dvr
15:00:40 <openstack> Meeting started Wed Apr 26 15:00:40 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:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:43 <openstack> The meeting name has been set to 'neutron_dvr'
15:00:48 <haleyb> #chair Swami
15:00:49 <openstack> Current chairs: Swami haleyb
15:01:07 <haleyb> #topic Announcements
15:01:55 <haleyb> Summit is almost here, May 8th
15:02:07 <haleyb> sometimes I think i'm just stating the obvious :)
15:02:14 <Swami> haleyb: I have sent you a link to the presentation slide template.
15:02:23 <Swami> haleyb: did you receive it.
15:02:58 <haleyb> Yes, I got the link, will start working on it since we don't have much time
15:03:15 <haleyb> Swami: are you flying in Sunday?
15:03:31 <Swami> haleyb: yes check on the agenda and see if we need to add any other topic to the agenda. I will try to update the remaining slides based on the agenda.
15:03:55 <haleyb> ok, will do
15:04:16 <Swami> haleyb: I am flying in on Friday and reaching boston on Saturday. I will be spending a day with my relatives in Boston and will reach the hotel on Sunday.
15:05:04 <Swami> haleyb: will you be there for all 4 days.
15:05:38 <haleyb> I plan on driving down Monday morning, might see about Sunday night if I don't have a conflict
15:05:50 <haleyb> will be there until Thursday though
15:06:11 <Swami> haleyb: ok, you mentioned a while ago that you may be there for a couple of days.
15:06:17 <Swami> That's the reason I asked.
15:07:49 <haleyb> yes, i finally did get approval, otherwise might have only spent a couple of days there
15:08:17 <Swami> haleyb: ok good.
15:08:42 <haleyb> let's move on
15:08:47 <haleyb> topic #Bugs
15:09:08 <haleyb> i didn't update the wiki, but think there's just one missing, wasn't new
15:09:15 <Swami> haleyb: thanks
15:09:24 <Swami> Yes I did not see any new bugs this week.
15:09:35 <Swami> Unless I missed something in between.
15:09:39 <haleyb> https://bugs.launchpad.net/neutron/+bug/1682345 is the missing one
15:09:40 <openstack> Launchpad bug 1682345 in neutron "neutron metering agent does not work in DVR mode" [Undecided,Confirmed]
15:10:01 <haleyb> oh, maybe it's there but the title changed so i didn't notice
15:10:02 <Swami> haleyb: Yes I think we discussed about this last week.
15:10:32 <Swami> haleyb: There is one other topic that I wanted to discuss with you regarding the RFE patch that we pushed in.
15:10:38 <Swami> #link https://review.openstack.org/#/c/355062/
15:11:19 <Swami> haleyb: Yes there might be an IPv6 issue with this patch for the fast path exit.
15:11:45 <Swami> We don't have an IPv6 link local address configured for the eth-pair connecting the router and fip namespace.
15:13:05 <Swami> Today we still don't support IPv6 for fip-ns in the compute node. ( I meant the fip agent gateway port does not have an IPv6 address and only has IPv4 address).
15:13:23 <Swami> What do you think will be the right approach.
15:13:52 <Swami> Can we restrict this patch to support only IPv4 traffic and for IPv6 traffic can we still redirect to the SNAT namespace.
15:14:13 <haleyb> i think ignoring IPv6 would be the current option.  I was just looking to see if we always forced IPv4 in the ip_lib calls we made
15:14:37 <haleyb> yes, what you said ^^
15:15:05 <Swami> haleyb: Yes let us ignore the IPv6 for now and probably can add in a patch later when we support IPv6 through the compute nodes.
15:16:29 <Swami> haleyb: sounds good to me. I will make the change to restrict it to IPv4 then.
15:16:46 <haleyb> great, thanks
15:17:05 <Swami> haleyb: Also probably if the interface has dual stack, then we might go with the SNAT redirect.
15:17:26 <Swami> haleyb: if no dual stack and just IPv4, then use the fast path exit.
15:18:17 <haleyb> Swami: so don't just add IPv4 routes for v4 subnets?  none for v6?
15:19:02 <Swami> haleyb: I did not get what you are saying.
15:19:57 <haleyb> i thought you were saying if the interface is v4/v6 send everything to SNAT
15:20:41 <Swami> haleyb: The case were I make a decision to use the fast-path-exit or not is based on the address-scope-match.
15:21:20 <Swami> haleyb: What I should be doing is if the address-scopes-match and if the interface is not a dual-stack then use the fast-path-exit and don't delete the snat-redirect path.
15:23:06 <Swami> haleyb: does that sound ok.
15:24:07 <haleyb> i'm still confused.  when i think dual-stack i think both v4/v6, which would be no fast-path exit?
15:24:38 <Swami> haleyb: yes you are right. When it is dual stack, then no fast-path-exit. I am ok with that.
15:25:05 <haleyb> why can't we just do v4-fast-exit and not v6?
15:25:43 <Swami> haleyb: yes because when I decide to redirect all traffic to the fip-namespace, I make my decision based on the address-scope-match.
15:26:39 <Swami> haleyb: I might have to check if that route rule is only applicable for IPv4 and not for IPv6.
15:27:13 <Swami> haleyb: In that case we should be able to redirect just the IPv6 traffic to the SNAT namespace. Let me check that and will confirm you.
15:27:29 <haleyb> i would think so.  most of the code there is v4-centric although it's not always obvious
15:27:59 <Swami> haleyb: Ok will check and update.
15:28:24 <Swami> haleyb: I don't have anything else to discuss with regards to the bugs.
15:29:29 <haleyb> ok
15:29:53 <haleyb> #topic Gate
15:30:26 * haleyb is waiting for grafana page to refresh
15:32:03 <haleyb> gate queue is clean from a DVR perspective
15:32:12 <Swami> haleyb: nice
15:32:56 <haleyb> DVR jobs in check queue seem low, but only showing from 4/23 backwards, not today for some reason
15:33:34 <haleyb> maybe i clicked the wrong timeframe, waiting for refresh
15:35:12 <haleyb> well, it still seems good :)
15:35:23 <Swami> haleyb: good
15:35:49 <haleyb> one if the non-voting jobs is still high but I haven't had a chance to look into it, dvr-multinode-scenario
15:36:06 <haleyb> but it's been high for a long time, not recent spike
15:37:22 <haleyb> either way, DVR isn't getting in the way
15:37:30 <Swami> haleyb: ok sounds good.
15:37:49 <Swami> haleyb: have you run those scenario jobs locally from tempest.
15:38:12 <Swami> haleyb: I have not run those jobs locally, but just wanted to check is it easy to run those jobs locally.
15:38:30 <haleyb> no i haven't, but it should be possible.
15:38:58 <Swami> haleyb: ok thanks
15:39:12 <haleyb> #topic Stable
15:39:38 <haleyb> I didn't see any DVR patches in the stable review list
15:40:12 <Swami> haleyb: yes you are right.
15:40:22 <haleyb> +1 on that then
15:40:23 <Swami> haleyb: There is one back port patch that is failing jenkins.
15:40:43 <haleyb> Swami: link?
15:40:44 <Swami> #link https://review.openstack.org/#/c/456780/
15:41:40 <haleyb> since it was +A the review dashboard didn't show it
15:42:06 <Swami> haleyb: no problem, I just initiated a recheck and let's see how it goes.
15:42:14 <haleyb> might be best to rebase to master since there were some issues a couple of weeks ago, unless there's an obvious failure
15:42:52 <haleyb> if the recheck fails again let's rebase
15:43:05 <Swami> haleyb: ok will rebase it.
15:43:07 <haleyb> the tools are usually smart about that
15:44:10 <haleyb> #topic Open Discussion
15:44:50 <Swami> haleyb: lately I have been having issues with ubuntu-16-04 and tox requirements. Have you seen any similar issues.
15:45:17 <Swami> Also the tempest installation fails with ubuntu 16-04 and devstack.
15:46:21 <haleyb> I had a problem stacking yesterday, but i haven't tried running tempest on it
15:46:47 <haleyb> my problem was a stale link in /etc/apache2 somewhere, but that's different
15:46:50 <Swami> haleyb: Yes I have seen the issue with tempest for a while and recently removed the tempest from my stack.
15:47:24 <Swami> haleyb: I will check it one more time.
15:47:55 <haleyb> i would first try pulling the latest devstack code and re-stacking.  Does it fail to install when tempest is selected?
15:48:29 <Swami> haleyb: Yes it goes all the way and fails when it tries to configure the tempest. I have seen some issues with flake and tempest related.
15:49:11 <haleyb> mine pulled and installed tempest, but i haven't tried to run any tests with it
15:49:32 <haleyb> i.e. tempest is enabled in local.conf
15:49:35 <Swami> haleyb: ok
15:51:17 <haleyb> ping me if you trip over it again i might be able to help
15:51:24 <Swami> haleyb: ok
15:51:59 <haleyb> guess we're done then
15:52:08 <Swami> haleyb: yes,
15:52:33 <Swami> haleyb: we are done.
15:52:42 <haleyb> #endmeeting