22:01:46 <armax> #startmeeting neutron_drivers
22:01:47 <openstack> Meeting started Thu May 26 22:01:46 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:50 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:00 <HenryG> o/
22:02:03 <dougwig> o
22:02:04 <carl_baldwin> o/
22:02:07 <boden> o/
22:02:07 <dougwig> /
22:02:13 <ihrachys> quack
22:02:14 <dougwig> slow wave, i guess.
22:02:22 <amuller> hiya
22:02:50 <amotoki> hi
22:03:21 <armax> hello everyone!
22:03:33 <armax> sorry I am a bit late
22:03:40 <armax> let’s dive in!
22:03:43 <armax> but before we do
22:04:17 <armax> checkpoint before the first milestone
22:04:56 <armax> we have a few blueprints targeted for N-1
22:05:01 <armax> #link https://launchpad.net/neutron/+milestone/newton-1
22:05:31 <armax> if we can get eyes on specs
22:06:34 <armax> make sure they are given extensive review!
22:07:05 <armax> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
22:07:56 <armax> you guys still with me
22:07:57 <armax> ?
22:08:08 <ihrachys> yeap
22:08:12 <njohnsto_> here
22:08:13 <HenryG> indeed
22:08:19 <amotoki> yeah
22:08:21 <armax> ok good
22:09:08 <carl_baldwin> sorry, was looking at a spec.
22:09:17 <armax> carl_baldwin: that’s a good one!
22:12:45 <ihrachys> huh. so we lost armax? :)
22:12:48 <HenryG> armax are you still with us?
22:12:52 <amuller> he just rejoined
22:12:56 <amuller> armax_:
22:13:11 <armax_> what did I miss?
22:13:12 <armax_> lousy wifi
22:13:12 <armax_> sorry
22:13:38 <carl_baldwin> Didn't miss anything.  We were waiting for you.
22:13:46 <armax> good
22:14:20 <armax> before we go and dive in the list of triaged bugs
22:15:02 <armax> I also wanted to get a feel from you on how we think we’re doing, and whether there’s ways we can refine the process
22:15:30 <armax> I should probably extend the question on the ML
22:15:54 <armax> and ask for larger feedback, but I wanted to see if you had any general suggestion/complain/feedback
22:16:21 <HenryG> As usual we have too many things to get done. It might be time to set priorities for Newton?
22:17:25 <armax> setting priorities is tricky because people don’t tend to follow them!
22:17:44 <dougwig> nsh in sfc. done.
22:17:44 <carl_baldwin> Everyone's got their own set.
22:17:45 <ihrachys> ^ what the gentleman just said :(
22:17:52 <HenryG> yeah, when will I learn?
22:17:56 <armax> and it’s down to how well a group of folks work together to get a feature to completion
22:18:27 <armax> HenryG: in principle I think we already provide some degree of guidance on what RFEs are accepted and which aren’t
22:18:30 * ihrachys also notes that apart from features, we are not looking good on gate front. but that's maybe not for this forum.
22:18:38 <armax> taking into account the existing workload
22:18:52 <armax> ihrachys: what do you mean?
22:18:53 <dougwig> ihrachys: i think it is, because if we're not handling maintenance, we should not be adding.
22:19:08 <armax> can’t drop a bomb like this and run away :)
22:19:18 <ihrachys> armax: recheck is everyone's friend lately. functional, api, tempest, all kinds of failures
22:19:40 <HenryG> functional is the worst a.t.m.
22:19:45 <armax> functional is terrible
22:19:50 <armax> I am this close to make it non voting again
22:19:51 <ihrachys> HenryG: pg-full is 30% rate
22:20:02 <armax> but as far as the gate is concerned
22:20:04 <armax> http://status.openstack.org//openstack-health/#/
22:20:16 <HenryG> ihrachys: it is non-voting but I have it on my list of things to fix
22:20:20 <armax> the failure rate is at >96%
22:20:37 <armax> which is pretty good all things considered
22:21:32 <dougwig> i think you mean success rate.
22:21:43 <armax> dougwig: right
22:21:45 <armax> sorry
22:21:49 <ihrachys> maybe gate, but definitely not check queue. or I am especially lucky.
22:22:18 <armax> ihrachys: I don’t see any uncaterogized api failures
22:22:19 <armax> http://status.openstack.org/elastic-recheck/data/uncategorized.html
22:22:31 <amuller> there's a fix for the functional gate issue https://review.openstack.org/#/c/317369/
22:22:33 <armax> ihrachys: check queue biggest offender is functional
22:22:36 <armax> for sure
22:22:39 <amuller> by Jakub, just +1'd by Terry today
22:23:35 <armax> the thing with the functional job is that we need to figure out a way to keep it stable, that’s not the first time that it goes wild and it’s tricky to understand why
22:24:15 <amuller> I don't know if there's anything to generalize or learn here
22:24:17 <armax> anyhow, I think we digressed enough but ihrachys that’s a good point, hopefully the weekly checkpoint will continue to keep us in check
22:24:39 <amuller> Jakub worked on it for a few weeks until he found out the root cause, which was a production bug in the ovsdb native code (Not a test only thing)
22:24:44 <amuller> it was complicated and took a lot of time
22:26:24 <armax> amuller: so how close is it to merging?
22:26:38 <amuller> armax: the current patchset should be very close
22:27:31 <armax> amuller: ok, I’ll keep an eye on it
22:27:58 <armax> if I look at grafana
22:28:01 <armax> #link http://grafana.openstack.org/dashboard/db/neutron-failure-rate
22:28:28 <armax> I have see nothing startling besides pg, and functional
22:28:35 <armax> and fullstack
22:28:48 <armax> but only functional (in check) is disruptive
22:29:31 <armax> ok let’s park this for now
22:29:36 <armax> ihrachys: thanks for bringing it up
22:29:54 <HenryG> There does not appear to be any consistency in the PG failures, last time I looked.
22:30:05 <armax> bug #1552680
22:30:07 <openstack> bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] https://launchpad.net/bugs/1552680 - Assigned to John Schwarz (jschwarz)
22:30:09 <armax> any update on this one?
22:30:29 <armax> not yet I gather
22:30:39 <armax> bug #1559978
22:30:41 <openstack> bug 1559978 in neutron "[RFE] log segmentation_id over threshold for monitoring" [Wishlist,Triaged] https://launchpad.net/bugs/1559978
22:31:05 <armax> anyone has had the chance to look into it?
22:31:27 <armax> btw I am looking at this list
22:31:31 <carl_baldwin> (crickets)
22:31:33 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:31:38 <armax> minus the BGP ones
22:32:30 <ihrachys> well, I briefly looked at it, but I guess we need ajo_ to chime in addressing latest comments
22:32:47 <armax> ok
22:33:08 <armax> bug #1560963
22:33:11 <openstack> bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,Triaged] https://launchpad.net/bugs/1560963 - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
22:34:30 <armax> is this something the QoS team think is in scope?
22:34:42 <armax> I would think so, under certain premises
22:34:53 <ihrachys> I think yes, they are discussing it, for egress for now.
22:35:02 <ihrachys> ingress is shelved
22:35:15 <ihrachys> there is a spec for that RFE
22:35:22 <ihrachys> from API perspective, very straightforward
22:35:23 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe+-l3-bgp+&field.tags_combinator=ALL
22:35:34 <carl_baldwin> ^ Removes BGP ones.
22:36:39 <armax> carl_baldwin: nice one, I’d rather see the BGP ones vetted and moved out of the way for real but that’s a start :
22:36:41 <armax> :)
22:36:51 <amotoki> are BGP ones waiting for feedback from L3 team? can we mark them as Confirmed until discussions start?
22:37:16 <carl_baldwin> armax: We're almost there.  tidwellr and I did some prioritization of them yesterday.  Just not sure what to do with the lower priority ones.
22:37:32 <carl_baldwin> Yes, I'll mark them as confirmed for now.
22:37:44 <armax> carl_baldwin: ok
22:38:05 <armax> ihrachys: ok so let’s iterate on the spec with the assumption that we agree something will have to be done
22:38:17 <ihrachys> +
22:38:40 <armax> bug #1563879
22:38:41 <openstack> bug 1563879 in neutron "[RFE] DVR should route packets to Instances behind the L2 Gateway" [Wishlist,Triaged] https://launchpad.net/bugs/1563879
22:40:42 <armax> in a nutshell if I a have two neutron networks connected via a dvr router
22:41:27 <armax> and one of these two networks is the result of a logical segment + an unmanaged segment, the nodes on the unmanaged segments won’t be able to reach out the other network via the DVR routerr
22:41:44 <armax> which seems like like a gap
22:43:50 <carl_baldwin> agreed
22:43:59 <amotoki> I agree with armax's comment in the bug.
22:44:39 <armax> ok
22:44:44 <carl_baldwin> +1
22:44:55 <armax> bug #1577488
22:44:56 <openstack> bug 1577488 in neutron "[RFE]"Fast exit" for compute node egress flows when using DVR" [Wishlist,Triaged] https://launchpad.net/bugs/1577488
22:45:58 <carl_baldwin> We discussed a lot yesterday.  Did we reach conclusion?
22:46:10 <armax> carl_baldwin: we being?
22:46:20 <carl_baldwin> all the people
22:46:21 <armax> or you mean last week?
22:46:34 <armax> carl_baldwin: all the openstack people?
22:46:40 <carl_baldwin> Yes, last week.
22:46:53 <dougwig> it was our 'go' last week.
22:47:01 <armax> it sounds to me that the rfe is invalid
22:47:17 <carl_baldwin> I thought we agreed that a router could do fast exit if it isn't doing SNAT.
22:47:34 <armax> but it has unveiled that the ext_gw_mode extension and the address_scope extensions are conflicting
22:48:11 <carl_baldwin> I think that is, at most, a documentation issue.
22:48:13 <armax> in other words you can address the RFE’s use case employing address scopes
22:48:34 <armax> and in that case toggling the enable_snat flag on the router is ineffective
22:48:37 <carl_baldwin> That's true.
22:49:26 <armax> so we would want to a) document the issue; b) make sure this condition is caught when a dumb user is expecting things to happen when they won’t and raise an error
22:49:27 <carl_baldwin> Matching address scopes does render enable_snat ineffective.
22:49:58 <armax> if that’s the conclusion I’d state that on the RFE bug and mark it invalid
22:50:24 <carl_baldwin> All that's good but it still doesn't get you fast exit from the DVR router without some work.
22:50:50 <armax> carl_baldwin: is there anything that doesn’t need work when it comes to DVR?
22:51:18 <armax> the other option is to turn this RFE into a regular bug fix
22:51:22 <armax> I mean bug report
22:51:51 <amotoki> do you mean DVR needs a work to support NAT mode based address scope?
22:52:27 <tidwellr> amotoki: that's effectively what I was thinking this rfe would solve
22:52:57 <carl_baldwin> DVR sends traffic to the snat namespace when there is no floating IP, even when there is no SNAT.  This rfe is an enhancement to get a fast exit path.  That's not a bug.
22:53:11 <carl_baldwin> It is a change in behavior from today.  Hence RFE.
22:54:35 <armax> carl_baldwin: but without address scope though, right?
22:55:17 <carl_baldwin> armax: I'm not following.
22:55:27 <armax> carl_baldwin: me neither
22:55:39 <carl_baldwin> Let's take it up later.
22:56:30 <armax> ok
22:56:39 <armax> we’re nearly at time
22:56:58 <dougwig> how many can make it to the ireland meetup?
22:57:03 <armax> I don’t see any activity on bug 1580588
22:57:05 <openstack> bug 1580588 in neutron "[RFE] use network's dns_domain to generate dns_assignment" [Wishlist,Triaged] https://launchpad.net/bugs/1580588 - Assigned to Miguel Lavalle (minsel)
22:57:31 <carl_baldwin> armax: I think Miguel is tapped for now.
22:57:42 <amuller> dougwig: too early to tell, I think people need to check travel budgets etc
22:57:49 <carl_baldwin> dougwig: I need to check on travel
22:58:03 <armax> dougwig: ditto, though I have no conflict for that week
22:58:18 <carl_baldwin> armax: How do we put an RFE on the back-burner?
22:58:19 <njohnst__> ^^ what he said
22:58:28 <carl_baldwin> armax: Confirmed?
22:59:27 <armax> carl_baldwin: which one?
22:59:30 <armax> #endmeeting