20:02:06 <ttx> #startmeeting tc
20:02:06 <jroll> yeah, john is on honeymoon, congrats to him \o/
20:02:06 <openstack> Meeting started Tue Dec  6 20:02:06 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:09 <openstack> The meeting name has been set to 'tc'
20:02:11 <dhellmann> ttx: dims just contacted me that he won't be able to make it
20:02:18 <ttx> alright noted
20:02:26 <ttx> Hi everyone!
20:02:29 <ttx> Our agenda for today:
20:02:32 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:37 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:02:47 * Rocky_g just crept under the table with popcorn
20:02:48 <ttx> #topic Driver teams: discuss various options
20:02:53 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#108074
20:02:58 <ttx> I'll let dhellmann introduce the topic, then we'll likely take turns talking so that it's not too messy
20:03:07 <dhellmann> thanks, ttx
20:03:08 <dhellmann> To prepare for some upcoming big tent team proposals, I reviewed our current policies and found that they could be interpreted to not allow a team to build something focused on a single vendor's product line, as a driver would be in a lot of cases.
20:03:16 <dhellmann> We need to address that, because as things stand we will end up turning away contributors to the community.
20:03:16 <dhellmann> Both in terms of the people contributing, and in terms of the companies funding much of our work.
20:03:24 <dhellmann> Given the other recent cutbacks that were beyond our control, I think we should avoid encouraging companies to disengage from the community.
20:03:34 <mordred> ++
20:03:35 <dhellmann> Together ttx, fungi, and I identified 6 potential courses of action, represented by the various patches we've posted for review.
20:03:47 <dhellmann> I'm going to just paste these all at once, stand by
20:03:58 <dhellmann> #info option 1. Say that we prefer having a level playing field to allowing standalone driver teams. (Identified as the "hard black" option)
20:03:59 <dhellmann> #link https://review.openstack.org/#/c/403834/
20:03:59 <dhellmann> #info option 2. Say that the level playing field policy doesn't apply to driver teams, if the resources needed to work on the driver are open. (Identified as the "soft black" option)
20:03:59 <dhellmann> #link https://review.openstack.org/#/c/403836/
20:03:59 <dhellmann> #info 3. Remove the level playing field statement from the project team policies. (Identified as the "hard white" option)
20:04:00 <dhellmann> #link https://review.openstack.org/#/c/403838/
20:04:01 <dhellmann> #info 4. Loosen the level playing field statement to exempt driver teams completely. (Identified as the "soft white" option)
20:04:02 <dhellmann> #link https://review.openstack.org/#/c/403839/
20:04:03 <dhellmann> #info 5. Define a new type of team with different rules based on different expectations for driver teams. (Identified as the "grey" option)
20:04:04 <dhellmann> #link https://review.openstack.org/#/c/403829/
20:04:05 <dhellmann> #info 6. Require project teams with driver abstractions to host drivers in one of their official repos, as long as they meet some community standards. (Identified as the "red" option)
20:04:06 <dhellmann> #link https://review.openstack.org/#/c/403830/
20:04:09 <dhellmann> As well as a general resolution that might be mixed in with one of the other changes to provide more detail.
20:04:09 <dhellmann> #link https://review.openstack.org/#/c/403826/
20:04:17 <dhellmann> So far most of the discussion for the topic has been on the mailing list
20:04:17 <dhellmann> #link start of thread http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#108074
20:04:17 <dhellmann> #link continuation of thread http://lists.openstack.org/pipermail/openstack-dev/2016-December/thread.html#108410
20:04:26 <dhellmann> done
20:04:28 <ttx> I propose we take turns exposing our position, if we have one. Raise your hand (using o/) and wait until I give you voice
20:04:40 <dhellmann> o/
20:04:40 <ttx> I can start
20:04:46 <ttx> ah no, dhellmann
20:04:51 <fungi> the ml discussion was disappointingly sparse. i was hoping we'd drum up more interest in weighing pros and cons
20:04:52 <dhellmann> oh, that's fine, go ahead
20:04:58 <ttx> ok
20:05:09 <ttx> My personal view on this is that we should not dilute our open collaboration principles
20:05:15 <ttx> which is why I am against the hard white option, and am not a fan of the soft white option
20:05:22 <flaper87> o/
20:05:25 <ttx> I think it's unhealthy to require teams to adopt code they don't want, so I'm against the red option
20:05:25 <mtreinish> o/
20:05:33 <ttx> At the same time I think it would be better if we could include driver development as a part of our community rather than force it outside
20:05:41 <ttx> which is why I'm not a fan of the hard or soft black options.
20:05:50 <ttx> I like the grey option, because it enables driver teams to be part of the community, without compromising on our principles.
20:05:59 <ttx> It *clearly* defines a narrow and limited case where it benefits OpenStack to be more flexible, and keeps track of it separately
20:06:10 <ttx> So in summary: my preference goes to grey, I could live with soft white / hard black / soft black if there is a majority for it, and I'm against hard white / red.
20:06:16 <ttx> voice goes to dhellmann
20:06:25 <dhellmann> I know there have been scaling and social issues within the Neutron team that have led to the current situation (best summed up by Armando and Kevin's posts in the thread).
20:06:26 <ttx> then flaper87 then mtreinish
20:06:33 <dhellmann> The other major projects that have drivers have had less trouble with this, which makes it seem that with some adjustments we could adopt a community standard practice.
20:06:39 <dhellmann> I would prefer to have teams work things out internally so they can scale, rather than forcing scaling to happen by creating multiple teams.
20:06:49 <dhellmann> If some of our other policies and standards need to be reviewed to allow teams to scale “vertically", we should do that because the alternative is asking more teams to somehow scale “horizontally”.
20:06:56 <dhellmann> Continuing with drivers within the existing projects also recognizes drivers as important contributions to and features of the services that consume them
20:07:03 <dhellmann> and encourages the contributors to collaborate with the folks working on the abstraction layers within projects.
20:07:03 <mtreinish> oh, I was just saying I showed up :)
20:07:10 <dhellmann> That's the outcome of option 6, without making it a hard requirement.
20:07:13 <ttx> mtreinish: noted :)
20:07:23 <dhellmann> Which, I admit, isn't on the list of proposals and would need work.
20:07:35 <dhellmann> That said, it's possible that there is not a one-size-fits all solution.
20:07:35 <dhellmann> If the neutron team is committed to its current course, then I think we need to do something at the TC level, and adopt one of the other proposals.
20:08:04 <dhellmann> I would prefer to simplify our rules, rather than add new ones, so I lean in favor of either interpreting "level" as meaning anyone can contribute so the teams are ok or removing the phrase entirely.
20:08:23 <dhellmann> let me convert those to colors...
20:08:44 <dhellmann> soft black, hard white, or soft white
20:08:59 <dhellmann> I wrote up the red option, but I agree we don't want to set that precedent
20:09:01 <dhellmann> done
20:09:09 <ttx> that is your preference, or the list you can live up with ?
20:09:14 <mordred> yah. I agree about not liking red
20:09:16 <dhellmann> I can live with that list
20:09:27 <dhellmann> oh, I can live with grey, too
20:09:36 <dhellmann> I just prefer the options that seem simpler
20:09:37 <ttx> dhellmann: and any preference ?
20:09:55 <dhellmann> hard or soft white, I guess
20:10:05 <mordred> I agree with ttx's list and preference except I'm not in favor of hard black
20:10:09 <ttx> ok so dhellmann says preference hard/soft white, can live with softblack or grey.
20:10:27 <ttx> flaper87: voice goes to you
20:10:31 <flaper87> So, as I mentioned in the email I like the fact that option #5 acknowledges that drivers are somewhat different from other projects but I like the sense of inclusion that #6 gives. I'd like for #6 to be more explicit about it. I like that #6 gives the opportunity for drivers maintainers t ovote on the PTL election and it gives them also more voice (or the sense of mor voice) to these folks on the
20:10:32 <flaper87> team choices. It feels more welcoming and inclusive than #5.That said, I think I'm leaning more towards #5 even though it adds more complexity. It is more explicit and helps with organizing teams better
20:10:33 <fungi> o/
20:10:35 <mordred> ttx: it might be worth spinning up a non-binding condorcet to help us sort through TC preference
20:10:39 <flaper87> so, I guess my preference goes to grey
20:10:42 <sdague> o/ (queuing)
20:10:50 <ttx> mordred: on it
20:11:13 <ttx> queue has fungi and sdague next
20:11:13 <sdague> mordred: why don't we see how close to concensus we are first
20:11:18 <mordred> sdague: ++
20:11:21 <ttx> sdague: ++
20:11:51 <ttx> flaper87: preference to grey, and could live with... ?
20:11:52 <dtroyer> o/
20:12:25 <flaper87> I could live with soft black and red
20:12:30 <flaper87> I think I did the colors right
20:12:45 <mugsie> o/
20:12:46 <ttx> mordred is: preference to grey, could live with soft white soft black
20:12:54 <ttx> voice goes to fungi
20:12:59 <fungi> i drafted the black and white options as i'd much prefer to find minimal policy solutions, or effective interpretations of current policy. the grey option strikes me as giving up on welcoming driver teams into the big tent, and making a smaller exceptions-based tent off to the side they can go sit in
20:13:09 <ttx> queue gas sdague, dtroyer next
20:13:11 <ttx> has*
20:13:44 <fungi> if we want to welcome them into our community, to me that means finding ways to have one consistent policy which covers them in the same ways as our other teams
20:14:26 <ttx> fungi: do you have a preference ?
20:14:43 <fungi> on the other hand, i definitely want to make sure this doesn't simply become another place to get your driver/product listed to make it look better-supported
20:15:25 <fungi> so i think my order of preference is soft black, hard white, soft white, hard black, grey, red
20:15:40 <ttx> are there options you would rather not live with ?
20:15:48 * EmilienM voted for hard black but actually would prefer soft black now, after re-reading the policies.
20:15:59 <fungi> well, i don't really like red at all since i'm not a fan of telling projects what to do
20:16:08 <ttx> fungi: ok
20:16:10 <smcginnis> Hopefully I'm not derailing anything. Just another data point from me. I would be fine having drivers completely separate if adding a new driver was just a procedural rubber stamp by the core team. But I have yet to see a new driver submission that has not had to go through 20+ patch revs before it's in a decent shape to be accepted.
20:16:35 <smcginnis> My concern would be someone would run Cinder and an out of tree driver that has issues and have a bad experience.
20:16:51 <smcginnis> That would reflect badly on OpenStack and Cinder, even if it was entirely on the vendor for having issues.
20:17:01 <ttx> that is a fair point
20:17:13 <ttx> voice goes to sdague
20:17:37 <sdague> ok, I feel like red is a no go entirely, that just turns into a friction level that won't work
20:17:48 <ttx> queue has dtroyer next, amybe mugsie if I interpreted the o/ right and no other TC member wants voice
20:18:01 <ttx> sdague: ++
20:18:41 <sdague> my preference is to grey, because while drivers are a contribution to openstack, they tend to be a much more self serving contribution for a particular piece of vendor hardware / software
20:19:00 <sdague> and I want to distinguish things that are purely that from working on the common base
20:19:17 <sdague> especially in our over analyticized community
20:19:45 <ttx> sdague: are you done ?
20:19:51 <ttx> (I completely agree)
20:19:55 <sdague> yeh, that's probably good enough for now
20:20:05 <ttx> dtroyer; you're up
20:20:35 <dtroyer> I agree with the desire for driver inclusion by the project teams, basically how dhellmann described it but not forced like the red option ( as written, red it not an option for me).  I recognize that is not always going to work out.  I do think that recognizing the specifics of these kinds of teams may be necessary.  It is a bit of a side-test as fungi put it, but I see that as part carrot, part stick to try and make the
20:21:04 <dtroyer> We are talking about code that by its very nature can not be tested the same way as the majority of OpenStack so we are already making exceptions for them.  I believe recognizing that and guiding it will improve the situation.
20:21:19 <dtroyer> My preference is for grey, soft white
20:21:22 <dtroyer> fini
20:21:34 <ttx> mugsie: did you want voice ?
20:21:41 <fungi> o/
20:21:48 <mugsie> yeah  -I just had one thought
20:21:49 <sdague> just a side comment, nothing here says that projects can't have drivers in tree, its for the case in which they choose not to for a particular driver / driver team
20:22:18 <ttx> yeah, I would still encourage drivers to be in-tree, dhellmann has a complementary resolution for that
20:22:19 <dtroyer> sdague: ++, we should encourage that by default
20:22:19 <flaper87> sdague: yeah, this is specific for vendor specific drivers, I think. but you phrased it better
20:22:20 <mugsie> for the softs, and the grey option, should something like 3rd party testing be a requirement ?
20:22:39 <ttx> mugsie: there could be
20:22:45 <Rocky_g> o/ two side comments
20:22:45 <flaper87> mugsie: yeah, I think that's part of the proposal (probably not explicit)
20:22:47 <mugsie> (I have been out ofr a while, and I did not see it in the ML thread - but if this has been answered, I appologise)
20:22:48 <sdague> meaning option pink (the thing dtroyer / dhellman hint towards) is kind of already in our DNA.
20:23:18 <mugsie> I think that there should be a way of a random dev knoing that this change should work
20:23:18 <dhellmann> mugsie : inclusion requirements would still be up to each team, imo
20:23:36 <ttx> queue has fungi, Rocky_g
20:24:08 <dhellmann> sdague, the resolution in https://review.openstack.org/#/c/403826/1/resolutions/20161128-driver-teams.rst ends with a statement encouraging drivers to stay in projects
20:24:09 <mugsie> from my perspective, if I have to make a change to the driver interface, I would like to be able to send a patch to the repo, and see if it breaks
20:24:20 <ttx> mugsie: I think we could formalize that whatever the chosen option is
20:24:31 <ttx> fungi: you're up
20:24:35 <fungi> i should have probably clarified that my biggest concern with grey is that we're effectively developing what could be seen as a registry of drivers, and it turns into a means of indicating that your driver is approved by the openstack technical committee (rather than just a place to recognize teams working on something we can't count as being on the same level as other projects in the tent)
20:24:38 <fungi> mugsie's comments reinforce that concern for me
20:24:51 <dhellmann> ++
20:25:08 <dhellmann> o/
20:25:13 <sdague> like, I wouldn't see Nova dumping hyperv or xenapi while there were still notable users of those. If it turned out all the users of these things we knew about went away (or all the people maintaining it), we might want to put it out of tree. Basically that's what happened with the docker driver.
20:25:17 <ttx> I don't really see how the other options help with that though
20:25:17 <fungi> third-party testing requirements, code quality, et cetera are things service teams would want to require of drivers to determine how well they're supported, independent of how they're governed
20:25:50 <EmilienM> fungi: +1
20:25:51 <Rocky_g> ++
20:25:58 <fungi> the other options besides grey don't involve the tc maintaining an approved list of drivers
20:26:07 <sdague> fungi: I think you address that with reporting on 3rd party CI status
20:26:17 <ttx> Well, that's not what grey is -- it's just keeping track of teams
20:26:22 <sdague> but, I think that's true for any approach
20:26:23 <fungi> i think the tc shouldn't have a stake in third-party testing
20:26:47 <sdague> fungi: who should have that stake?
20:26:50 <fungi> i think with the less-is-more governance approach, that's something that ought to be up to the individual service teams
20:26:50 <jroll> o/ quick question
20:27:11 <ttx> Rocky_g: you're up, then dhellmann, jroll
20:28:01 <Rocky_g> K.  Firs, I want to say this mode of discussion is great and I encourage its use whenever there are invitees to discuss topics.  I can easily follow it.
20:28:44 <mordred> ++
20:28:48 <Rocky_g> Second.  Just want to remind everyone of Poppy and say that you may want to consider how it might become part of the big tent based on the outcome of this dicision
20:28:51 <Rocky_g> Done
20:29:05 <ttx> (fungi: I'm interested in ways we could tweak grey to reduce that potential side-effect)
20:29:13 <ttx> dhellmann: you're up
20:29:18 <dhellmann> Whatever solution we pick, I think we’ll also need to address the driver support documentation question.
20:29:25 <dhellmann> I know there’s a site managed by the foundation, but I’m not sure project teams have the input into that data to make them comfortable enough with these “official” drivers living out of tree.
20:29:25 <dhellmann> Because although we’re talking about a governance change and teams, it’s clear to me from the discussions I’ve had with other folks that they don’t always make the distinction between code and teams, so a list of “driver teams” is going to look a lot like a list of “supported drivers” to some.
20:29:32 <dhellmann> over
20:29:59 <mordred> ++
20:30:30 <Rocky_g> o/
20:30:30 <dtroyer> We've fallen short of these special driver teams are indistinguishable from in-tree drivers
20:30:35 <ttx> I think that's unescapable though... you can bury the information in a larger yaml, won't make it less official
20:30:51 <ttx> jroll: you're up
20:30:53 <dhellmann> right, I'm suggesting that we need to actually document the level of support for all drivers
20:30:57 <jroll> thanks
20:31:01 <jroll> with the red option, does that allow any choice at all for the project teams? e.g. a driver that works but the project team fundamentally disagrees with (not-so-real example: a network switch provisioning driver for ironic, if ironic decides it doesn't want to provision switches). or allowing the project team to have requirements like third party CI to accept the driver repo into the project.
20:31:04 <Rocky_g> ++ dhellmann
20:31:17 <ttx> dhellmann: agree that the driver marketplace or whatever the name is needs to be revved up
20:32:00 <sdague> jroll: I think those conflicts are going to be frequent, which is why most people voicing opinions here have put the red option as not viable
20:32:47 <jroll> or is it a hard "project teams must allow any driver"
20:32:47 <jroll> even sillier example, a coffeepot driver for ironic (this exists!)
20:32:48 <ttx> jroll: it's called red for a reason. Lots of blood
20:32:48 * ttx lags a bit, so lets switch to normal open discussion
20:32:48 <fungi> the red option was a bit more of a straw-man than the others, i think. if it were a serious contender it would almost certainly need a lot more detail
20:33:09 <jroll> okay, cool, I may have missed some things, thanks
20:33:11 <Rocky_g> So, ttx calling it "driver marketplace" gets to my next comment.   Make it a driver store so customers can rate them and leave comments
20:33:17 <ttx> It feels like grey is promising but the devil is in the details. The one person that ranked it very low was fungi
20:33:17 <mtreinish> jroll: I want to use that driver :)
20:33:44 <dhellmann> jroll : teams could have rules like third-party ci
20:33:44 <dhellmann> it would be weird for someone to write a switch driver that met ironic's API, but if that came up I think you could say it doesn't follow the mission of the team so it's out of scope
20:33:45 <dhellmann> jroll : does that answer your questions?
20:33:51 <fungi> i still feel like grey is a lot of bureaucracy and red tape for something we could accomplish in other ways
20:33:54 <sdague> Rocky_g: I feel like customers rating things only works at statistically high volume of ratings
20:33:54 <smcginnis> jroll: https://www.ietf.org/rfc/rfc2324.txt
20:33:59 <jroll> dhellmann: yes, it does, thanks
20:34:24 <ttx> fungi: we could talk it through. I fear that not red-taping it would add a lot of confusion
20:34:43 <ttx> including tainting our principles in a bad light
20:34:50 <fungi> also, some of these aren't entirely mutually exclusive
20:35:02 <flaper87> so, I assume normal voting will happen over reviews, right ?
20:35:14 <flaper87> sdague: ++
20:35:25 <ttx> Basically I think people will have a hard time considering open collaboration to be an important tenet if they can't spot one team from another
20:35:30 <fungi> hard black was meant to represent the status quo assumption that no driver could ever be independently developed and still meet our community's standards
20:35:58 <fungi> soft black addresses teh question of what happens if a driver is developed by a normal (to us) team outside the vendor who makes that product (it happens in lots of other communities)
20:36:08 <ttx> soft black to me is the status quo
20:36:23 <ttx> (the way I interpret the current rules)
20:36:35 <EmilienM> flaper87: I hope so :)
20:36:54 <ttx> like dhellmann said, if we just keep the same those driver teams would get rejected today
20:37:13 <fungi> fair enough, it was my interpretation as well, but the grey option seems to assume that you can't write a driver as a "normal" project team without also developing other things
20:37:24 <dhellmann> ttx: that's interesting, I saw the status quo as hard black unless the driver is for an open source project of some sort, and those aren't having any trouble staying in-tree
20:37:30 <sdague> fungi: in what way?
20:37:54 <fungi> i personally don't want to lose the possibility to encourage drivers to be developed openly and independent of their vendors, and for vendors to release good specs for their hardware to make that possible
20:37:56 <sdague> dhellmann: maybe with neutron, but not with other projects
20:38:01 <ttx> dhellmann: why ? we always said that if a driver team somehow magically provided the same resources to every contributor, it would be a level playing field
20:38:04 <flaper87> I want to welcome drivers so, I really hope the voting will be done around how we can achieve this
20:38:35 <dhellmann> ttx: right, but that isn't a realistic situation, which is why we're effectively hard-black now
20:38:45 <dhellmann> sdague : yes, true
20:38:52 <fungi> i also feel like if we make concessions to driver teams, we reduce the incentive for them to become more open and just accept that it will never happen
20:38:53 <flaper87> dhellmann: ++
20:38:56 <sdague> grey feels like a way we can give drivers space here in the community, but still distinguish that they are different
20:39:34 <fungi> grey feels like defining a second community which is almost like ours but in a twilight-zone parallel dimension
20:39:39 <dhellmann> grey still blocks a project like poppy, right?
20:39:40 <sdague> fungi: maybe, but we also need to figure out what other efficiencies and costs are we going to trade for building that incentive structure for driver teams
20:39:51 <ttx> yeah, I feel like anything less would create a lot of confusion. Like "why are you rejecting my project ? That team over there is doing this and that"
20:39:55 <dtroyer> I don't think the poppy conclusion changes with this discussion
20:40:08 <ttx> dhellmann: no
20:40:19 <ttx> poppy actually is OK with hard black :)
20:40:46 <ttx> since it does not benefit a single party
20:40:50 <dhellmann> yes, well, that was my position when we voted, too. I'm trying to understand if any of these options allow poppy to join.
20:41:11 <ttx> I'd say all of them. But that's a separate discussion
20:41:17 <ttx> So... next actions
20:41:30 <dhellmann> in the minds of those who voted against it
20:41:31 <ttx> should we just vote on the proposal, or take some of them through an iterative improvement process ?
20:41:55 <dhellmann> are there any others than the red option we can eliminate from further discussion?
20:41:56 <dtroyer> I think we should identify the two or three realistic ones and work on them
20:41:58 <flaper87> can we just abandon the ones didn't get a vote?
20:41:59 * dims just barely made it home
20:42:01 <EmilienM> +1 for iterative improvement process
20:42:11 <ttx> I consider grey promising, but would not consider it perfect or final
20:42:17 <sdague> ttx: ++
20:42:22 <dhellmann> dims : did you want to say anything about the driver team stuff before we start dropping options and moving to next steps?
20:42:29 <sdague> it just seems like the starting point of what reality is
20:42:31 <ttx> there might be ways to improve it that would reduce fungi's concerns about it
20:42:32 <flaper87> ttx: we have some votings/preferences. Let's get those and abandon the rest
20:42:42 <flaper87> I think grey is promising and I think we could improve it
20:42:50 <ttx> OK, I'll go through them and propose an outcome based on that discussion
20:42:54 <dims> dhellmann : gotta read scroll back, but will respond on the reviews (grey(
20:42:56 <flaper87> ++
20:42:58 <flaper87> thanks, ttx
20:42:59 <dhellmann> I will happily yield ownership of the grey patch to someone who wants to work on updates
20:43:00 <stevemar> makes sense to remove the ones that didn't get any positive feedback
20:43:06 <ttx> stevemar: yes
20:43:23 <EmilienM> stevemar: +1
20:43:24 <ttx> and then see if we can improve any of the ones we seem to be able to "live with"
20:43:32 <ttx> Let's move on to next topic ?
20:43:34 <flaper87> I'd be happy to help wih grey but I'm working on the languages ref doc so I'll let that to someone else
20:43:36 <dhellmann> s/with/by/
20:43:44 <ttx> live by, that's the one
20:43:51 <ttx> I confuse them
20:43:59 <flaper87> ttx: you and me both
20:44:02 <dhellmann> maybe someone slightly less invested wants to moderate the updates?
20:44:05 <dhellmann> stevemar?
20:44:14 <stevemar> dhellmann: happy to
20:44:19 <dhellmann> cool, thanks
20:44:19 <flaper87> dhellmann: stevemar ++
20:44:27 <fungi> i've been trying to think of ways to mitigate my concern with grey... but it's similar to why the vmt doesn't publish the list of vendors who subscribe for advance notifications. as soon as the openstack community opens another place for companies to list their names, they'll flock to it in droves
20:44:32 <stevemar> keystone has no stake here
20:44:33 <ttx> stevemar: cool, if you lack rights to abandon, just let me know
20:45:02 <stevemar> ttx: ack
20:45:09 <ttx> #action stevemar to summarize outcomes for each proposal and propose abandons
20:45:19 <ttx> #topic Amend reference/PTI with supported distros
20:45:25 <ttx> #link https://review.openstack.org/402940
20:45:29 <ttx> EmilienM: want to introduce that one ?
20:45:35 <EmilienM> maybe :)
20:45:39 <mtreinish> fungi: yeah, that's kinda what I was wondering. What does the community (and the project teams) get out of this?
20:45:51 <mtreinish> s/project/driver
20:45:59 <EmilienM> so I want to be quick, I noticed some projects don't gate functional tests on centos7
20:46:05 <dims> mtreinish : access to vertical teams (docs, translation)
20:46:21 <ttx> (fungi: we can still have pretty high requirements, like 3rd party testing)
20:46:23 <EmilienM> and it might seem important to us to consider is, as some of our users are deploying on this platform
20:46:31 <EmilienM> I found useful to share this feedback and propose this change
20:46:51 <dhellmann> EmilienM : is the issue mainly that there are differences in dependencies on those platforms? or other configuration issues?
20:47:03 <EmilienM> dhellmann: dependencies
20:47:15 <mtreinish> dhellmann: well centos devstack is often broken because of config differences too
20:47:23 <mtreinish> and no one ever looks at it
20:47:30 <mordred> I think that's my biggest concern
20:47:34 <mtreinish> which I think is the actual issue on that
20:47:34 <ttx> the way it's phrased, it's just encouraging tests to use more of CentOs, right ?
20:47:37 <mordred> devstack centos is frequently broken
20:47:37 <EmilienM> please keep in mind my idea was not about blocking any feature because this feature wouldn't work on centos7
20:47:38 <sdague> right, it's pretty much only ianw keeping that working
20:47:40 <flaper87> mtreinish: yeah, I was going to say that it's probably mainly dependencies but there's also something about configs
20:47:42 <fungi> there are projects interested in gating on dependencies too new to be present in lts releases of either ubuntu or centos
20:47:50 <mordred> and until thats' more solid, having other things depending on it seems scary
20:47:55 <sdague> mordred: ++
20:47:55 <mordred> otoh ...
20:48:06 <mordred> if more projects depended on it - it would potentially get more people caring
20:48:07 <fungi> it's one thing if they want to develop features that can _never_ work on a platform we intend to support
20:48:11 <dhellmann> this is all phrased as encouraging teams to do it voluntarily, right?
20:48:25 <dhellmann> EmilienM : ^^
20:48:31 <mordred> does devstack gate itself on centos?
20:48:32 <EmilienM> dhellmann: exactly
20:48:42 <dims> yes, it is dhellmann
20:48:46 <mtreinish> mordred: it's nv (or experimental) because it doesn't work
20:48:49 <mtreinish> I think
20:48:50 * mtreinish checks
20:48:58 <sdague> from a pragmatic perspective I'd like to get more centos fans contributing in the QA / infra space first to keep things working. It feels like that's a foundation we are missing before telling teams to do more of it
20:49:00 <flaper87> I think the first step is to encourage folks to voluntarily depend on it and then improve support
20:49:04 <mordred> sdague: ++
20:49:06 <clarkb> mtreinish: correct
20:49:09 <fungi> nv last a looked, and seemed to be passing regularly recently
20:49:10 <clarkb> devstack too
20:49:11 <EmilienM> and I know people here like devstack but I've been also working on making tripleo jobs usable outside TripleO projects (eg: you can run them in Ceilometer's gate, and it uses Centos7)
20:49:12 <flaper87> but I'm not too much into infra
20:49:12 <mtreinish> clarkb wins :)
20:49:27 <ttx> sdague: yeah, if the support is shaky right now maybe adding more tests on that platform is a recipe for more fail
20:49:27 <mordred> yah - I think we need to encourage that to be in good shape as a baseline - otherwise we're recommending something to project teams that will not work
20:49:37 <EmilienM> the jobs take less than 50 minutes and have pretty good coverage and are maintained by tripleo foks... not sure you like the idea
20:50:02 <dhellmann> do we have some sort of objective measure we could use to say "when X is done then we can approve this"?
20:50:15 <flaper87> a.k.a I think this is a good first step
20:50:16 <jeblair> as a reminder, here is the existing distro support policy: http://lists.openstack.org/pipermail/openstack-dev/2012-December/004052.html
20:50:17 <EmilienM> anyway, beside the tools, the idea was really about documenting our official platforms we like to support in our tests
20:50:27 <mordred> dhellmann: for me I think it would be that devstack itself has a gating job running on centos
20:50:32 <sdague> EmilienM: I think thrusting not only a second OS, but a second install & dev model on development teams is really burdensome
20:50:32 <JayF> If this is desirable, I wonder if it'd be a good target for a cross-project Pike goal, in the vein of the oslo-incubator stuff from Ocata.
20:50:37 <mordred> which I think would be a good thing to exist ... but is under-resourced
20:50:40 <JayF> Rather than simply being a policy change.
20:50:52 <ttx> jeblair: nice history dive
20:51:00 <dhellmann> mordred : will the QA team accept that job, if there's someone working on it? it seems like it would be easier to keep support if they put the job in place.
20:51:09 <clarkb> as the person currently trying to force all of openstack to use xenial (eg update from trusty) even getting projects to do that is almost impossible
20:51:11 <sdague> mordred: it breaks a bit too often for that to be the case right now
20:51:12 <fungi> gate-tempest-dsvm-platform-centos7-nv ran successfully against https://review.openstack.org/404476 in <50 minutes
20:51:21 <clarkb> so as a reality check I don't think the proposed change is going to help anything project side
20:51:22 <sdague> dhellmann: centos breaks for quite odd reasons
20:51:24 <EmilienM> sdague: i don't disagree
20:51:28 <jeblair> actually, i think the thing voted on is: https://etherpad.openstack.org/p/python-support-motion
20:51:32 <jeblair> http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.html
20:51:32 <dhellmann> sdague : not related to changes in devstack itself?
20:51:36 <mordred> sdague: yes - I agree - mostly saying that if that is the goal then people can talk about resourcing it
20:51:54 <mordred> jeblair, ttx: we should maybe get that into the governance repo?
20:51:58 <mtreinish> fungi: but it's not running exactl the same thing, like ssl is disabled there
20:51:58 <sdague> dhellmann: nope. A bunch of things take more kernel memory on centos that cause issues
20:52:09 <sdague> there have been a number of odd bugs
20:52:13 <clarkb> ya wecan't ssl on centos because apache doesn't work
20:52:17 <ttx> ok, so it sounds like it's a bit early for even suggesting ?
20:52:18 <fungi> mtreinish: exciting, so there's stuff we've disabled to get it to run on centos?
20:52:21 <mtreinish> yep
20:52:25 <ttx> mordred: propose and you should get it
20:52:27 <stevemar> clarkb: that seems rather limiting
20:52:33 <sdague> plus, the cadence is so much slower that we get drive away from the tooling that people want to be using
20:52:34 <dhellmann> sdague : ok. we're going to have a hard time coming up with resources to address it if there's not a general sense that the devstack team would welcome it.
20:52:34 <mordred> ttx: k. I guess I just walked in to that
20:52:43 <ttx> kind of
20:52:47 <clarkb> stevemar: I am sure it can be made to work but no one is doing the work
20:52:53 <ttx> I would blame jeblair for pushing you into it
20:53:07 <sdague> dhellmann: if there were more people on top of it so that the existing team didn't have to drop everything to go figure it out, it would help
20:53:10 <jeblair> plonk
20:53:14 <fungi> presumably we then need a reasonably similar configuration and to have it running the same tempest tests as we currently run against ubuntu 16.04
20:53:16 <dims> ++ sdague
20:53:30 <dhellmann> sdague : yeah, so we need both "sides" to agree it's a reasonable goal :-)
20:53:40 <dims> ++ dhellmann :)
20:53:44 <sdague> right now it's mostly ianw, and he's in .au tz. It's too much to ask him to own it all 24 hours a day
20:53:50 <dhellmann> of course
20:54:02 <dhellmann> I'm thinking RH ought to be involved
20:54:03 <mtreinish> sdague: I have faith in ianw :)
20:54:08 <ttx> OK, so it sounds like it's a bit early to even suggest this
20:54:11 <EmilienM> do you folks have #action ? we're seeing lot of things now
20:54:11 <flaper87> mtreinish: lol
20:54:14 <sdague> ianw is great, don't get me wrong
20:54:25 <fungi> ianw is amazing, but yes he should have some more support from his colleagues at rh it sounds like
20:54:26 <ttx> what is the next step ?
20:54:30 <EmilienM> dhellmann: yes, we have the resources I think
20:54:32 <dhellmann> EmilienM : you and I should see if we can get some resources working on better centos support for devstack
20:54:47 <sdague> it's just that we've got the rest of the core team, plus 20 - 40 other random community members that will show up to fix devstack on ubuntu
20:54:47 <flaper87> I think getting some action items that would help moving this forward would be great
20:54:57 <ttx> #info dhellmann and EmilienM  should see if we can get some resources working on better centos support for devstack
20:54:59 <EmilienM> dhellmann: I volunteer to work on this thing, even if I'm not a devstack fan
20:54:59 <dhellmann> then we can try for a voting gate job, and then we can see about getting this change added
20:55:04 <sdague> and an order of magnitude less on the centos side
20:55:08 <EmilienM> ttx: thx
20:55:21 <ttx> #info because it's a blocker to larger use of CentOS in test jobs
20:55:37 <jroll> is the goal to duplicate all devstack jobs to run on both ubuntu and centos? is infra cool with doubling that?
20:55:40 <ttx> OK, let's move on quickly to next topic
20:55:48 <jroll> (I assume so but throwing it out there)
20:55:54 <mtreinish> jroll: nah, I think it's just to have a token centos job
20:55:57 <fungi> jroll: probably not entirely duplicate, no
20:55:57 <ttx> jroll: I think you would matrix them, some tests on CenTOS, some on Ubuntu
20:56:03 <jroll> okay cool
20:56:04 <mordred> I don't think we need to double across the board - just make it possible for _some_ things to opt in to centos stuff if they desire
20:56:15 <ttx> #topic Do not allow data plane downtime during upgrades
20:56:15 <mordred> other people are more succinct :)
20:56:20 <ttx> #link https://review.openstack.org/404361
20:56:27 <ttx> We don't have much time to discuss it
20:56:38 <ttx> probably better to put it on next week agenda
20:56:39 <stevemar> dolphm: around?
20:57:04 <dolphm> stevemar: yes
20:57:04 <stevemar> ttx: probably for the best
20:57:13 <ttx> I think we can discuss on the review until then
20:57:20 <dolphm> i'm good for next week with 2 minutes left on the clock ;)
20:57:20 <mordred> I agree with dhellmann's comment in the review
20:57:29 <stevemar> dolphm: thanks :)
20:57:36 <ttx> #topic Open discussion
20:58:04 <mordred> as much as I'm sure we all want to bikeshed over words - 'data plane' is sufficiently vague that I don't expect everyone to agree what it means
20:58:23 <ttx> If you have a strong opinion on where to allow meetings to happen (more meeting rooms or opening up project rooms to meetings) please comment on the thread
20:58:34 <mordred> I know what _I_ would expect from it - but I also expect directly routable IPv4 to VMs as a default and other people don't - so we should be clear
20:58:39 <dhellmann> I also suspect that given a bunch of existing projects with this tag, a new tag will be easier to implement that a major change in the rules
20:58:46 <mordred> dhellmann: yah
20:58:47 <dims> fyi, i spent the morning talking to folks at massachusetts open cloud (they use openstack a lot) https://info.massopencloud.org/blog/2016-moc-fall-workshop/
20:59:12 <dhellmann> dims : nice, thanks for the link
20:59:15 <fungi> mass o' cloud ;)
20:59:16 <dolphm> dhellmann: that's a good point
20:59:21 <sdague> dhellmann: honestly, it was kind of implied in the current tag
20:59:27 <ttx> IRC meetings thread: http://lists.openstack.org/pipermail/openstack-dev/2016-December/108360.html
20:59:28 <sdague> and the automated testing that you have to run to get that tag
20:59:29 <dims> :)
20:59:29 <dhellmann> dolphm : someone else did make it in the review, so I don't get credit :-)
20:59:58 <sdague> we can define data plane, if that's an issue for folks
21:00:03 <dtroyer> no tag upgrades?
21:00:08 <ttx> At the board meeting today they mentioned they might want to do a joint TC/Board meeting around the PTG
21:00:23 <ttx> Though it's not really an official proposal yet
21:00:28 <ttx> but fair warning
21:00:35 <fungi> in the same vicinity as the ptg?
21:00:40 <flaper87> good to know
21:00:45 <mordred> ttx: it would likely be good to communicate that most of the TC is likely to be booked all 5 weekdays
21:00:45 <flaper87> someone asked me tha recently
21:01:00 <flaper87> mordred: ++
21:01:02 <mordred> since most of the TC is fairly strongly involved in both vertical and horizontal efforts
21:01:05 <jeblair> yeah, could we please not double book the tc?
21:01:07 <mordred> and the PTG has been planned for a while
21:01:07 <dims> thanks for the heads up ttx, will have to book flights accordingly
21:01:11 <ttx> We migth have some time on the Friday
21:01:18 <mordred> like, as a TC member, I will not attend that if it's during the week
21:01:25 <ttx> anyway, more on that when they actually talk to me about it
21:01:30 <jeblair> or, i guess, if it does happen, maybe i'll just go home a day early or whatever
21:01:50 <ttx> and we are offtime
21:01:54 <ttx> thanks everyone
21:01:57 <flaper87> o/
21:01:57 <ttx> #endmeeting