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