20:02:06 #startmeeting tc 20:02:06 yeah, john is on honeymoon, congrats to him \o/ 20:02:06 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:09 The meeting name has been set to 'tc' 20:02:11 ttx: dims just contacted me that he won't be able to make it 20:02:18 alright noted 20:02:26 Hi everyone! 20:02:29 Our agenda for today: 20:02:32 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:37 (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 #topic Driver teams: discuss various options 20:02:53 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#108074 20:02:58 I'll let dhellmann introduce the topic, then we'll likely take turns talking so that it's not too messy 20:03:07 thanks, ttx 20:03:08 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 We need to address that, because as things stand we will end up turning away contributors to the community. 20:03:16 Both in terms of the people contributing, and in terms of the companies funding much of our work. 20:03:24 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 ++ 20:03:35 Together ttx, fungi, and I identified 6 potential courses of action, represented by the various patches we've posted for review. 20:03:47 I'm going to just paste these all at once, stand by 20:03:58 #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 #link https://review.openstack.org/#/c/403834/ 20:03:59 #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 #link https://review.openstack.org/#/c/403836/ 20:03:59 #info 3. Remove the level playing field statement from the project team policies. (Identified as the "hard white" option) 20:04:00 #link https://review.openstack.org/#/c/403838/ 20:04:01 #info 4. Loosen the level playing field statement to exempt driver teams completely. (Identified as the "soft white" option) 20:04:02 #link https://review.openstack.org/#/c/403839/ 20:04:03 #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 #link https://review.openstack.org/#/c/403829/ 20:04:05 #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 #link https://review.openstack.org/#/c/403830/ 20:04:09 As well as a general resolution that might be mixed in with one of the other changes to provide more detail. 20:04:09 #link https://review.openstack.org/#/c/403826/ 20:04:17 So far most of the discussion for the topic has been on the mailing list 20:04:17 #link start of thread http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#108074 20:04:17 #link continuation of thread http://lists.openstack.org/pipermail/openstack-dev/2016-December/thread.html#108410 20:04:26 done 20:04:28 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 o/ 20:04:40 I can start 20:04:46 ah no, dhellmann 20:04:51 the ml discussion was disappointingly sparse. i was hoping we'd drum up more interest in weighing pros and cons 20:04:52 oh, that's fine, go ahead 20:04:58 ok 20:05:09 My personal view on this is that we should not dilute our open collaboration principles 20:05:15 which is why I am against the hard white option, and am not a fan of the soft white option 20:05:22 o/ 20:05:25 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 o/ 20:05:33 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 which is why I'm not a fan of the hard or soft black options. 20:05:50 I like the grey option, because it enables driver teams to be part of the community, without compromising on our principles. 20:05:59 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 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 voice goes to dhellmann 20:06:25 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 then flaper87 then mtreinish 20:06:33 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 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 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 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 and encourages the contributors to collaborate with the folks working on the abstraction layers within projects. 20:07:03 oh, I was just saying I showed up :) 20:07:10 That's the outcome of option 6, without making it a hard requirement. 20:07:13 mtreinish: noted :) 20:07:23 Which, I admit, isn't on the list of proposals and would need work. 20:07:35 That said, it's possible that there is not a one-size-fits all solution. 20:07:35 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 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 let me convert those to colors... 20:08:44 soft black, hard white, or soft white 20:08:59 I wrote up the red option, but I agree we don't want to set that precedent 20:09:01 done 20:09:09 that is your preference, or the list you can live up with ? 20:09:14 yah. I agree about not liking red 20:09:16 I can live with that list 20:09:27 oh, I can live with grey, too 20:09:36 I just prefer the options that seem simpler 20:09:37 dhellmann: and any preference ? 20:09:55 hard or soft white, I guess 20:10:05 I agree with ttx's list and preference except I'm not in favor of hard black 20:10:09 ok so dhellmann says preference hard/soft white, can live with softblack or grey. 20:10:27 flaper87: voice goes to you 20:10:31 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 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 o/ 20:10:35 ttx: it might be worth spinning up a non-binding condorcet to help us sort through TC preference 20:10:39 so, I guess my preference goes to grey 20:10:42 o/ (queuing) 20:10:50 mordred: on it 20:11:13 queue has fungi and sdague next 20:11:13 mordred: why don't we see how close to concensus we are first 20:11:18 sdague: ++ 20:11:21 sdague: ++ 20:11:51 flaper87: preference to grey, and could live with... ? 20:11:52 o/ 20:12:25 I could live with soft black and red 20:12:30 I think I did the colors right 20:12:45 o/ 20:12:46 mordred is: preference to grey, could live with soft white soft black 20:12:54 voice goes to fungi 20:12:59 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 queue gas sdague, dtroyer next 20:13:11 has* 20:13:44 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 fungi: do you have a preference ? 20:14:43 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 so i think my order of preference is soft black, hard white, soft white, hard black, grey, red 20:15:40 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 well, i don't really like red at all since i'm not a fan of telling projects what to do 20:16:08 fungi: ok 20:16:10 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 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 That would reflect badly on OpenStack and Cinder, even if it was entirely on the vendor for having issues. 20:17:01 that is a fair point 20:17:13 voice goes to sdague 20:17:37 ok, I feel like red is a no go entirely, that just turns into a friction level that won't work 20:17:48 queue has dtroyer next, amybe mugsie if I interpreted the o/ right and no other TC member wants voice 20:18:01 sdague: ++ 20:18:41 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 and I want to distinguish things that are purely that from working on the common base 20:19:17 especially in our over analyticized community 20:19:45 sdague: are you done ? 20:19:51 (I completely agree) 20:19:55 yeh, that's probably good enough for now 20:20:05 dtroyer; you're up 20:20:35 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 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 My preference is for grey, soft white 20:21:22 fini 20:21:34 mugsie: did you want voice ? 20:21:41 o/ 20:21:48 yeah -I just had one thought 20:21:49 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 yeah, I would still encourage drivers to be in-tree, dhellmann has a complementary resolution for that 20:22:19 sdague: ++, we should encourage that by default 20:22:19 sdague: yeah, this is specific for vendor specific drivers, I think. but you phrased it better 20:22:20 for the softs, and the grey option, should something like 3rd party testing be a requirement ? 20:22:39 mugsie: there could be 20:22:45 o/ two side comments 20:22:45 mugsie: yeah, I think that's part of the proposal (probably not explicit) 20:22:47 (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 meaning option pink (the thing dtroyer / dhellman hint towards) is kind of already in our DNA. 20:23:18 I think that there should be a way of a random dev knoing that this change should work 20:23:18 mugsie : inclusion requirements would still be up to each team, imo 20:23:36 queue has fungi, Rocky_g 20:24:08 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 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 mugsie: I think we could formalize that whatever the chosen option is 20:24:31 fungi: you're up 20:24:35 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 mugsie's comments reinforce that concern for me 20:24:51 ++ 20:25:08 o/ 20:25:13 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 I don't really see how the other options help with that though 20:25:17 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 fungi: +1 20:25:51 ++ 20:25:58 the other options besides grey don't involve the tc maintaining an approved list of drivers 20:26:07 fungi: I think you address that with reporting on 3rd party CI status 20:26:17 Well, that's not what grey is -- it's just keeping track of teams 20:26:22 but, I think that's true for any approach 20:26:23 i think the tc shouldn't have a stake in third-party testing 20:26:47 fungi: who should have that stake? 20:26:50 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 o/ quick question 20:27:11 Rocky_g: you're up, then dhellmann, jroll 20:28:01 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 ++ 20:28:48 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 Done 20:29:05 (fungi: I'm interested in ways we could tweak grey to reduce that potential side-effect) 20:29:13 dhellmann: you're up 20:29:18 Whatever solution we pick, I think we’ll also need to address the driver support documentation question. 20:29:25 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 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 over 20:29:59 ++ 20:30:30 o/ 20:30:30 We've fallen short of these special driver teams are indistinguishable from in-tree drivers 20:30:35 I think that's unescapable though... you can bury the information in a larger yaml, won't make it less official 20:30:51 jroll: you're up 20:30:53 right, I'm suggesting that we need to actually document the level of support for all drivers 20:30:57 thanks 20:31:01 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 ++ dhellmann 20:31:17 dhellmann: agree that the driver marketplace or whatever the name is needs to be revved up 20:32:00 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 or is it a hard "project teams must allow any driver" 20:32:47 even sillier example, a coffeepot driver for ironic (this exists!) 20:32:48 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 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 okay, cool, I may have missed some things, thanks 20:33:11 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 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 jroll: I want to use that driver :) 20:33:44 jroll : teams could have rules like third-party ci 20:33:44 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 jroll : does that answer your questions? 20:33:51 i still feel like grey is a lot of bureaucracy and red tape for something we could accomplish in other ways 20:33:54 Rocky_g: I feel like customers rating things only works at statistically high volume of ratings 20:33:54 jroll: https://www.ietf.org/rfc/rfc2324.txt 20:33:59 dhellmann: yes, it does, thanks 20:34:24 fungi: we could talk it through. I fear that not red-taping it would add a lot of confusion 20:34:43 including tainting our principles in a bad light 20:34:50 also, some of these aren't entirely mutually exclusive 20:35:02 so, I assume normal voting will happen over reviews, right ? 20:35:14 sdague: ++ 20:35:25 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 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 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 soft black to me is the status quo 20:36:23 (the way I interpret the current rules) 20:36:35 flaper87: I hope so :) 20:36:54 like dhellmann said, if we just keep the same those driver teams would get rejected today 20:37:13 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 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 fungi: in what way? 20:37:54 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 dhellmann: maybe with neutron, but not with other projects 20:38:01 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 I want to welcome drivers so, I really hope the voting will be done around how we can achieve this 20:38:35 ttx: right, but that isn't a realistic situation, which is why we're effectively hard-black now 20:38:45 sdague : yes, true 20:38:52 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 dhellmann: ++ 20:38:56 grey feels like a way we can give drivers space here in the community, but still distinguish that they are different 20:39:34 grey feels like defining a second community which is almost like ours but in a twilight-zone parallel dimension 20:39:39 grey still blocks a project like poppy, right? 20:39:40 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 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 I don't think the poppy conclusion changes with this discussion 20:40:08 dhellmann: no 20:40:19 poppy actually is OK with hard black :) 20:40:46 since it does not benefit a single party 20:40:50 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 I'd say all of them. But that's a separate discussion 20:41:17 So... next actions 20:41:30 in the minds of those who voted against it 20:41:31 should we just vote on the proposal, or take some of them through an iterative improvement process ? 20:41:55 are there any others than the red option we can eliminate from further discussion? 20:41:56 I think we should identify the two or three realistic ones and work on them 20:41:58 can we just abandon the ones didn't get a vote? 20:41:59 * dims just barely made it home 20:42:01 +1 for iterative improvement process 20:42:11 I consider grey promising, but would not consider it perfect or final 20:42:17 ttx: ++ 20:42:22 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 it just seems like the starting point of what reality is 20:42:31 there might be ways to improve it that would reduce fungi's concerns about it 20:42:32 ttx: we have some votings/preferences. Let's get those and abandon the rest 20:42:42 I think grey is promising and I think we could improve it 20:42:50 OK, I'll go through them and propose an outcome based on that discussion 20:42:54 dhellmann : gotta read scroll back, but will respond on the reviews (grey( 20:42:56 ++ 20:42:58 thanks, ttx 20:42:59 I will happily yield ownership of the grey patch to someone who wants to work on updates 20:43:00 makes sense to remove the ones that didn't get any positive feedback 20:43:06 stevemar: yes 20:43:23 stevemar: +1 20:43:24 and then see if we can improve any of the ones we seem to be able to "live with" 20:43:32 Let's move on to next topic ? 20:43:34 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 s/with/by/ 20:43:44 live by, that's the one 20:43:51 I confuse them 20:43:59 ttx: you and me both 20:44:02 maybe someone slightly less invested wants to moderate the updates? 20:44:05 stevemar? 20:44:14 dhellmann: happy to 20:44:19 cool, thanks 20:44:19 dhellmann: stevemar ++ 20:44:27 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 keystone has no stake here 20:44:33 stevemar: cool, if you lack rights to abandon, just let me know 20:45:02 ttx: ack 20:45:09 #action stevemar to summarize outcomes for each proposal and propose abandons 20:45:19 #topic Amend reference/PTI with supported distros 20:45:25 #link https://review.openstack.org/402940 20:45:29 EmilienM: want to introduce that one ? 20:45:35 maybe :) 20:45:39 fungi: yeah, that's kinda what I was wondering. What does the community (and the project teams) get out of this? 20:45:51 s/project/driver 20:45:59 so I want to be quick, I noticed some projects don't gate functional tests on centos7 20:46:05 mtreinish : access to vertical teams (docs, translation) 20:46:21 (fungi: we can still have pretty high requirements, like 3rd party testing) 20:46:23 and it might seem important to us to consider is, as some of our users are deploying on this platform 20:46:31 I found useful to share this feedback and propose this change 20:46:51 EmilienM : is the issue mainly that there are differences in dependencies on those platforms? or other configuration issues? 20:47:03 dhellmann: dependencies 20:47:15 dhellmann: well centos devstack is often broken because of config differences too 20:47:23 and no one ever looks at it 20:47:30 I think that's my biggest concern 20:47:34 which I think is the actual issue on that 20:47:34 the way it's phrased, it's just encouraging tests to use more of CentOs, right ? 20:47:37 devstack centos is frequently broken 20:47:37 please keep in mind my idea was not about blocking any feature because this feature wouldn't work on centos7 20:47:38 right, it's pretty much only ianw keeping that working 20:47:40 mtreinish: yeah, I was going to say that it's probably mainly dependencies but there's also something about configs 20:47:42 there are projects interested in gating on dependencies too new to be present in lts releases of either ubuntu or centos 20:47:50 and until thats' more solid, having other things depending on it seems scary 20:47:55 mordred: ++ 20:47:55 otoh ... 20:48:06 if more projects depended on it - it would potentially get more people caring 20:48:07 it's one thing if they want to develop features that can _never_ work on a platform we intend to support 20:48:11 this is all phrased as encouraging teams to do it voluntarily, right? 20:48:25 EmilienM : ^^ 20:48:31 does devstack gate itself on centos? 20:48:32 dhellmann: exactly 20:48:42 yes, it is dhellmann 20:48:46 mordred: it's nv (or experimental) because it doesn't work 20:48:49 I think 20:48:50 * mtreinish checks 20:48:58 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 I think the first step is to encourage folks to voluntarily depend on it and then improve support 20:49:04 sdague: ++ 20:49:06 mtreinish: correct 20:49:09 nv last a looked, and seemed to be passing regularly recently 20:49:10 devstack too 20:49:11 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 but I'm not too much into infra 20:49:12 clarkb wins :) 20:49:27 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 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 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 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 a.k.a I think this is a good first step 20:50:16 as a reminder, here is the existing distro support policy: http://lists.openstack.org/pipermail/openstack-dev/2012-December/004052.html 20:50:17 anyway, beside the tools, the idea was really about documenting our official platforms we like to support in our tests 20:50:27 dhellmann: for me I think it would be that devstack itself has a gating job running on centos 20:50:32 EmilienM: I think thrusting not only a second OS, but a second install & dev model on development teams is really burdensome 20:50:32 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 which I think would be a good thing to exist ... but is under-resourced 20:50:40 Rather than simply being a policy change. 20:50:52 jeblair: nice history dive 20:51:00 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 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 mordred: it breaks a bit too often for that to be the case right now 20:51:12 gate-tempest-dsvm-platform-centos7-nv ran successfully against https://review.openstack.org/404476 in <50 minutes 20:51:21 so as a reality check I don't think the proposed change is going to help anything project side 20:51:22 dhellmann: centos breaks for quite odd reasons 20:51:24 sdague: i don't disagree 20:51:28 actually, i think the thing voted on is: https://etherpad.openstack.org/p/python-support-motion 20:51:32 http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.html 20:51:32 sdague : not related to changes in devstack itself? 20:51:36 sdague: yes - I agree - mostly saying that if that is the goal then people can talk about resourcing it 20:51:54 jeblair, ttx: we should maybe get that into the governance repo? 20:51:58 fungi: but it's not running exactl the same thing, like ssl is disabled there 20:51:58 dhellmann: nope. A bunch of things take more kernel memory on centos that cause issues 20:52:09 there have been a number of odd bugs 20:52:13 ya wecan't ssl on centos because apache doesn't work 20:52:17 ok, so it sounds like it's a bit early for even suggesting ? 20:52:18 mtreinish: exciting, so there's stuff we've disabled to get it to run on centos? 20:52:21 yep 20:52:25 mordred: propose and you should get it 20:52:27 clarkb: that seems rather limiting 20:52:33 plus, the cadence is so much slower that we get drive away from the tooling that people want to be using 20:52:34 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 ttx: k. I guess I just walked in to that 20:52:43 kind of 20:52:47 stevemar: I am sure it can be made to work but no one is doing the work 20:52:53 I would blame jeblair for pushing you into it 20:53:07 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 plonk 20:53:14 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 ++ sdague 20:53:30 sdague : yeah, so we need both "sides" to agree it's a reasonable goal :-) 20:53:40 ++ dhellmann :) 20:53:44 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 of course 20:54:02 I'm thinking RH ought to be involved 20:54:03 sdague: I have faith in ianw :) 20:54:08 OK, so it sounds like it's a bit early to even suggest this 20:54:11 do you folks have #action ? we're seeing lot of things now 20:54:11 mtreinish: lol 20:54:14 ianw is great, don't get me wrong 20:54:25 ianw is amazing, but yes he should have some more support from his colleagues at rh it sounds like 20:54:26 what is the next step ? 20:54:30 dhellmann: yes, we have the resources I think 20:54:32 EmilienM : you and I should see if we can get some resources working on better centos support for devstack 20:54:47 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 I think getting some action items that would help moving this forward would be great 20:54:57 #info dhellmann and EmilienM should see if we can get some resources working on better centos support for devstack 20:54:59 dhellmann: I volunteer to work on this thing, even if I'm not a devstack fan 20:54:59 then we can try for a voting gate job, and then we can see about getting this change added 20:55:04 and an order of magnitude less on the centos side 20:55:08 ttx: thx 20:55:21 #info because it's a blocker to larger use of CentOS in test jobs 20:55:37 is the goal to duplicate all devstack jobs to run on both ubuntu and centos? is infra cool with doubling that? 20:55:40 OK, let's move on quickly to next topic 20:55:48 (I assume so but throwing it out there) 20:55:54 jroll: nah, I think it's just to have a token centos job 20:55:57 jroll: probably not entirely duplicate, no 20:55:57 jroll: I think you would matrix them, some tests on CenTOS, some on Ubuntu 20:56:03 okay cool 20:56:04 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 #topic Do not allow data plane downtime during upgrades 20:56:15 other people are more succinct :) 20:56:20 #link https://review.openstack.org/404361 20:56:27 We don't have much time to discuss it 20:56:38 probably better to put it on next week agenda 20:56:39 dolphm: around? 20:57:04 stevemar: yes 20:57:04 ttx: probably for the best 20:57:13 I think we can discuss on the review until then 20:57:20 i'm good for next week with 2 minutes left on the clock ;) 20:57:20 I agree with dhellmann's comment in the review 20:57:29 dolphm: thanks :) 20:57:36 #topic Open discussion 20:58:04 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 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 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 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 dhellmann: yah 20:58:47 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 dims : nice, thanks for the link 20:59:15 mass o' cloud ;) 20:59:16 dhellmann: that's a good point 20:59:21 dhellmann: honestly, it was kind of implied in the current tag 20:59:27 IRC meetings thread: http://lists.openstack.org/pipermail/openstack-dev/2016-December/108360.html 20:59:28 and the automated testing that you have to run to get that tag 20:59:29 :) 20:59:29 dolphm : someone else did make it in the review, so I don't get credit :-) 20:59:58 we can define data plane, if that's an issue for folks 21:00:03 no tag upgrades? 21:00:08 At the board meeting today they mentioned they might want to do a joint TC/Board meeting around the PTG 21:00:23 Though it's not really an official proposal yet 21:00:28 but fair warning 21:00:35 in the same vicinity as the ptg? 21:00:40 good to know 21:00:45 ttx: it would likely be good to communicate that most of the TC is likely to be booked all 5 weekdays 21:00:45 someone asked me tha recently 21:01:00 mordred: ++ 21:01:02 since most of the TC is fairly strongly involved in both vertical and horizontal efforts 21:01:05 yeah, could we please not double book the tc? 21:01:07 and the PTG has been planned for a while 21:01:07 thanks for the heads up ttx, will have to book flights accordingly 21:01:11 We migth have some time on the Friday 21:01:18 like, as a TC member, I will not attend that if it's during the week 21:01:25 anyway, more on that when they actually talk to me about it 21:01:30 or, i guess, if it does happen, maybe i'll just go home a day early or whatever 21:01:50 and we are offtime 21:01:54 thanks everyone 21:01:57 o/ 21:01:57 #endmeeting