22:01:46 #startmeeting neutron_drivers 22:01:47 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:50 The meeting name has been set to 'neutron_drivers' 22:02:00 o/ 22:02:03 o 22:02:04 o/ 22:02:07 o/ 22:02:07 / 22:02:13 quack 22:02:14 slow wave, i guess. 22:02:22 hiya 22:02:50 hi 22:03:21 hello everyone! 22:03:33 sorry I am a bit late 22:03:40 let’s dive in! 22:03:43 but before we do 22:04:17 checkpoint before the first milestone 22:04:56 we have a few blueprints targeted for N-1 22:05:01 #link https://launchpad.net/neutron/+milestone/newton-1 22:05:31 if we can get eyes on specs 22:06:34 make sure they are given extensive review! 22:07:05 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z 22:07:56 you guys still with me 22:07:57 ? 22:08:08 yeap 22:08:12 here 22:08:13 indeed 22:08:19 yeah 22:08:21 ok good 22:09:08 sorry, was looking at a spec. 22:09:17 carl_baldwin: that’s a good one! 22:12:45 huh. so we lost armax? :) 22:12:48 armax are you still with us? 22:12:52 he just rejoined 22:12:56 armax_: 22:13:11 what did I miss? 22:13:12 lousy wifi 22:13:12 sorry 22:13:38 Didn't miss anything. We were waiting for you. 22:13:46 good 22:14:20 before we go and dive in the list of triaged bugs 22:15:02 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 I should probably extend the question on the ML 22:15:54 and ask for larger feedback, but I wanted to see if you had any general suggestion/complain/feedback 22:16:21 As usual we have too many things to get done. It might be time to set priorities for Newton? 22:17:25 setting priorities is tricky because people don’t tend to follow them! 22:17:44 nsh in sfc. done. 22:17:44 Everyone's got their own set. 22:17:45 ^ what the gentleman just said :( 22:17:52 yeah, when will I learn? 22:17:56 and it’s down to how well a group of folks work together to get a feature to completion 22:18:27 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 taking into account the existing workload 22:18:52 ihrachys: what do you mean? 22:18:53 ihrachys: i think it is, because if we're not handling maintenance, we should not be adding. 22:19:08 can’t drop a bomb like this and run away :) 22:19:18 armax: recheck is everyone's friend lately. functional, api, tempest, all kinds of failures 22:19:40 functional is the worst a.t.m. 22:19:45 functional is terrible 22:19:50 I am this close to make it non voting again 22:19:51 HenryG: pg-full is 30% rate 22:20:02 but as far as the gate is concerned 22:20:04 http://status.openstack.org//openstack-health/#/ 22:20:16 ihrachys: it is non-voting but I have it on my list of things to fix 22:20:20 the failure rate is at >96% 22:20:37 which is pretty good all things considered 22:21:32 i think you mean success rate. 22:21:43 dougwig: right 22:21:45 sorry 22:21:49 maybe gate, but definitely not check queue. or I am especially lucky. 22:22:18 ihrachys: I don’t see any uncaterogized api failures 22:22:19 http://status.openstack.org/elastic-recheck/data/uncategorized.html 22:22:31 there's a fix for the functional gate issue https://review.openstack.org/#/c/317369/ 22:22:33 ihrachys: check queue biggest offender is functional 22:22:36 for sure 22:22:39 by Jakub, just +1'd by Terry today 22:23:35 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 I don't know if there's anything to generalize or learn here 22:24:17 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 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 it was complicated and took a lot of time 22:26:24 amuller: so how close is it to merging? 22:26:38 armax: the current patchset should be very close 22:27:31 amuller: ok, I’ll keep an eye on it 22:27:58 if I look at grafana 22:28:01 #link http://grafana.openstack.org/dashboard/db/neutron-failure-rate 22:28:28 I have see nothing startling besides pg, and functional 22:28:35 and fullstack 22:28:48 but only functional (in check) is disruptive 22:29:31 ok let’s park this for now 22:29:36 ihrachys: thanks for bringing it up 22:29:54 There does not appear to be any consistency in the PG failures, last time I looked. 22:30:05 bug #1552680 22:30:07 bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] https://launchpad.net/bugs/1552680 - Assigned to John Schwarz (jschwarz) 22:30:09 any update on this one? 22:30:29 not yet I gather 22:30:39 bug #1559978 22:30:41 bug 1559978 in neutron "[RFE] log segmentation_id over threshold for monitoring" [Wishlist,Triaged] https://launchpad.net/bugs/1559978 22:31:05 anyone has had the chance to look into it? 22:31:27 btw I am looking at this list 22:31:31 (crickets) 22:31:33 #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 22:31:38 minus the BGP ones 22:32:30 well, I briefly looked at it, but I guess we need ajo_ to chime in addressing latest comments 22:32:47 ok 22:33:08 bug #1560963 22:33:11 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 is this something the QoS team think is in scope? 22:34:42 I would think so, under certain premises 22:34:53 I think yes, they are discussing it, for egress for now. 22:35:02 ingress is shelved 22:35:15 there is a spec for that RFE 22:35:22 from API perspective, very straightforward 22:35:23 #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe+-l3-bgp+&field.tags_combinator=ALL 22:35:34 ^ Removes BGP ones. 22:36:39 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 :) 22:36:51 are BGP ones waiting for feedback from L3 team? can we mark them as Confirmed until discussions start? 22:37:16 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 Yes, I'll mark them as confirmed for now. 22:37:44 carl_baldwin: ok 22:38:05 ihrachys: ok so let’s iterate on the spec with the assumption that we agree something will have to be done 22:38:17 + 22:38:40 bug #1563879 22:38:41 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 in a nutshell if I a have two neutron networks connected via a dvr router 22:41:27 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 which seems like like a gap 22:43:50 agreed 22:43:59 I agree with armax's comment in the bug. 22:44:39 ok 22:44:44 +1 22:44:55 bug #1577488 22:44:56 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 We discussed a lot yesterday. Did we reach conclusion? 22:46:10 carl_baldwin: we being? 22:46:20 all the people 22:46:21 or you mean last week? 22:46:34 carl_baldwin: all the openstack people? 22:46:40 Yes, last week. 22:46:53 it was our 'go' last week. 22:47:01 it sounds to me that the rfe is invalid 22:47:17 I thought we agreed that a router could do fast exit if it isn't doing SNAT. 22:47:34 but it has unveiled that the ext_gw_mode extension and the address_scope extensions are conflicting 22:48:11 I think that is, at most, a documentation issue. 22:48:13 in other words you can address the RFE’s use case employing address scopes 22:48:34 and in that case toggling the enable_snat flag on the router is ineffective 22:48:37 That's true. 22:49:26 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 Matching address scopes does render enable_snat ineffective. 22:49:58 if that’s the conclusion I’d state that on the RFE bug and mark it invalid 22:50:24 All that's good but it still doesn't get you fast exit from the DVR router without some work. 22:50:50 carl_baldwin: is there anything that doesn’t need work when it comes to DVR? 22:51:18 the other option is to turn this RFE into a regular bug fix 22:51:22 I mean bug report 22:51:51 do you mean DVR needs a work to support NAT mode based address scope? 22:52:27 amotoki: that's effectively what I was thinking this rfe would solve 22:52:57 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 It is a change in behavior from today. Hence RFE. 22:54:35 carl_baldwin: but without address scope though, right? 22:55:17 armax: I'm not following. 22:55:27 carl_baldwin: me neither 22:55:39 Let's take it up later. 22:56:30 ok 22:56:39 we’re nearly at time 22:56:58 how many can make it to the ireland meetup? 22:57:03 I don’t see any activity on bug 1580588 22:57:05 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 armax: I think Miguel is tapped for now. 22:57:42 dougwig: too early to tell, I think people need to check travel budgets etc 22:57:49 dougwig: I need to check on travel 22:58:03 dougwig: ditto, though I have no conflict for that week 22:58:18 armax: How do we put an RFE on the back-burner? 22:58:19 ^^ what he said 22:58:28 armax: Confirmed? 22:59:27 carl_baldwin: which one? 22:59:30 #endmeeting