20:00:38 #startmeeting tc 20:00:38 Meeting started Tue Jan 24 20:00:38 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:42 The meeting name has been set to 'tc' 20:00:44 o/ 20:00:54 Hi everyone! 20:00:58 Our agenda for today is at: 20:01:00 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:06 lots to cover so let's get started and go quick 20:01:08 * edleafe hides in plain sight 20:01:10 but I'll have to leave a bit early to pack for my flight home in a few hours 20:01:18 o/ 20:01:42 mtreinish: I'll rearrange the ddschedule to handle the goals first then 20:02:04 #topic 2nd Pike goal 20:02:09 * smcginnis joins edleafe 20:02:10 ttx: thanks 20:02:14 So we need to pick our second Pike goal 20:02:20 o/ 20:02:23 o/ 20:02:23 split out tempest plugins 20:02:27 #link https://review.openstack.org/369749 20:02:29 or deploy-api-in-wsgi 20:02:32 #link https://review.openstack.org/419706 20:02:35 EmilienM: what's the status there ? 20:03:01 ttx: stauts on wsgi goal: 20:03:08 I sent an email to PTLs to give feedback 20:03:16 a very few paid attention :/ 20:03:24 but at least we had positive feedback 20:03:30 could be seen as a good sign 20:03:38 I think I've addressed all comments in the reviews, if not please let me know major concerns 20:03:51 I've seen some thoughts about "focusing on Apache webserver" 20:03:58 do you feel like it's less contentious than the tempest goal ? 20:03:58 reminder: this goal doesn't tell you to deploy Apache 20:04:03 * stevemar sneaks in 20:04:33 the tempest goal currently has negative feedback (not sure if it's negative or just under discussion) 20:04:37 my read on the tempest goal is that there are people unhappy with the way tempest works and not wanting to make any further "progress" in that direction 20:04:38 fwiw, as it is right now, I'd pick this goal over the tempest one 20:04:49 with current infra ptl hat on, neither proposed goal seemed relevant to infra projects so i haven't commented. i bet there are lots of teams in the same boat. both seem like fine goals though 20:05:05 flaper87: +1 20:05:08 fungi ++ (as PTL) 20:05:08 so they resist the goal 20:05:13 I think the 2 goals are good and we want them. Just pick one that has agreement I would say 20:05:17 agree flaper87 20:05:27 dtroyer, fungi: yes, no worries. I'm more concerned about projects that have API service. 20:05:29 This goal is simple enough to pair with the py3.5 goal, it is simple enough for the second round of community goals and it's also extremely valuable (not that the tempest one isn't ) 20:05:31 the wsgi goal has more deployer impact 20:05:43 fine doing lazy progress on the tempest one -- the wsgi goal is more user-visible 20:05:46 and to be honest, people can still make the tempest goal in Pike if they can 20:05:50 and the tempest goal more dev impact 20:05:51 nothing will stop them 20:05:54 EmilienM: yep! 20:06:03 so on the tempest one, my -1 is a technical one, not a directional one 20:06:05 ttx: they don't like how tempest works, but they use it anyway? 20:06:09 what I like with the WSGI goal, is the direct impact on ops 20:06:10 Bases on the concerns with the tempest one, I would like to see a discussion at the PTG on that one first. 20:06:17 EmilienM: it sounds like the Tempest goal needs more consensus-building and pushing one cycle lets it do that 20:06:20 johnthetubaguy: I did link an etherpad with the steps 20:06:23 but I think the wsgi goal seems like bigger impact, and closer to us making progress 20:06:33 mtreinish: yeah, I reviewed that, looked good from what I remember 20:06:34 dtroyer: I agree 20:06:34 mtreinish: that's how I read some of the comments against "branchless tempest" yes 20:07:00 EmilienM : also helps eventually to get to point where we can have one port 20:07:01 Would the proposed WSGI goal include those services needing to be deployed into the shared devstack apache setup? Or would this just be documenting + providing configs to run an api service under wsgi? 20:07:05 ttx: right, but that's something which won't ever change in tempest (it's been that way for years) 20:07:06 maybe we can finish the tempest goal during PTG and early pike, and start preparing it during Pike to achieve it in Queen? 20:07:13 * JayF just found the link, will RTFM 20:07:18 dims: ++ 20:07:19 we're also working on baking that into the api stability requirements 20:07:21 * sigmavirus apologizes for tardiness 20:07:26 JayF : it includes updating devstack 20:07:34 mtreinish: nor something we'd want to change. Means we might need to do some education before having it as goal 20:07:40 ttx: ++ 20:07:42 JayF: I read it as making the deployment possible, not requiring it be implemented in DevStack 20:07:47 JayF: yes, testing is the key point here 20:07:53 dtroyer : it needs to be testable. 20:07:56 ttx ++ 20:07:58 dtroyer: it's the second point I think 20:08:09 if a project has multiple individual components, will each part be deployed with mod_wsgi or is it just the user-facing part? 20:08:11 dhellmann: right, I suppose I'm thinking as the default 20:08:12 dtroyer: in "Completion Criteria" 20:08:31 notmyname: I read it as just the HTTP APIs 20:08:35 mtreinish: pretty sure that if the same people went through the same issues we went through they would see it the same way we do 20:08:42 dtroyer : it currently says to switch to using WSGI in Apache, until/unless devstack changes the container service it uses 20:08:52 * dtroyer sighs, makes note to re-read things before writing, like many databases 20:08:53 so it's targeting the state of what we have for tools, but allowing changes 20:09:14 exactly 20:09:16 johnthetubaguy: my understanding too 20:09:21 notmyname : control-plane APIs 20:09:23 ttx: I'm not convinced of that, because I've seen the same objections from the same people repeatedly over the last year or so 20:09:28 if people want nginx in devstack, this is out of scope now 20:09:52 dhellmann: which could completely exclude swift, based on some previous TC discussions. or not. IDK 20:10:10 notmyname: you already run under wsgi, no ? 20:10:12 notmyname : I think EmilienM and I assumed swift was mostly data plane 20:10:20 ttx: but not apache? 20:10:36 JayF: please do not consider my list of projects as accurate 20:10:44 I guess the proxy is considered control plane, am i right ? 20:10:47 JayF: I did it very quickly and I'm happy to fix it in another patch 20:10:52 dhellmann: I think the latest draft doesn't mandate apache, only wsgi 20:10:59 That said, I'd agree that this is mostly targeting control-plane APIs 20:11:04 s/mostly// 20:11:14 EmilienM: it's not a big deal, just wanted to make sure you knew it wasn't true for Ironic. I filed the still-open bug about it :P 20:11:16 ttx: draft 8 says apache on line 32 20:11:28 dhellmann: for testing iirc 20:11:28 JayF: ok:) 20:11:30 * ttx looks 20:11:36 ttx: yes, right 20:11:47 ttx: yes. and we've got docs for running under mod_wsgi (and it seems like there's som devstack support for that already built in). but we use some dusty corners of http that we don't have access to under mod_wsgi. so we'd have to keep the storage nodes running under eventlet's wsgi server. running the proxy under mod_wsgi should work (although I know of zero prod examples of this) 20:12:11 notmyname: I think that's fair game 20:12:14 meaning that you can't "just use apache" for all of swift. 20:12:28 notmyname: I agree with ttx 20:12:42 notmyname : I think that's a reasonable response to the goal for the swift team. Doing that then documents it for anyone asking similar questions in the future. 20:12:49 the goal targets API for now 20:13:24 JayF: I'll fix the list in a top-patch 20:13:39 OK, I think we should select that goal. Doesn't mean we can't refine/adjust between now and PTG 20:13:52 what do you think ? 20:13:57 ttx: ++ 20:14:00 ttx: yes, it seems we have a concensus here 20:14:00 +1 20:14:02 +1 20:14:04 +1 20:14:04 I just don't want anyone to be surprised when some of the wsgi apps in swift (the storage servers) cannot be run under apache/mod_wsgi at all. specifically, crypto and erasure codes will not work 20:14:23 notmyname: that won't be the case, we target Rest API services now 20:14:27 * flaper87 is sold on this goal 20:14:30 ttx: could have a vote, but i'm in favor of the mod_wsgi one 20:14:33 notmyname: ack 20:14:53 ok, please RollCall-Vote+1 on wsgi if in favor 20:15:03 notmyname : it's fine, really. like I said, we assumed there would be issues with some of the services, and specifically considered swift a likely case of "you don't want to do it that way". So when the time comes, just document that in the goal as the response. 20:15:18 zaqar also came up as a potentially bad fit, fwiw 20:15:49 dhellmann: it's another data-plane service 20:15:52 right 20:16:19 Still missing a couple votes to pass 20:16:20 remember, the point of these goals is not just to get everyone to do something, but to document our edge cases when we can't/shouldn't do something 20:16:55 * sigmavirus wonders how this would affect glance 20:16:58 dhellmann +1 20:17:01 yeah, zaqar is not considered a control-plane service but its api uses wsgi 20:17:15 since day 1 it's been recommended to use either apache or nginx 20:17:17 sigmavirus : glance also came up as a possibly bad fit, but we'll leave it up to the glance team to decide 20:17:20 Alright, let's close it 20:17:28 so, despite being a different tipe of service it's still a good fit for the goal 20:17:36 flaper87 : good to know, thanks 20:17:38 dhellmann: right, I'm not sure either way =P 20:17:41 * flaper87 thinks glance should do wsgi too 20:17:50 * flaper87 tried to do this like 3 or 4 cycles ago 20:17:52 sigmavirus : I predict a discussion on this topic at the PTG :-) 20:17:59 ttx: so what is the next step for that tempest goal then? 20:18:01 flaper87: definitely should be 20:18:03 good, now we have 2 goals for Pike, thanks folks! 20:18:12 ttx: i'll work with PTLs for the next steps 20:18:13 EmilienM: thank you 20:18:27 mtreinish: I think I would work on convincing people so that we can make it a Queens goal 20:18:32 dhellmann: I'm sure it will be :) 20:18:33 and I volunteer to be liaison on $topic and give updates on ml + tc meeting when needed 20:18:35 and/or work on it project per project 20:18:57 I few more examples of the tempest lib conversion landing before the end of pike would surely help things along 20:19:06 s/I/A/ 20:19:10 mtreinish: we need to make sure we have a session about your goal at PTG, so we can make good progress and make sure we have it in Queen 20:19:12 ttx: with the exectption of those 3 -1s (which are really just people who don't understand the framework) everyone else is onboard 20:19:38 mtreinish: it might be the first goal to be completed without being a goal 20:19:44 mtreinish: should we encourage some projects to do their share and then handle the leftovers as a goal for Q ? 20:20:06 johnthetubaguy: yeah, I'll get jroll to finish his work on that and get the ball rolling 20:20:07 mtreinish : if you have projects who don't understand the major testing framework within the community, that sounds like we need more education 20:20:16 dhellmann++ 20:20:22 in the mean time we can educate the vocal minority 20:20:27 what dhellmann said 20:20:33 It's been an issue for a long time. 20:20:34 mtreinish : so I consider this a good outcome, for exposing that need 20:20:50 seems like the goal process is helping pull these problems out of the weeds, which is awesome 20:21:02 and yes, it's not as if that prevented anyone from working on it 20:21:16 ttx : right 20:21:18 let's move on 20:21:20 that's true, and it's not like it's hard to implement either 20:21:25 right, this is very similar to what happened with python3 last time; we uncovered a need to do more prep work 20:21:35 mtreinish: there's someone (slowly) working on it, should get done early pike 20:21:35 #topic Team diversity update 20:21:40 A few things to cover in that topic... 20:21:44 First we have two proposed fixes for the diversity script 20:21:47 #link https://review.openstack.org/422305 20:21:58 I'll approve this one now unless there is a late objection 20:22:03 ship it 20:22:07 #link https://review.openstack.org/422312 20:22:15 Since it is correct and we have a standing patch chain I'd rather approve this one and improve it after 20:22:40 One more vote and I'll bypass flaper87 20:22:45 yeah, lemme change my vote 20:22:55 With those in, the resulting tag updates are proposed at: 20:22:57 #link https://review.openstack.org/421286 20:23:05 * dhellmann is glad to have a bunch of other folks willing to review that code 20:23:34 Any objection to those tag updates ? 20:23:43 s.h.i.p i.t 20:23:47 nope, ship it 20:24:02 A comment by Gordon and Emilien on that review pointed to things so inactive the stats don't mean that much 20:24:09 (no objection but I wanted to highlight what gordc said, some project look to be quite inactive over the last months, e.g. Solum) 20:24:11 So I'd like to take a moment to discuss dead / low-activity teams, and what to do with them 20:24:17 ttx: same time :) 20:24:17 Especially when those teams are not really central to fulfilling the OpenStack mission 20:24:21 #topic Discuss dead / low-activity teams 20:24:27 The first one going nowhere this cycle is Solum 20:24:32 http://git.openstack.org/cgit/openstack/solum/log/ shows that most commits there are general typo / maintenance stuff 20:24:40 I have some stats on projects that did work but haven't done releases this cycle 20:24:41 and most ~= all 20:24:47 Could not find a single bugfix or feature 20:24:48 * amrith sneaks in 20:25:16 Solum was always stretching a bit what we call "infrastructure" 20:25:26 http://paste.openstack.org/show/596147/ are the changes in solum since their last release 20:25:32 * flaper87 clicks 20:25:42 #link http://paste.openstack.org/show/596147/ are the changes in solum since their last release 20:25:59 I was fine with the experiment of stretching the goal posts a bit... but if it's not moving and not deployed... why continue 20:26:01 we should reach Solum PTL and ask what's up 20:26:04 dhellmann: it clearly hasn't had much love in a while 20:26:24 EmilienM: yes indeed 20:26:25 Is there such a thing as stability or maturing in a project? 20:26:26 stevemar : they're landing patches, but it looks like mostly requirements and devstack updates 20:26:33 yah 20:26:37 i think he may be asleep right now.. 20:26:38 cdent: yes, some projects mature 20:26:43 and I believe this is a recurring issue in the solum team 20:26:52 IIRC we also had a review like this one last cycle 20:26:55 cdent: but this one never really reached a point where it's used 20:26:57 for solum, that is 20:27:00 * cdent nods 20:27:00 fwiw, solum has no ptl candidate proposed yet for pike 20:27:06 lets propose a patch to remove it from projects.yaml and discuss it from there? 20:27:10 fungi : right 20:27:11 fwiw, my last act as release management ptl for this cycle will be to encourage the tc to drop projects that don't release 20:27:17 mtreinish : ++ 20:27:19 mtreinish: I think we need to discuss before 20:27:21 yes, was just testing the waters before starting anything 20:27:29 dhellmann : ++ 20:27:33 The second one without much happening is the AppCatalog (although Murano is still alive) 20:27:38 For the appcatalog I'll run a more thorough stakeholder analysis 20:27:39 dhellmann: ++ 20:27:45 but I feel like if we can't do a stellar job at it, it can't compete with other more popular application marketplaces 20:27:48 I currently have 19 teams with unreleased changes in their deliverables, though we'll see what happens by the end of the cycle 20:27:54 makes us look bad and competitive for no reason 20:28:03 dhellmann: did you send a warning? 20:28:14 So I'll reach out to AppCat folks and check their long-term strategy 20:28:18 EmilienM : I will 20:28:19 dhellmann : paste later please? (after the meeting) 20:28:20 * EmilienM in favor of peaceful discussion before pro-active reactions 20:28:26 #action ttx to reach out to AppCatalog stakeholders on long-term strategy there 20:28:40 EmilienM : we had discussions with a few teams at the end of last cycle, too 20:28:42 i know they had some ongoing work to switch the app catalog to using a standalone glare instance backend, but other than that i've not seen much out of them on the infra end 20:28:48 anyone taking the solum action ? 20:28:52 EmilienM : i would not want to keep poking people to make releases... 20:28:58 should we have individual discusions or collective? 20:29:10 Any other project that appears dead at this point ? 20:29:12 dims: yeah I know 20:29:25 but yeah, as dims says, the point of all the work I've been doing is to get teams to stand on their own for releases so the release managers don't have to keep begging them to cut releases 20:29:31 ttx : i can take that action (solum) 20:29:54 #action dims to reach out to Solum to see if it's going anywhere 20:30:05 as usual, i expect we'll see at least a handful with no ptl proposed come sunday and can have some related discussions after that 20:30:23 fungi: sounds like a good plan 20:30:30 agree fungi 20:30:39 anything else on that topic ? 20:30:52 gordc: thx for bringing it up 20:31:10 sure. blame me :P 20:31:12 ok, moving on 20:31:14 #topic Disallow downtime of controlled resources during upgrades 20:31:18 is dolphm around ? 20:31:24 #link https://review.openstack.org/404361 20:31:35 Not much progress there since Jan 4. 20:32:12 feels like this needs more work before being approvable 20:32:24 skip until there is some movement in it ? 20:32:53 was this on the list to clear out a backlog item? 20:32:58 s/list/agenda/ 20:33:20 no it was put on the list because we skipped it twice and I was hoping we could determine what the next step is 20:33:24 ah 20:33:33 but hard to do without the proposer :) 20:33:36 should I reach out to dolphm about that around my comments 20:33:41 I can take that action 20:33:45 johnthetubaguy: that would be great yes 20:33:59 #action johnthetubaguy to reach out to dolphm re: https://review.openstack.org/404361 progress 20:34:09 which brings us to our next topic 20:34:14 #topic Review of stale changes 20:34:28 There are a number of stale old changes opened against openstack/governance 20:34:33 I think we should only keep open changes that are ready to be considered by the TC 20:34:48 * Add minimal cold upgrade tag for Zaqar (https://review.openstack.org/333099) 20:34:58 Zaqar is missing a grenade job in the gate, so probably this should be abandoned until that's added 20:35:18 ttx: yes, Zaqar is not ready imho to have this tag 20:35:26 * Add the vulnerability:managed tag to Manila (https://review.openstack.org/350597) 20:35:32 Open since last August, Manila needs to complete a threat analysis. I propose we abandon it until that's completed 20:35:41 unless fungi has some recent progress on that to report 20:35:45 ++ 20:36:02 none that's been brought to my attention 20:36:03 * Add puppet module for docker registry to infra (https://review.openstack.org/399181) 20:36:08 I'll also abandon this one, based on fungi's comment 20:36:20 * Equal Integration Chances for all Projects (https://review.openstack.org/342366) 20:36:25 Open since last July... 20:36:30 We said before that it's easier to handle those conflicts one by one rather than try to create magic legislation that would avoid them 20:36:30 ttx: just abandoned it 20:36:34 thanks ttx, due to the acls on the governance repo you and teh proposer are the only ones who can abandon anything i think 20:36:35 ttx: I'll follow up on that, but abandoning is fine w/ me 20:36:42 totally forfot it was still open 20:36:47 as it's extra hard to find wording that catches all cases 20:37:12 bswartz: note that you can easily "restore" it when ready 20:37:29 just makes it easier for TC members to know what they should be actively reviewing 20:37:39 mugsie: thanks 20:37:46 there is a vulnerability:managed application for barbican which looks really close, but is held back on a technical issue with the governance change 20:38:04 seems like no one knows what to do about https://review.openstack.org/#/c/421070/1 :) 20:38:04 yes I think I kept that one in the backlog 20:38:05 oh, looks like it just got fixed 20:38:10 ttx: done 20:38:19 stevemar: indeed 20:38:29 stevemar: very complex problem 20:38:35 #topic License for openstack/governance 20:38:44 A bot proposed a LICENSE file for this repo 20:38:46 ttx: also ptl +1'ed https://review.openstack.org/#/c/420713/ 20:38:50 oops 20:39:00 #link https://review.openstack.org/#/c/421070/1 20:39:04 any opinion on that ? 20:39:10 ttx: I don't think we need that patch. 20:39:26 does the bot take constructive criticism well? 20:39:29 we don't release any of the software in that repo, and the scripts all have the header 20:39:31 as you said dhellmann ttx, this is bot based and I'd say abandon it. 20:39:32 https://review.openstack.org/#/q/topic:add_LICENSE_file 20:39:40 * mtreinish disappears 20:39:43 this bot is a human fungi and may take criticism 20:39:47 I mean, we have codeAlrightn abandon 20:39:56 lulwat 20:40:04 dhellmann: yep -- any code has a licence at the top 20:40:06 I'm fine with abandoning that 20:40:08 no deliverables, abandon 20:40:35 #topic Open discussion 20:40:40 Have a few topics 20:40:43 also the LICENSE file isn't actually needed for apache license 2.0 afaik 20:40:46 * Skip next week meeting ? 20:40:51 Next week I'll be away for a Foundation offsite, same for fungi and thingee 20:40:58 Should we skip the meeting ? If not who would like to run it ? 20:41:11 I may be traveling, too 20:41:17 next week will be all hands-on deck for most project teams i imagine 20:41:28 yeah, with rc1 next thurs 20:41:44 yes, busy 4-week pre-release period in Ocata 20:41:46 I can run it if nobody else volunteers 20:42:04 who from TC thinks to be around? 20:42:07 o/ 20:42:09 I'll propose skipping it if nothing uregnt comes up 20:42:24 (later this week) 20:42:45 #action ttx to propose next week meeting skip later this week if nothing urgent comes up 20:43:02 then we can find a volunteer to run it if we have something urgent to cover :) 20:43:10 * TC+Board meeting date/meeting 20:43:16 vote still open @ https://framadate.org/bK8ziU1mhzjThdih 20:43:17 ttx: if it's the case, i'll run it 20:43:24 I added on e option recently 20:43:35 #info EmilienM volunteers to run the meeting in case we need one 20:43:40 FWIW, I can run the meeting if needed 20:43:42 so you may want to revisit it 20:43:54 #info flaper87 also volunteers to run the meeting in case we need one 20:44:04 Expect a decision on that meeting soon after the Board meeting today 20:44:07 ttx: nice, e option works for me :) 20:44:45 trying desperately to tie it to another of my US travels 20:44:56 ttx: same as stevemar 20:45:10 because frankly I'm reaching Monty levels this next months 20:45:34 * Driver teams / discoverability status 20:45:41 Couple of weeks ago we paused the discussion on driver teams, waiting for some progress on discoverability 20:45:45 is thingee around ? 20:46:14 wanted to set a next step 20:46:20 Should we plan to discuss that at some point at the PTG ? earlier ? 20:47:11 mildly concerned that neutron also wants to bow out of even providing guidance as to which drivers we should list in the marketplace 20:47:25 or at least that has been the sentiment of a couple of prominent contributors anyway 20:47:42 fungi : I'm not sure we should leave it up to teams to say which to "include" vs. which they "support" 20:47:48 i just replied to that thread attempting to find out who they think would be better suited to weigh in on drivers 20:48:07 i certainly wouldn't want the tc deciding what drivers work 20:48:23 maybe a working group of operators? 20:48:27 ++ fungi 20:48:53 fungi : "is available", "works", and "is supported" are 3 different things 20:49:00 it's tricky, not sure how that would work 20:49:01 dhellmann: ++ that’s what i was about to try to say = ) 20:49:27 also "is supported upstream" is different from "is supported by the vendor" or even "is supported downstream (not by vendor)" 20:50:01 I propose that the criteria for inclusion in the marketplace be that their code is hosted on our git server 20:50:07 at least for other teams, some of us were hoping they'd start to curate (or continue providing) a feature matrix of drivers 20:50:19 and i think the weakness in discoverability up to now is we’ve gotten stuck on trying to come up with an answer for “supported” and “works” when projects handle those concepts differently 20:50:21 and that all of those other characteristics be listed separately 20:50:46 jbryce : it sounds like you're asking the tc to help standardize those definitions 20:50:54 i don't see why they'd need to take advantage of our hosting just to provide a driver 20:51:11 fungi : that's fair, I was just proposing an objective criteria for inclusion 20:51:20 i can completely understand some companies wanting to publish the source code/releases for their drivers from their own sites 20:51:22 I could also live with them providing minimal contact info 20:51:43 I do not think project teams need to get involved in the inclusion question, though 20:51:44 dhellmann: no. i actually think “is available” is the more important piece of info that most consumers are looking for 20:52:07 jbryce : interesting, ok 20:52:07 yeah, don't want driver teams to be compelled to post code under our infrastructure just to be listed in the marketplace 20:52:26 right, i'd be thrilled if service teams just maintained lists of what drivers were available. that needs some sort of minimal gatekeeper familiar with how to vet the claim anyway 20:53:02 Interesting I would think that a service team has done their job best when drivers can exist and be good when the service team is completely unaware of them. 20:53:27 fungi : if we want to include things that live outside of our infrastructure entirely, then I don't think it's fair to ask the contributors to the projects to keep up with that list. Those drivers seem like a part of the broader foundation mission, at that point. 20:54:21 yes, it's more a referencing exercise at that point 20:54:27 in that case i expect we'll just end up with a submission form that sticks these in a database backend and hope the authors of those drivers keep up with them 20:54:28 if we make the market place list centralized and let anyone propose additions or edits, then if community members are interested they can help with reviews, but I think the foundation should probably "own" the repo 20:54:48 fungi : or what you said, if that's simpler 20:55:10 using git at least makes the crowdsourcing a little more consistent with our other things 20:55:13 so abandoning the earlier idea of relying on the driver feature matrices some services are currently maintaining? 20:55:36 that might be throwing the baby with the bath water 20:55:38 fungi: i think the ideal might be a hybrid 20:55:44 do any project teams maintain a feature matrix that includes out of tree drivers? 20:55:48 those could be a starting point, but I don't think we're going to get consistent info from all teams if we don't centralize this 20:55:54 designate did 20:56:00 I think it's fairly clear that in-tree drivers are supported, and they're easy to find 20:56:01 I still think there is value in having a list of tested or 3rd-party-tested drivers 20:56:02 the driver got deleted though 20:56:04 mugsie: did or does? 20:56:05 ah 20:56:13 for projects happy with maintaining that 20:56:16 but our matrix supports external locations 20:56:23 a “crowdsourced” list that is the superset of “is available” and then do some merging with the project maintained data to add in the concepts of supported/tested/in tree/last tested 20:56:46 jbryce: and "open source" :) 20:56:49 ttx: right, that's why I thought a git repo where project teams who want to help expose that info could do so with normal commits or even bots 20:57:12 this is just a collection of yaml files, right? 20:57:22 it's always just a collection of yaml files 20:57:23 well, right now there's the driverlog repo where that was ostensibly being maintained by any teams who wanted to propose changes 20:57:47 fungi : and I guess from your phrasing that participation levels were low 20:57:50 concern was raised that centralized maintenance like that wasn't as valuable as lists maintained by each team 20:58:08 we have https://git.openstack.org/cgit/openstack/designate/tree/doc/source/support-matrix.ini 20:58:15 which says to me that if we split this out into other repos, it will be equally out of date, but if we say "dear foundation staff, please maintain this list" then there is someone assigned to do it 20:58:20 that having the service teams unable to maintain those lists on their was leading to them not being kept up 20:58:34 mugsie : I think designate was exemplary on this front :-) 20:58:39 however, that breaks for projects like neutron who may want to have noting to do with even tracking their drivers 20:58:49 fungi : right, that's the case I'm worried about 20:59:20 am wondering if there is opposition to it, or just nobody wanting to do it 20:59:32 because the latter can be fixed with a volunteer 20:59:33 it does seem like a large task for neutron to track so many out of tree plugins 20:59:33 we have a disappointing number of contributors who do not care about things not happening in their tree, and the point of this discoverability work was to address things happening outside of projects 20:59:50 based on the earlier discussions we seemed to have some projects who wanted to track and maintain lists of their drivers for the benefit of the driver marketplace, but i guess others who have no interest in doing so 21:00:16 so we need to balance giving folks the choice to contribute vs. not having good data because they choose not to 21:00:19 its probably lack of resources, and the lack of objective criteria, and wanting to avoid a massive argument? 21:00:32 johnthetubaguy : I'm sure all of those play a part 21:00:33 I would rather have people spend time inside Neutron team to keep that up to date, than a specific person on Foundation staff to do it as a completely separate website 21:00:43 so i'm guessing we need to come up with a model that allows some teams to participate in tracking drivers and others to let someone else do it 21:01:08 (out of time) 21:01:11 ttx: should we wait until there's a volunteer from within neutron, then? because if we block on that... 21:01:14 fungi: "let someone else do it" could be just find a volunteer who is wiling to do it 21:01:17 with the knowledge that it probably won't be as accurate if uninvolved parties are tasked with maintaining that information 21:01:24 argh yes, endmeeting 21:01:27 #endmeeting