22:00:09 <armax> #startmeeting neutron_drivers
22:00:10 <openstack> Meeting started Thu Oct 13 22:00:09 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:13 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:37 <kevinbenton> hi
22:00:54 <ihrachys> o/
22:00:55 <armax> carl_baldwin, kevinbenton, amotoki ihrachys
22:00:57 <armax> ping
22:01:19 <armax> ok we almost have a full house
22:01:24 <blogan> o/
22:01:42 <johnsom> Lots of lbaas riff-raff...  haha
22:02:04 <njohnston> o/
22:02:18 <armax> we’re 10 days from the summit
22:02:34 <armax> and about a month from Ocata-1
22:04:07 <armax> not that people wouldn’t know but I figured I’d remind everybody
22:05:14 <armax> today I wanted to take the opportunity given by this hour to talk about
22:05:18 <armax> #link https://review.openstack.org/#/q/status:open+topic:stadium-implosion
22:05:51 <armax> over the past week I started looking at how things are going with the various projects in the lot
22:06:19 <armax> I have had a first pass on every project except bgpvpn and bagpipe
22:06:37 <armax> which I am hoping I’ll be able to process by the end of the week
22:06:54 <armax> what I need from you drivers members
22:06:58 <armax> and non
22:07:05 <armax> to review first and foremost
22:07:09 <armax> #link https://review.openstack.org/#/c/383525/
22:07:29 <armax> make sure you’re happy with the content and the format
22:07:45 <armax> it’s a relatively straightforward list of Yes and No questions
22:08:34 <armax> the set of responses gathered should help us get an idea of the level of maturity and overall quality of a project
22:08:36 <dougwig> since you've done a first pass, what's the gist of the review?  mostly in?  out?
22:08:43 <armax> dougwig: well
22:08:56 <armax> dougwig: the in vs out is something I want to reach out with my fellow drivers
22:09:15 <armax> dougwig: I have a few takeaways I am sharing in a minute
22:09:19 <armax> dougwig: so bear with me
22:09:24 <dougwig> k
22:10:05 <armax> the scorecard should not be seen first and foremost as a mean to spur conversation and allow people to identify gaps
22:10:17 <armax> that might have been overlooked
22:10:28 <HenryG> "should not"?
22:10:33 <armax> sorry
22:10:36 <armax> should be
22:10:48 <armax> I was making sure people were paying attention
22:10:53 <armax> HenryG gets a candy
22:11:12 * armax hands over a virtual candy to HenryG
22:11:16 <armax> :)
22:11:20 * HenryG puts candy in mouth and finds it very sour
22:11:24 <armax> :)
22:11:33 <armax> come on!
22:12:44 <armax> I hope people see these as something that helps improve the quality of the projects
22:13:29 <njohnston> I think it definitely does.
22:13:29 <ihrachys> it actually does, for what I see. though I am puzzled as to why it works.
22:13:44 <armax> that said, in the end we, the PTL, the Neutron drivers need to make a decision on where time and energy is well spent
22:13:53 <armax> when looking at the Stadium as a whole
22:14:21 <ihrachys> I mean, quality should be at the core of the interest of a team. if what in reality is a simple badge is a better motivation to push for quality, I dunno.
22:14:37 <armax> and if on one end the tool is useful to improve quality for the individual project
22:14:40 <HenryG> ihrachys: It gives the projects a checklist, which I guess they didn't have before
22:15:28 <armax> on the other end it’s a tool that is useful for the PTL, and the drivers and the rest of the Neutron community to raise awareness and involvement in projects where one may not necessarily involved on a day to day basis
22:15:45 <armax> I’d love to spend the same amount of time on project X than I spend on Neutron proper
22:15:50 <armax> but I simply know that I can’t
22:15:55 * carl_baldwin wanders in late...
22:16:51 <armax> and I see these regular checkpoints as a way to foster discussion between the various parties invovled in the stadium
22:17:35 <armax> ok, now enough with the talking :)
22:17:44 <armax> any suggestions/comments so far?
22:17:57 <armax> you can throw virtual rotten tomatoes if you want
22:18:17 <ihrachys> having those checkpoints at the start of a cycle makes a lot of sense, assuming projects actually follow the cycle in some way (some don't).
22:18:42 <armax> right, for now I am happy with the scorecard format I produced
22:18:56 <armax> if you guys are happy too, we can make incremental improvements over time
22:18:58 <ihrachys> overall, I feel that the stadium finally gets some technical substance, so + on that
22:19:18 <armax> but for now I’d say if I can get eyes on https://review.openstack.org/#/c/383525/
22:19:23 <armax> so that I can take it out of the way
22:19:36 <armax> I’ll be focussing on the actual assessments going forward
22:20:04 <armax> as for now I am filling the blanks at high level and to the best of my abilities
22:20:48 <armax> I’ll be reaching out to the various subproject liasions to make sure we capture a pitcure as objective and as trustyworthy of reality as possible
22:22:28 <armax> In the ‘final remarks’ section, I’ll will summarize at high level the status of the project and I’ll refrain from making a decision in vs out
22:22:55 <armax> which is something I want to agree in coordination with the drivers team once everyone has had the chance to review the scorecard
22:23:02 <armax> there will be exceptions though
22:23:38 <armax> especially if a project has clear indication of being stale
22:23:53 <armax> or not having chance of survival
22:24:09 <armax> one more thing and that I can answer dougwig’s question
22:24:49 <armax> the same scorecard would be used for projects that may want to be considered for inclusion, i.e. are not part of the governance list for Neutron and they want to be
22:25:09 <armax> ok
22:25:34 <armax> any question/comments so far? Otherwise I’ll start the drum rolls
22:25:55 <dasm> armax: question about latest statement: does it mean, that projects can somehow "bypass" governance and will be included into Neutron Stadium Projects?
22:26:00 <dasm> *last
22:26:20 <armax> clearly not
22:26:35 <armax> dasm: but I am not sure I understand your statement
22:27:08 <armax> what I mean is that if some project foo wants to be part of the governance list for Neutron
22:27:20 <armax> they would need to file an RFE and post a scorecard to the neutron-specs repo
22:27:45 <dasm> armax: yeah. i re-read that. sorry for messing, i've misunderstood it, and thought about openstack governance list, not neutron governance list
22:27:49 <armax> in time for the first milestone of the given cycle
22:28:07 <armax> so say you have project X and want to be part of the Neutron stadium in Ocata
22:28:47 <armax> you have time until Ocata 1 to file and RFE, post a scorecard with all the dots being filled and we, the drivers team, we’ll talk to you and dive into the guts of the projects to see how cool it is
22:29:10 <dasm> armax: ok, makes sense to me.
22:29:46 <armax> spin offs, like have happened in the past, e.g. dynamic routing, would get a free pass so to speak
22:30:14 <armax> but the assessment is at every cycle so if the project being spun off goes downhill
22:30:19 <armax> it can get to be removed
22:30:53 <armax> dougwig: what was your question again?
22:30:59 <armax> how much we suck?
22:31:05 <armax> or how much we rock?
22:31:09 <dougwig> What was your overall feel of the current list?
22:32:00 <armax> overall I noticed that some projects felt the pressure of the stadium and worked hard to cross most items on the checklist
22:32:13 <armax> some others didn’t give a rat’s ass
22:32:22 <armax> so it’s roughly 50/50
22:32:36 <armax> one thing that was consistent throughout the stadium projects
22:32:43 <armax> is that no-one gives a rat’s ass about neutron-lib
22:32:50 <armax> and that’s most likely is our fault
22:32:53 <armax> and we need to fix that
22:33:03 * HenryG sobs
22:33:12 <armax> if we want neutron-lib to be anything other than a repo that holds constants and api-ref
22:33:44 <dougwig> That's easy to fix. Just release the freeze on interface changes in neutron proper.
22:34:06 <armax> I look forward to talking about this in more details in a few weeks time
22:34:13 <ihrachys> armax: the question is, do we steer neutron-lib evolution, or do we necessarily hardlift it ourselves? can we make use of that broader stadium community we claim we have?
22:34:14 <dougwig> I
22:34:16 <armax> but something that ihrachys suggested today during our secret meeting
22:34:56 <armax> is that we can consciously make a decision that neutron-lib is the way forward and we can force projects to break if they do not comply
22:35:10 <armax> ihrachys didn’t exactly suggested that
22:35:30 <armax> but the evil side of me decided to interpret his statement that way
22:35:34 <dougwig> Right. That's what I just said too
22:35:35 * ihrachys sounds tough in your mouth
22:35:46 <armax> dougwig: I don’t listen to you anymore
22:35:51 <armax> dougwig: you’re not a driver
22:35:55 <HenryG> Can we do quicker turn-around on deprecation removals?
22:35:58 <dougwig> lol
22:36:01 <armax> :)
22:36:33 <armax> HenryG: first and foremost I see neutron-lib as the key component to kill the coupling between projects and Neutron
22:36:42 <armax> if we don’t go over the hump
22:36:55 <armax> quick turnaround is not solving the problem
22:37:10 <armax> we need projects to get to 90+% import rate for neutron lib
22:37:40 <armax> if we want to stand a chance for it to be seen as a useful piece of our development and deployment puzzle
22:37:57 <ihrachys> I think we should build neutron-lib, and make stadium projects pay for it
22:38:13 <armax> a toll
22:38:15 <armax> :)
22:38:22 <ihrachys> I mean, make use of their passion to comply with the scorecard ;)
22:38:34 <dasm> but if all deprecated functions/classes will be removed from neutron code, than non compliant projects will be broken, and would need to abide to brand, new world
22:38:45 <dasm> *adjust
22:39:06 <armax> anyhow there’s probably more to talk about this, it’s not a difficult problem but it’s not sexy
22:39:26 <ihrachys> we have a whole session to discuss it
22:39:51 <armax> but we need to crack this nut somehow
22:40:48 <armax> so neutron-lib being largely ignored is one piece of the finding
22:41:09 <armax> the other finding was that we partially  suck at testing
22:41:41 * amuller pretends he didn't hear that
22:41:55 <armax> documentation is patchy and if a project exposes client extensions, they are not turned over to OSC yet
22:42:12 <armax> amuller don’t read that literally
22:42:44 <armax> overall there’s recognition of the fact that we need better CI
22:43:03 <armax> but most projects’ efforts are ineffective at this point
22:43:25 <armax> many projects still primarily and solely rely on unit testing
22:44:08 <armax> and for a system as complex as OpenStack that’s clearly problematic if we want to signal downstream consumers that what we produce is rock solid out of the stadium gate
22:44:54 <armax> for those projects that have no stable tempest like validation in the gate I am going to take a hard line
22:45:05 <armax> regrettably
22:45:26 <armax> they are going to escorted out of the premises
22:45:52 <armax> virtual premises so to speak
22:46:08 <armax> I have been asked on some reviews like https://review.openstack.org/#/c/383904/
22:46:30 <armax> whether there’s a MUST TO-DO list out of the wider list of criteria
22:46:45 <amuller> What is your objective? Is your objective to kick a project out, or to improve its testing? If it's the latter, it would likely be more effective to communicate this requirement to the project team and to give them sufficient time to accomplish that goal
22:47:21 <armax> I have communicated this effectively since last cycle
22:47:23 <armax> I believe
22:47:54 <armax> how long is sufficient, that depends on the project resources
22:48:06 <armax> at one point we need to draw a line
22:48:22 <armax> pushing deadlines over and over and over again is pointless
22:49:11 <ihrachys> I think at this point teams themselves should draw a clear plan forward that could make the PTL to back up a bit.
22:50:08 <armax> I personally feel that so long as one demonstrates that all tasks are actively in progress and make steady steps forward
22:50:26 <armax> then it’s hard to draw a firm line
22:50:50 <armax> but one must have an end in sight
22:50:56 <armax> I have seen things drag on for ages
22:51:00 <armax> and ages
22:51:29 <ihrachys> armax: what was the thinking behind the first deadline and not e.g. second? trying to understand if it's a hard deadline due to some release concerns.
22:51:35 <armax> exclusion does not preclude re-inclusion
22:51:52 <armax> you mean Ocata-1 vs Ocata-2?
22:51:55 <ihrachys> yea
22:52:03 <ihrachys> why -1 in the original spec
22:52:42 <armax> primarily because after Ocata-1 there’s generally less time to look into these types of issues
22:53:04 <armax> as more time gets dedicated on hands-on feature development
22:53:12 <armax> and release matters
22:53:32 <ihrachys> ok, so there is nothing stopping us from ditching a non-complying subproject that committed to complete some gaps till e.g. Ocata-2 but has not done so.
22:54:01 * ihrachys not necessarily saying that anyone should be given a chance
22:54:37 <armax> we also want to make sure we give the TC enough time to digest/discuss
22:55:24 <armax> the related governance patch, so as of today I am giving myself Ocata-1 as the deadline by which I’ll be filing a patch to update the governance list
22:55:28 <njohnston> Yes, if a project is out of the stadium I would assume they would want to pivot and apply for inclusion in the Big Tent, if they have any life in them at all.
22:56:04 <armax> based on any discussion that will happen between now and then during the drivers meeting and/or the scorecard reviews themselves
22:57:39 <armax> any other comment or question, feedback?
22:58:38 <armax> if not, I would love to draw your attention on https://review.openstack.org/#/q/topic:stadium-implosion+status:open
22:59:23 <njohnston> It seems like a fair process overall.  I know I have had to wade into fullstack testing to see how it works under the covers, to introduce it to a subproject.
22:59:24 <armax> the sooner we wrap this up, the sooner we’re gonna go back to doing what we like the most
22:59:29 <HenryG> My neutron-lib patches need reviewers
22:59:33 <HenryG> https://review.openstack.org/337731
22:59:35 <HenryG> https://review.openstack.org/382556
22:59:51 <armax> HenryG: ack
23:00:08 <carl_baldwin> armax: attention drawn
23:00:29 <armax> njohnston: mind you, as pointed out, no project will be kicked out because of lack of fullstack testing
23:00:38 <armax> ok, thanks folks, we’re at time
23:00:40 <armax> #endmeeting