20:00:59 #startmeeting tc 20:01:00 Meeting started Tue Dec 20 20:00:59 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:02 * smcginnis lurks in the corner 20:01:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:05 o/ 20:01:06 The meeting name has been set to 'tc' 20:01:09 Hi everyone! 20:01:11 Busy agenda for today, so let's try to go quick. 20:01:15 hello 20:01:21 Lots of things that would be great to finalize before the new year 20:01:22 thingee: I have many fewer babies strapped to me than you do I believe 20:01:27 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:35 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:01:38 \o 20:01:38 o/ 20:01:41 #topic Storlets to become official - Proposed governance change 20:01:42 thingee: i wouldn't let the baby type 20:01:46 #link https://review.openstack.org/353693 20:01:54 This was originally proposed in August 20:02:06 eranrom: around ? 20:02:09 back then we deferred it so that a number of requirements could be implemented 20:02:10 Hi 20:02:15 Progress was made there and tracked at: 20:02:18 #link https://etherpad.openstack.org/p/storlets-big-tent 20:02:27 I feel like this is going in the right direction and is close enough now... 20:02:28 good progress! 20:02:31 Thoughts ? 20:02:54 yeah, FWIW, I've been working with the storlets team since August and guiding them through the process 20:03:03 I appreciated that Eran did wait until significant progress was made before reapplying 20:03:05 the team was receptive and they addressed the concerns as they came 20:03:13 sounds like great progress, just a few things left to do 20:03:30 * sigmavirus sneaks in and sits in the back 20:03:39 last week was the date for membership freeze, I guess thats not a hard rule? 20:03:42 If we want Storlets in Ocata and at the Atlanta PTG this is a bit of a deadline 20:04:08 (if approved today we can still include it I think) 20:04:28 fine with making an exception 20:04:41 One of the questions is whether the current concerns are critical or not 20:04:42 maybe we should focus on the application, and figure out the deadline question if we decide to go ahead 20:04:44 EmilienM: ^ 20:04:45 looks like great progress, I'd think it's pretty clear at this point they are one of us 20:04:50 looks like it's just py35 and test stuff left -- and given storlets track record, i think they'll get it done 20:05:00 flaper87 : what's the story with java testing? are we able to support that now? 20:05:06 stevemar ++ 20:05:12 jroll +1 20:05:12 flaper87: no blocker on my side. My questions were answered correctly 20:05:15 agree stevemar 20:05:16 Are we going to require a CTI or anything like that for the Java bits? 20:05:17 stevemar: +1, and those aren't things we require today 20:05:43 cast my +1 20:05:58 dtroyer : good question 20:06:11 jroll: +1 20:06:40 dhellmann: afaik, it's a work in progress 20:06:55 eranrom: you might want to chime in a bit more on the java side of things 20:07:01 they've moved to openjdk, at least 20:07:03 CTI==Continous Test Integration? 20:07:11 consistent testing interface 20:07:13 ttx: do we have a position on java? there's some precedent with monasca 20:07:13 jroll: yes 20:07:15 I'm not thrilled with the inconsistency we have WRT languages here... 20:07:20 dtroyer : ++ 20:07:21 if so then while we are lacking unit tests we do have functional tests in place 20:07:29 well, I think this falls into the integration point rule 20:07:33 like a java sdk 20:07:46 So the java code is being regularly tested 20:07:46 #link https://governance.openstack.org/tc/reference/project-testing-interface.html 20:07:48 eranrom : we don't have a CTI documented for java: https://governance.openstack.org/tc/reference/project-testing-interface.html 20:07:51 eranrom: ^ 20:08:06 it's not a service in java, it's a workload environment 20:08:24 so while it would be great to properly test it, I don't think we need a CTI 20:08:30 yeah, fwiw, the java code is not on the service side 20:08:35 since that would be pretty unique 20:08:41 right, similar to how trove runs mysql, right? 20:08:43 ttx: right 20:08:45 jroll: yes 20:08:46 ttx: true and as eranrom said, we have a few functional for java app in workload 20:08:48 right, i think the question is whether the java-based payloads need to get tc approval as a "supported" language and have cti addition and whatnot. i thought we'd determined previously they did not 20:08:51 more like a service VM 20:08:57 s/we/storlets/ 20:09:00 ttx: yes, that's the words I wanted :) 20:09:01 jroll +1 20:09:33 fungi: otoh, I'd say no but I haven't dug too much into that thought 20:09:37 dhellmann: but yes, we migt want to clarify that distinction to explain why it's OK here 20:09:54 ttx ++ 20:10:11 for the folks storlets are aiming at, they do everything in Java, so it would be odd to require those folks to learn python 20:10:15 ttx: someone else may need to do that, because I don't see the distinction myself. It's not a *service* but it's running on the server and defines an API, so I would think we would want some form of test for it. 20:10:24 we cared enough about which SDK was used, that was only due to redistribution concerns then? 20:10:25 the "service" is really swift here. Storlets is glue code to run payloads, and the Java payloads use a Java runtime shim 20:10:49 dtroyer: yeah, that was my understanding for the openjdk bit 20:10:55 dtroyer : yeah, we can't test with the oracle jdk in the gate, IIUC 20:10:58 dtroyer: yes 20:11:04 so the only "java" produced by the storlets team is example code, it sounds like 20:11:27 fungi: last time I looked there was some glue code to expose environment bits 20:11:38 ttx: indeed, I don't think that's changed 20:11:43 plus a tiny bit of C 20:11:43 oh, got it. so a minimal shim in java 20:11:45 don't get me wrong, I'd love to see the storlets team define the java CTI and run unittests on the libraries it exposes, but I don't believe it's a blocker here 20:12:16 jroll++ 20:12:21 We have enough to approve this 20:12:23 if we ignore the CTI question, are there actually tests for the java shim? 20:12:39 ttx: I would like to get this clarified before we move on 20:12:45 dhellmann: functional tests 20:12:47 dhellmann: they run functional tests with a java workload 20:12:48 I'll let eran 20:12:50 answer 20:12:51 dhellmann: from the quick scan I just did, they test it indirectly via functional tests. But no direct unittesting or anything like that 20:13:06 mtreinish: thats what I am seeing 20:13:07 and those functional tests run in a gate job somehow? 20:13:13 yes 20:13:17 ok, then I'm satisified 20:13:18 (using ansible) 20:13:24 (and plan to use devstack iiuc) 20:13:25 thanks, eranrom 20:13:45 it's not the end of the integration journey anyway, more like a milestone 20:13:51 as long as the stuff is actually being tested, we can discuss a java CTI separately 20:14:04 since they're functional tests, that may not apply here 20:14:08 ok, any other objection before I approve ? 20:14:25 also, between storlets, monasca and the infra projects that are in java, I think we've got a good corpus to define a java CTI should we decide that's a good idea 20:14:45 ++ 20:14:52 ok, approving 20:14:54 mordred: I think ti is a good idea, not blocking here 20:14:58 ++ 20:15:03 ++ mordred dtroyer 20:15:03 eranrom: welcome! 20:15:03 mordred: sounds like a good topic for one of the cross project deiscussions 20:15:10 eranrom: totally agree 20:15:11 ttx and all: Thanks very much. 20:15:11 mordred: ++ 20:15:15 browsing the storlets src/ subtree, there's a nontrivial quantity of java under there 20:15:21 eranrom congrats and good work 20:15:27 thansk flaper87 for following up and mentoring them 20:15:27 thingee: Thanks! 20:15:27 i'm surprised it doesn't have unit tests 20:15:31 thanks all (i'm working for storlets)! 20:15:36 my pleasure 20:15:56 #topic Reference doc for new language additions 20:15:58 flaper87: Thanks for working with us on this. 20:15:59 * EmilienM thinks flaper87 has superpowers 20:16:05 I think we should encourage them to work in that direction (unit testin gthe JAva) 20:16:09 fungi: http://paste.openstack.org/show/592955/ 20:16:16 ++ dtroyer 20:16:18 o/ 20:16:27 #link https://review.openstack.org/398875 20:16:33 I like the general principles laid out here (the two-step dance) 20:16:39 so, I've addressed some of the comments and I replied to the latest comments from dhellmann ttx and dtroyer 20:16:45 thanks a bunch for commenting on it 20:17:05 I'm good with amending the current proposal and, at this point, wait till next year to approve it 20:17:09 I see it as a living document and the current version is probably good enough as an initial doc 20:17:17 I think it is pretty good shape 20:17:19 there's no rush and I'd rather give some extra time to chime in on this 20:17:21 ttx: ++ 20:17:23 (if we wanted to approve the initial version now) 20:17:35 flaper87: I'm fine with doing one more iteration, too 20:17:50 flaper87: ok, so do you have anything specific to discuss today ? 20:17:51 however, if people feel this can go in now and amends can be done in follow-up patches, I can do that too 20:17:52 probably want to drop that note at line 24 before publishing, yeah? 20:18:02 The requirements management is one of the bigger issues, so I'd like to get that written down before teams start using this process. That could still happen as a follow-up, I guess. 20:18:15 i expect we're going to end up with subsequent changes to this document before any new language makes it through the gauntlet regardless 20:18:15 ttx: not really, I've reached out to more people on IRC and there doesn't seem to be strong opposition to this proposal 20:18:27 we don't have any urgency in approvign that now rather than next meeting tbh 20:18:38 yup 20:18:44 agree ttx flaper87 20:18:48 good work flaper87 20:18:57 I'll be out next week and the one after next week so, we can postpone this till next year :) 20:19:01 thingee: danke :D 20:19:01 ok, then unless there are questions we can move on to the next topic so that we have enough time to cover everything 20:19:19 by all means, if there are more questions/concerns, this is the time. 20:19:29 but don't ruin my new years celebration 20:19:33 #info one more iteration, final approval expected at next meeting 20:19:34 thanks flaper87 20:19:45 dtroyer: my pleasure 20:20:20 ok then, moving on 20:20:23 #topic Amend reference/PTI with supported distros 20:20:27 #link https://review.openstack.org/402940 20:20:31 o/ 20:20:34 We presented this one a couple weeks ago and there were objections due to regular job failures on CentOS 20:20:41 EmilienM: floor is yours 20:21:00 well, if you have some questions or concerns about this proposal, please go ahead 20:21:05 ttx: was there any change on that? 20:21:38 it's sounded like there's some confusion over what's currently actually tested, and what needs to be tested, to move forward 20:21:39 ihar and ianw seem to have been watching more closely and think it's probably ok for single node 20:21:47 ttx: I don't have anything to add now, I think I addressed comments in the proposal 20:21:54 at least from comments in the review 20:22:23 the outstanding concern seemed to me to be over what features/tests are currently didabled to get those basic devstack-gate jobs passing 20:22:27 fungi: there is still the disparity between what's tested. But the way the proposal is worded that's not necessarily a blocker 20:22:34 s/didabled/disabled 20:22:45 I feel like the proof is probably going to come in the pudding. We've disabled voting on those jobs before when it was blocking unrelated work from moving forward 20:22:55 yeah, I think the proposal is sufficiently weakly-worded to be aspirational 20:23:15 so the question remains, what happens if we need to disable those jobs again once this resolution passes? 20:23:16 tbh, I'd rather see things being run everywhere before we merge this 20:23:19 but on those issues I like to trust our QA people judgment 20:24:27 is approving 402940 the turning point where if the job breaks we tell people to suck it up and work on fixing the job or whatever broke it because we're not going to turn it off any longer? 20:24:28 so I'm fine with this being aspirational, and realize that realities mean we're not going to shut down the ship if there is a centos issue we can't get resolved in a timely manner. 20:24:47 fungi: we can't force folks to keep the job voting, if it's blocking something. But we can assume good faith on the desire to test both platforms 20:25:14 fungi: I don't think that's the idea behind this proposal, at least not from my side 20:25:45 i guess as long as it leaves us with the same flexibility/options we have now, i'm not opposed 20:25:53 which seems to be the case 20:26:06 We have a majority now. mtreinish would rather see things being run everywhere first. Any other objection ? 20:26:06 so my feeling is always that test jobs are information to help humans make better decisions. As such, they should always be treated in an advisory capacity, and turned off when they are doing more harm than good 20:26:22 ++ sdague 20:26:28 which is true of anything that currently votes 20:26:30 sdague: yes, I do agree. 20:26:36 sgtm 20:26:37 and this would be in the same capacity 20:26:49 I would hope we would prefer fixing jobs over turning them off, but I agree with the general idea that sometimes expediency calls for turning them off 20:27:34 Alright, it feels like we have support for this to be merged now 20:27:40 dhellmann: or, you know, you pull the car over and change to a spare tire, and keep going, instead of sitting on the side of the road out of priciple 20:27:52 dhellmann: me too, though it's a matter of resources available to work on $topic. I would expect them growing if we recognize this platform as "official" in our testing 20:28:05 * dtroyer has to fix a flat after the meeting… thanks for the reminder sdague 20:28:09 :) 20:28:09 sdague : fix the tire instead of just removing it and trying to drive on 3? 20:28:16 * ttx approves 20:28:25 and moves on 20:28:26 ttx: thanks 20:28:31 #topic Driver teams: establish new "driver team" concept 20:28:32 thanks, EmilienM 20:28:41 As promised last week I pushed the "amended grey" option back to the -dev list for community comments 20:28:46 #link https://review.openstack.org/403829 20:28:47 sdague: just drive on the flat 20:28:54 There were a number of public objections, but not for the same reasons. Let me summarize them 20:29:05 jaypipes basically thinks we should not have vendor teams in OpenStack, prefers the soft black option 20:29:11 #link https://review.openstack.org/#/c/403836/ 20:29:23 It is, I think, the crux of the issue: is allowing driver teams more destructive than not allowing them ? 20:29:33 Jay Faulkner and Bob Melander advocate for a more weakly-worded clause around drivers extending APIs 20:29:43 I proposed an alternate wording in the comments, that would cover the Ironic case 20:29:52 jaypipes objects to softening the language around drivers extending APIs, but frankly I think that's a larger discussion (about interoperability and strict APIs) not really tied to driver teams in particular 20:30:02 as it affects all drivers, in-tree or out-tree. 20:30:11 I agree with anyone saying we should be stricter about APIs, fwiw 20:30:14 Next, cdent and John Davidge object to "strongly preferring" in-tree drivers 20:30:26 Which is also a good point. Drivers are using plug-in points, so why maintain some of them in-tree in the same code repository ? 20:30:37 My take on it is that you should either have all drivers out of tree, or you should strongly prefer in-tree. But having some in-tree and some out-tree with an arbitrary boundary is not really awesome. 20:30:48 ttx: +1 20:30:49 because quite a lot of our driver APIs are not well defined 20:30:50 ++ 20:30:51 John Davidge also objects to the obfuscation of brands in team names, making lives of users more miserable 20:31:04 I think this concern comes from the lack of proper driver catalogs -- people should not go through the official OpenStack team list to find their drivers 20:31:07 I think in-tree reference drivers (like LVM in the cinder case) are good to maintain 20:31:10 ttx: can you give an example? 20:31:11 if only because they won't find in-tree drivers in there 20:31:12 ttx: at least for ironic api thing I didn't see an issue with the current wording. It's not modifying the api, just using a free form vendor endpoint that ironic exposes 20:31:14 would support moving the rest 20:31:19 it's not just our driver APIs being not well defined 20:31:39 So in parallel with this we should invest in making the driver section of the OpenStack marketplace actually usable 20:31:44 And probably make sure that project docs reference drivers too. 20:31:46 many people complain that it is hard to get things into openstack 20:31:59 Andreas Scheuring and jaypipes wondered how that obfuscation might work in practice 20:32:04 if you have to coordinate feature adds across multiple git repos thaat gets so much harder 20:32:09 but I think we have a good example case with the "Winstackers" team, and we have a history of creative naming 20:32:20 OK, so let's take those one by one. First the proposed modifications to grey: 20:32:27 * Softening the language around drivers extending API. Good idea, bad idea ? 20:32:34 ttx: bad idea 20:32:37 bad idea 20:32:42 I should also point out that the text doesn't say "in tree" but "in the consuming projects" by which I meant in a repo owned by that project team 20:32:54 yeah, I'd prefer not to soften the language 20:33:03 keeping in mind that it sounds like most neutron drivers today "extend" the neutron api in at least some ways 20:33:05 should we go after Ironic for having such a capability in their drivers ? 20:33:07 the bit after the comma comes after the comment, so it's not as clear 20:33:08 +1 to not soften the language 20:33:15 fungi: don't even get me started on that 20:33:16 fungi: yep... 20:33:20 (of course, maybe that provides a lot of examples for why it's a bad idea?) 20:33:26 neutron drivers already do this, it has caused substantial pain 20:33:29 bad idea, I agree 20:33:30 ttx: oh, that would be fun :) 20:33:33 ttx: bad idea 20:33:39 ++ 20:33:39 sorry I only read this proposal just now and I'm late to the party, but out of tree drivers are terrible because they practically ensure that the interfaces can never evolve 20:33:50 I strongly prefer in-tree drivers 20:34:02 great segway 20:34:05 * "Strongly encouraging" in-tree drivers. Good idea, bad idea ? 20:34:10 ttx: I thought ironic used that API extension point for evolving new APIs 20:34:13 ttx: good idea 20:34:15 +1 20:34:25 ttx: +1 20:34:25 so cinder wants in-tree and neutron wants out-of-tree :) 20:34:29 ttx: it's not actually "in-tree" though, see my earlier comment 20:34:30 good idea 20:34:36 manila wants in-tree as well 20:34:39 * ttx reads 20:34:45 jroll: what about ironic? 20:34:50 stevemar: iiuc neutron is the only thing this really effects in practice 20:34:54 I agree more with what ttx said on this earlier - "My take on it is that you should either have all drivers out of tree, or you should strongly prefer in-tree. But having some in-tree and some out-tree with an arbitrary boundary is not really awesome" 20:34:57 dhellmann: we do use that API for that, and I'm happy to have that conversation, but I'd love to keep on this topic and talk about that later 20:35:02 mtreinish: agreed 20:35:03 because the other projects don't support out of tree drivers 20:35:16 it says "in the consuming projects and managed by the same contributors in a collaborative fashion, *whether by including drivers "in tree" or by placing them in separate repositories owned by the same team" 20:35:18 I do not agree with the objections to out of tree drivers 20:35:19 ttx: ^^ 20:35:20 in fact 20:35:22 ironic prefers in-tree drivers, but has CI requirements for those, and allows out-of-tree drivers for drivers that do not have CI 20:35:23 dhellmann: oh right 20:35:31 it's about repo ownership 20:35:40 I tihnk we should strongly encourage driver APIs to be treated like apis so that people who want out of tree drivers can without being screwed 20:35:40 dhellmann: got it 20:35:43 my take on it is that there are always going to be some out-of-tree drivers because they're developed by third parties, possibly even outside the community entirely 20:35:49 fungi: ++ 20:35:53 yeah, then I'm not convinced by that objection 20:35:54 ironic also tries to keep the driver API stable, but doesn't make promises (though we'd love to get there) 20:36:05 * Brand obfuscation in team names. Good idea, bad idea ? 20:36:08 right, the point of this phrase is we want to encourage teams to do things in a way that makes it less painful, not more 20:36:11 as to whether or not we encourage that, or consider such drivers in need of "official recognition" by the tc, i'm unsure 20:36:18 and to encourage collaboration, not more driver teams 20:36:21 fungi: except in projects like nova that actively write code to disallow loading out-of-tree drivers :) 20:36:34 ttx: I thnk brand obfuscation is a tricky subject 20:36:35 mordred: forget about screwing driver developers -- it's the driver developers that are screwing the projects (in some cases) 20:36:46 fungi: (but then people will just patch the tree, etc, you can't win) 20:36:49 jroll: Same for Cinder re: "tried to keep the driver API stable, but doesn't make promises" 20:36:50 jroll: which can be "solved" by also distributing a nova fork, probably happens 20:36:54 yep 20:36:56 right, thath 20:37:09 jroll: there is still a hook for loading out of tree drivers 20:37:13 mordred: I added it after dsicussing with fungi ways to avoid to turn the project team list into a walking billboard 20:37:34 we do tell people it's not officially supported and they should be working in the community instead 20:37:41 ttx: for instance, it's entirely possible the nova-docker driver could hit legal issues with docker inc's move to make 'docker' all about the company and we could run in to a situation where a team who cared aout that would not be able to legally call themselves the docker team 20:37:42 sdague: I'm skeptical, would love to see that after the meeting 20:37:45 in short, any time we give companies a place to list themselves, everyone wants to avoid being outdone by their competitors and looks for a way to get added to the list 20:37:50 I like the team name vs repo name distinction, didn't catch that the first time through 20:38:10 dtroyer: ++ 20:38:13 mordred: the nova docker driver that is abandoned? 20:38:38 fungi : will we also forbid the use of trademarks in the team mission descriptions? 20:38:40 sdague: irrelevant for the purposes of example of why naming a driver team after a thing that is trademarked can be problematic 20:38:43 I guess it's easy to change our stance on the brand obfuscation thing. Team renames are cheap 20:38:56 sdague: there is a clone of it in the zun repo. It'll never die :) 20:38:57 I'm willing to give it a try though 20:39:02 mordred: i'm honestly less concerned about legal ramifications of trademarks appearing in team names. that concern possibly also applies to deliverable/repo names which we aren't proposing any restrictions on 20:39:02 I just don't think we know enough to make a hard rule on that 20:39:11 for reasons outlined by fungi 20:39:18 fungi: so reading your comments, you'd be okay with a 'bar' team that has a neutron-foo driver, to support foo branded switches, but not okay with a foo team doing that, correct? 20:39:46 or ttx ^ 20:39:52 jroll: yes 20:39:59 ok, thanks 20:40:08 jroll: basically, yes. a lot of that is because we have one place we list all team names, but we don't list the deliverables for all projects in one place (except in structured data files where the proposal intermixes them with normal teams) 20:40:14 * jroll doesn't have a strong opinion, then 20:40:16 it will be interesting to see what effect, if any, the obfuscation rule has 20:40:24 jroll: think Winstackers doing a nova-hyperv repo 20:40:31 ttx: good example, thanks 20:40:39 dhellmann: as I said we can easily come back on that one 20:40:43 yeah 20:40:45 OK, so that leaves us with the crux described above. Do we want vendor-led driver teams or not 20:40:51 If we do, I would argue that grey is now looking like a reasonable compromise. If we don't, we should pick soft black 20:41:00 +1 to no trademarks in the team/deliverable/repo names for vendor led teams 20:41:18 I think they are valuable, although I totally understand the concerns with their existence 20:41:20 so far the only official teams we have with trademarked terms in their names are also the names of free software projects which just happen to be trademarked, which i find less objectionable 20:41:21 * dims remembers java.apache.org -> jakarta.apache.org 20:41:27 jaypipes makes a good case that it could be harmful. it's just difficult to judge which option is actually the most destructive 20:41:35 I can live with vendor-led teams as a fallback, still like the idea that they should be considered that and not a frist choice 20:41:49 dtroyer: ++ 20:41:50 right, dtroyer, I think given that we're not going to just accept all teams, that they have to go through the consuming project first, it will be manageable. 20:41:50 dtroyer : yep 20:42:28 worth noting, the grey option is still my third choice. but the proposal is one i could support if there is sufficient backing from the rest of the tc 20:42:33 To me the question is, are we going to get more core contributions by having them in, or by keeping them out 20:43:02 (by core I mean contributions to the consuming service) 20:43:19 given the (perception at least) of the current corporate climate, we're going to see a lot of minimal amount of effort stuff I am afraid 20:43:36 dtroyer: good point 20:43:59 I'm leaning towards in. I don't think keeping them out is not really going to help with getting more contributions, I think 20:44:02 I suppose if we say no to the teams, we just wouldn't see their efforts at all. 20:44:07 I don't think core contributions is the only thing that's relevant - I think empowering our consumers to use the hardware items they want to use is also important, and sometimes that may involve empowering the vendor of that thing to maintain something nobody else cares about 20:44:18 another way to put it would be... will we get enough extra core contributions to justify compromising on our open collaboration principles 20:44:19 even if we don't like that vendor 20:44:21 mordred : yes, good point 20:44:24 my opinion, driver team option is a safety valve to keep folks in. so +1 20:44:26 idk. with the cisco team as a specific example, sambetts is an ironic core, that team cares about cisco stuff working in the entire openstack ecosystem, not just their neutron driver 20:44:28 mordred: +1 20:44:31 i mostly just want to make sure that companies coming to us trying to get their "driver team" listed to raise their visibility have somewhere "better" we can direct them (e.g., driver marketplace on www.o.o) 20:44:40 fungi: + 20:44:42 fungi: ++ 20:44:44 sam is a heavy driver (heh) of a lot of ironic's networking work 20:45:04 jroll: yes. that is the healthy way to do things and what we should _always_ prefer 20:45:07 jroll : I think it speaks highly that they asked to be an official team under the existing rules. 20:45:08 right, if the source code lives in gerrit, it means that users are empowered even if their vendor abandons the effort down the road. There is a collaboration space 20:45:13 what I do like about the driver teams is that ensures that the cose as it stands is available for customers should the vendor disappear. it isn't sufficient, but better than it being buried and possibly disappeared on github in that case 20:45:20 s/cose/code/ 20:45:21 dtroyer: ++ 20:45:23 (I can't speak for other vendor teams, of course) 20:45:44 and it's part of the workflow that lets someone understand how to work on common code 20:45:52 also - a vendor who wants a driver team to be official is saying that they'd LIKE non-company people - they may just not have any 20:45:58 dtroyer: the irony there is that if the vendor abandons that repo and some other unrelated team takes it over, they could probably qualify as an official team under our existing rules ;) 20:46:12 I like this grey option in that the TC will prefer to try to get the team to work with the project they plug into first, and being a separate team as a fallback 20:46:14 if a company wants to do out of tree drivers just with themselves, the overhead to doing things 'officially' is silly for them to carry 20:46:16 To avoid the "contributes only to their driver team and consider it's contributing enough to openstack as a result" -- we could list driver teams ina subcategory in stackalytics 20:46:20 allows folks on both sides to document why it doesn't fit 20:46:25 because, our workflow is different enough from what's considered norms today, that any additional ways to get there are good 20:46:28 fungi: I would hope in that case moving back into the project team oversight is what happens 20:46:34 jroll: indeed 20:46:44 it feels like we should welcome them into the community to learn form each other on how to be successful at doing this thing, I don't want to exclude them, it hurts our users wanting to use their things if they do it badly 20:46:53 dtroyer: if the consuming project team would allow it, but some do not want that added responsibility 20:46:56 johnthetubaguy : ++ 20:47:05 ok, I feel a group leaning toward "in" 20:47:12 * dhellmann is happy to see others making the same arguments that led to starting this whole mess 20:47:13 johnthetubaguy: ++ 20:47:29 I can live by both outcomes at this point (grey or softblack) 20:47:30 dhellmann: :) 20:47:42 at least its explicitly messy 20:47:47 (now) 20:47:51 any other advocate for "out" ? 20:48:06 what I'm still struggling with is what "in" actually means here, and the benefits it provides a driver team 20:48:13 (Because if I read your previous answers I should actually not modify grey) 20:48:28 like the infra workflow was always available to them as was hosting a repo in openstack/ 20:48:40 mtreinish: they become an official openstack project team, with controlled /limited scope 20:48:41 mtreinish : access to horizontal teams 20:48:49 mtreinish: vote for TC 20:48:58 mtreinish: docs.openstack.org access is the main thing people want, from what I've heard 20:48:59 PTG space 20:49:03 thanks for asking mtreinish 20:49:26 so docs.o.o, a tc vote, and ptg access? 20:49:27 mtreinish : they're asking to be "in". We don't currently say there must be a benefit to any other teams asking to join. 20:49:29 jroll: the part of docs.o.o? the developer docs? or guides? 20:49:31 ATC/PTG, folks are happy to have, but don't care as much, afaict 20:49:33 jroll +1 heard that from neutron folks 20:49:50 stevemar: being able to publish anything anywhere on that site (primarily dev docs, but now install guide plugins etc) 20:49:57 I think these are people who have banked a bunch on openstack, and they want us to consider them one of us 20:49:59 * stevemar nods 20:49:59 dhellmann: well in this case it matters because we're defining a new subset of projects that is different 20:50:02 stevemar vendors want to be able to document setting up an environment with their drivers. 20:50:20 thingee: that sounds perfectly reasonable 20:50:30 mtreinish : why does that make it matter? are you worried we're giving up too much somehow? 20:50:34 I agree. current rules disallow neutron drivers today though 20:50:35 If you made your decision can you cast your +1 for either proposal ? Just so that we know where we stand 20:51:09 Looks like overwhelming support for grey as it stands 20:51:23 one remaining concern i have with the grey option is that it may imply, to teams who end up developing drivers without skewed employer affiliation using publicly available specifications and/or reverse-engineering, that they're supposed to apply as a driver team and don't realize they could be full-fledged project teams 20:51:33 I'm fine approving it now since we covered all the objections that were raised and decided to bypass them 20:51:48 dhellmann: I am concerned about that because these teams are very specifically about a single product. The level playing field thing is there for a reason 20:51:50 fungi : we can guide them when they apply for status 20:52:10 agree dhellmann 20:52:17 dhellmann: yes, i hope we'll be aware enough to do so 20:52:23 yes we need to accompany those, and probably write a bunch for the project team guide 20:52:26 mtreinish : are you concerned about what the teams get, or what we get? I don't see how the single product question is related to your earlier question. 20:52:34 mtreinish: yah - I do not think we should allow single-vendor services 20:52:58 I also don't think we should keep driver teams if they do not accept valid contributions from outside the vendor. 20:53:03 mordred mtreinish ++ 20:53:04 dhellmann: ++ 20:53:11 dhellmann: we should maybe encode that 20:53:16 dhellmann: I'm trying to weigh what the community gets vs what the vendor gets 20:53:21 perhaps, I had trouble coming up with wording 20:53:23 ok, should we approve this now or discuss it one more time 20:53:26 dhellmann: fair 20:53:35 because I have stuff to discuss in open discussion 20:53:45 mtreinish : so you're worried that vendors will ask to live under our rules and somehow hoodwink us into giving them more benefit than we get? 20:53:53 dhellmann: I feel like the outside contributions thing is part of "open development" 20:54:00 ttx: ok 20:54:05 jroll : yep 20:54:06 i'm okay pressing forward. while grey is not my preference, my concerns are addressed sufficiently by it 20:54:23 I'm ok with the proposal as it is 20:54:33 ttx: is today the cutoff for driver teams getting ptg space? 20:54:37 y, already has my +1 20:54:44 same 20:54:51 stevemar: not really. But some teams have been patiently waiting that we get our house in order 20:55:19 mtreinish: ? 20:55:25 can you live by it ? 20:55:28 gotcha 20:55:45 ttx: I'd be fine with it. But I still have concerns 20:55:59 * fungi still finds those leadership training catchphrases mildly creepy 20:56:11 concerns that we can address in subsequent changes ? 20:56:29 I'm not sure, I think it's a more fundamental question about why 20:56:33 ttx: perhaps we should postpone it till next year with the language one 20:56:43 ok, let's not rush it 20:56:47 yes, four mins left too 20:56:47 #topic Open discussion 20:56:53 * Joint TC/Board meeting 20:57:02 I had an exchange with Alan and we agreed that tacking a half-day at the start or the end of a long PTG week wasn't likely to deliver the desired results 20:57:12 like I think the rules outlined make sense, I'm just worried about the implications of it 20:57:15 They are now looking into a specific 1-day or 2-day workshop to make progress on the "OpenStack futures" discussion 20:57:19 Which might be tied to a future ops meetup or OpenStack Day or leadership training to make the trip worthwhile 20:57:29 Long story short, won't happen on Sunday or Friday of the PTG, so you can book your flights 20:57:36 great thanks ttx 20:57:42 (I'll likely arrive Saturday afternoon, so I'm happy to see people on Sunday) 20:57:44 Tying it to something is very appealing for those of us who wish to observe. 20:57:55 * Election officials for Pike PTL elections 20:58:00 We have volunteers to be "officials": tristanC & diablo_rojo 20:58:06 (They said they would not run for PTL election) 20:58:13 persia: ++ 20:58:16 If you don't have objections, I propose we let them start organizing since we don't have that much time left 20:58:20 ttx: ++ 20:58:23 ++ 20:58:28 * Skipping next two meetings 20:58:32 thanks for volunteering, tristanC and diablo_rojo! 20:58:32 Dec 27 is likely to be lightly-attended 20:58:36 ++ ttx 20:58:36 ttx: no objection 20:58:39 Jan 3... we could have a meeting then, especially since we now have a bit of a backlog 20:58:43 you tell me 20:58:43 ++ for both of those 20:58:45 +1 to skip 20:58:53 +1 20:58:57 +1 on Jan 3 next meeting 20:59:02 +1 to skip the 27th and meet on Jan 3 20:59:07 +1 to Jan 3 20:59:14 yeah, 3rd seems fine for me 20:59:15 i'll need excusing from any meeting on the 27th but am available for the 3rd 20:59:16 I'll be out on Jan 3, likely 20:59:20 wait, I thought we would meet and celebrate together 20:59:23 oh well, +1 then :-) 20:59:29 let's close the driver-team stuff on Jan 3rd ? 20:59:29 +1 to skip 27th, next meeting jan 3 20:59:35 mtreinish: you'll be around ? 20:59:42 on jan 3rd? 20:59:43 yeah 20:59:47 ok 20:59:50 +1 for skip 27th 20:59:55 #agreed skip the 27th and meet on Jan 3 21:00:00 Anything else, anyone ? 21:00:11 with 0 seconds left ? 21:00:15 he says at the buzzer :) 21:00:21 #endmeeting