20:00:59 <ttx> #startmeeting tc
20:01:00 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:05 <dhellmann> o/
20:01:06 <openstack> The meeting name has been set to 'tc'
20:01:09 <ttx> Hi everyone!
20:01:11 <ttx> Busy agenda for today, so let's try to go quick.
20:01:15 <kota_> hello
20:01:21 <ttx> Lots of things that would be great to finalize before the new year
20:01:22 <mordred> thingee: I have many fewer babies strapped to me than you do I believe
20:01:27 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:35 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:01:38 <jroll> \o
20:01:38 <sdague> o/
20:01:41 <ttx> #topic Storlets to become official - Proposed governance change
20:01:42 <stevemar> thingee: i wouldn't let the baby type
20:01:46 <ttx> #link https://review.openstack.org/353693
20:01:54 <ttx> This was originally proposed in August
20:02:06 <flaper87> eranrom: around ?
20:02:09 <ttx> back then we deferred it so that a number of requirements could be implemented
20:02:10 <eranrom> Hi
20:02:15 <ttx> Progress was made there and tracked at:
20:02:18 <ttx> #link https://etherpad.openstack.org/p/storlets-big-tent
20:02:27 <ttx> I feel like this is going in the right direction and is close enough now...
20:02:28 <thingee> good progress!
20:02:31 <ttx> Thoughts ?
20:02:54 <flaper87> yeah, FWIW, I've been working with the storlets team since August and guiding them through the process
20:03:03 <ttx> I appreciated that Eran did wait until significant progress was made before reapplying
20:03:05 <flaper87> the team was receptive and they addressed the concerns as they came
20:03:13 <stevemar> 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 <johnthetubaguy> last week was the date for membership freeze, I guess thats not a hard rule?
20:03:42 <ttx> If we want Storlets in Ocata and at the Atlanta PTG this is a bit of a deadline
20:04:08 <ttx> (if approved today we can still include it I think)
20:04:28 <thingee> fine with making an exception
20:04:41 <flaper87> One of the questions is whether the current concerns are critical or not
20:04:42 <dhellmann> maybe we should focus on the application, and figure out the deadline question if we decide to go ahead
20:04:44 <flaper87> EmilienM: ^
20:04:45 <jroll> looks like great progress, I'd think it's pretty clear at this point they are one of us
20:04:50 <stevemar> 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 <dhellmann> flaper87 : what's the story with java testing? are we able to support that now?
20:05:06 <thingee> stevemar ++
20:05:12 <johnthetubaguy> jroll +1
20:05:12 <EmilienM> flaper87: no blocker on my side. My questions were answered correctly
20:05:15 <dims> agree stevemar
20:05:16 <dtroyer> Are we going to require a CTI or anything like that for the Java bits?
20:05:17 <jroll> stevemar: +1, and those aren't things we require today
20:05:43 <dims> cast my +1
20:05:58 <dhellmann> dtroyer : good question
20:06:11 <EmilienM> jroll: +1
20:06:40 <flaper87> dhellmann: afaik, it's a work in progress
20:06:55 <flaper87> eranrom: you might want to chime in a bit more on the java side of things
20:07:01 <jroll> they've moved to openjdk, at least
20:07:03 <eranrom> CTI==Continous Test Integration?
20:07:11 <fungi> consistent testing interface
20:07:13 <dhellmann> ttx: do we have a position on java? there's some precedent with monasca
20:07:13 <flaper87> jroll: yes
20:07:15 <dtroyer> I'm not thrilled with the inconsistency we have WRT languages here...
20:07:20 <dhellmann> dtroyer : ++
20:07:21 <eranrom> if so then while we are lacking unit tests we do have functional tests in place
20:07:29 <ttx> well, I think this falls into the integration point rule
20:07:33 <ttx> like a java sdk
20:07:46 <eranrom> So the java code is being regularly tested
20:07:46 <fungi> #link https://governance.openstack.org/tc/reference/project-testing-interface.html
20:07:48 <dhellmann> eranrom : we don't have a CTI documented for java: https://governance.openstack.org/tc/reference/project-testing-interface.html
20:07:51 <fungi> eranrom: ^
20:08:06 <ttx> it's not a service in java, it's a workload environment
20:08:24 <ttx> so while it would be great to properly test it, I don't think we need a CTI
20:08:30 <flaper87> yeah, fwiw, the java code is not on the service side
20:08:35 <ttx> since that would be pretty unique
20:08:41 <jroll> right, similar to how trove runs mysql, right?
20:08:43 <EmilienM> ttx: right
20:08:45 <ttx> jroll: yes
20:08:46 <kota_> ttx: true and as eranrom said, we have a few functional for java app in workload
20:08:48 <fungi> 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 <ttx> more like a service VM
20:08:57 <kota_> s/we/storlets/
20:09:00 <jroll> ttx: yes, that's the words I wanted :)
20:09:01 <johnthetubaguy> jroll +1
20:09:33 <flaper87> fungi: otoh, I'd say no but I haven't dug too much into that thought
20:09:37 <ttx> dhellmann: but yes, we migt want to clarify that distinction to explain why it's OK here
20:09:54 <thingee> ttx ++
20:10:11 <johnthetubaguy> 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 <dhellmann> 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 <dtroyer> we cared enough about which SDK was used, that was only due to redistribution concerns then?
20:10:25 <ttx> 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 <mtreinish> dtroyer: yeah, that was my understanding for the openjdk bit
20:10:55 <dhellmann> dtroyer : yeah, we can't test with the oracle jdk in the gate, IIUC
20:10:58 <ttx> dtroyer: yes
20:11:04 <fungi> so the only "java" produced by the storlets team is example code, it sounds like
20:11:27 <ttx> fungi: last time I looked there was some glue code to expose environment bits
20:11:38 <flaper87> ttx: indeed, I don't think that's changed
20:11:43 <dtroyer> plus a tiny bit of C
20:11:43 <fungi> oh, got it. so a minimal shim in java
20:11:45 <jroll> 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 <ttx> jroll++
20:12:21 <ttx> We have enough to approve this
20:12:23 <dhellmann> if we ignore the CTI question, are there actually tests for the java shim?
20:12:39 <dhellmann> ttx: I would like to get this clarified before we move on
20:12:45 <eranrom> dhellmann: functional tests
20:12:47 <jroll> dhellmann: they run functional tests with a java workload
20:12:48 <ttx> I'll let eran
20:12:50 <ttx> answer
20:12:51 <mtreinish> 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 <johnthetubaguy> mtreinish: thats what I am seeing
20:13:07 <dhellmann> and those functional tests run in a gate job somehow?
20:13:13 <eranrom> yes
20:13:17 <dhellmann> ok, then I'm satisified
20:13:18 <EmilienM> (using ansible)
20:13:24 <EmilienM> (and plan to use devstack iiuc)
20:13:25 <dhellmann> thanks, eranrom
20:13:45 <ttx> it's not the end of the integration journey anyway, more like a milestone
20:13:51 <dhellmann> as long as the stuff is actually being tested, we can discuss a java CTI separately
20:14:04 <dhellmann> since they're functional tests, that may not apply here
20:14:08 <ttx> ok, any other objection before I approve ?
20:14:25 <mordred> 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 <dhellmann> ++
20:14:52 <ttx> ok, approving
20:14:54 <dtroyer> mordred: I think ti is a good idea, not blocking here
20:14:58 <mordred> ++
20:15:03 <dims> ++ mordred dtroyer
20:15:03 <ttx> eranrom: welcome!
20:15:03 <eranrom> mordred: sounds like a good topic for one of the cross project deiscussions
20:15:10 <mordred> eranrom: totally agree
20:15:11 <eranrom> ttx and all: Thanks very much.
20:15:11 <jroll> mordred: ++
20:15:15 <fungi> browsing the storlets src/ subtree, there's a nontrivial quantity of java under there
20:15:21 <thingee> eranrom congrats and good work
20:15:27 <ttx> thansk flaper87 for following up and mentoring them
20:15:27 <eranrom> thingee: Thanks!
20:15:27 <fungi> i'm surprised it doesn't have unit tests
20:15:31 <kota_> thanks all (i'm working for storlets)!
20:15:36 <flaper87> my pleasure
20:15:56 <ttx> #topic Reference doc for new language additions
20:15:58 <eranrom> flaper87: Thanks for working with us on this.
20:15:59 * EmilienM thinks flaper87 has superpowers
20:16:05 <dtroyer> I think we should encourage them to work in that direction (unit testin gthe JAva)
20:16:09 <mtreinish> fungi: http://paste.openstack.org/show/592955/
20:16:16 <dims> ++ dtroyer
20:16:18 <flaper87> o/
20:16:27 <ttx> #link https://review.openstack.org/398875
20:16:33 <ttx> I like the general principles laid out here (the two-step dance)
20:16:39 <flaper87> so, I've addressed some of the comments and I replied to the latest comments from dhellmann ttx and dtroyer
20:16:45 <flaper87> thanks a bunch for commenting on it
20:17:05 <flaper87> I'm good with amending the current proposal and, at this point, wait till next year to approve it
20:17:09 <ttx> I see it as a living document and the current version is probably good enough as an initial doc
20:17:17 <dtroyer> I think it is pretty good shape
20:17:19 <flaper87> there's no rush and I'd rather give some extra time to chime in on this
20:17:21 <dtroyer> ttx: ++
20:17:23 <ttx> (if we wanted to approve the initial version now)
20:17:35 <ttx> flaper87: I'm fine with doing one more iteration, too
20:17:50 <ttx> flaper87: ok, so do you have anything specific to discuss today ?
20:17:51 <flaper87> 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 <jroll> probably want to drop that note at line 24 before publishing, yeah?
20:18:02 <dhellmann> 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 <fungi> 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 <flaper87> 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 <ttx> we don't have any urgency in approvign that now rather than next meeting tbh
20:18:38 <flaper87> yup
20:18:44 <dims> agree ttx flaper87
20:18:48 <thingee> good work flaper87
20:18:57 <flaper87> I'll be out next week and the one after next week so, we can postpone this till next year :)
20:19:01 <flaper87> thingee: danke :D
20:19:01 <ttx> 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 <flaper87> by all means, if there are more questions/concerns, this is the time.
20:19:29 <flaper87> but don't ruin my new years celebration
20:19:33 <ttx> #info one more iteration, final approval expected at next meeting
20:19:34 <dtroyer> thanks flaper87
20:19:45 <flaper87> dtroyer: my pleasure
20:20:20 <ttx> ok then, moving on
20:20:23 <ttx> #topic Amend reference/PTI with supported distros
20:20:27 <ttx> #link https://review.openstack.org/402940
20:20:31 <EmilienM> o/
20:20:34 <ttx> We presented this one a couple weeks ago and there were objections due to regular job failures on CentOS
20:20:41 <ttx> EmilienM: floor is yours
20:21:00 <EmilienM> well, if you have some questions or concerns about this proposal, please go ahead
20:21:05 <mtreinish> ttx: was there any change on that?
20:21:38 <fungi> 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 <sdague> ihar and ianw seem to have been watching more closely and think it's probably ok for single node
20:21:47 <EmilienM> ttx: I don't have anything to add now, I think I addressed comments in the proposal
20:21:54 <sdague> at least from comments in the review
20:22:23 <fungi> 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 <mtreinish> 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 <fungi> s/didabled/disabled
20:22:45 <sdague> 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 <ttx> yeah, I think the proposal is sufficiently weakly-worded to be aspirational
20:23:15 <fungi> so the question remains, what happens if we need to disable those jobs again once this resolution passes?
20:23:16 <mtreinish> tbh, I'd rather see things being run everywhere before we merge this
20:23:19 <ttx> but on those issues I like to trust our QA people judgment
20:24:27 <fungi> 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 <sdague> 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 <EmilienM> 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 <EmilienM> fungi: I don't think that's the idea behind this proposal, at least not from my side
20:25:45 <fungi> i guess as long as it leaves us with the same flexibility/options we have now, i'm not opposed
20:25:53 <fungi> which seems to be the case
20:26:06 <ttx> We have a majority now. mtreinish would rather see things being run everywhere first. Any other objection ?
20:26:06 <sdague> 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 <dims> ++ sdague
20:26:28 <sdague> which is true of anything that currently votes
20:26:30 <EmilienM> sdague: yes, I do agree.
20:26:36 <fungi> sgtm
20:26:37 <sdague> and this would be in the same capacity
20:26:49 <dhellmann> 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 <ttx> Alright, it feels like we have support for this to be merged now
20:27:40 <sdague> 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 <EmilienM> 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 <sdague> :)
20:28:09 <dhellmann> sdague : fix the tire instead of just removing it and trying to drive on 3?
20:28:16 * ttx approves
20:28:25 <ttx> and moves on
20:28:26 <EmilienM> ttx: thanks
20:28:31 <ttx> #topic Driver teams: establish new "driver team" concept
20:28:32 <dhellmann> thanks, EmilienM
20:28:41 <ttx> As promised last week I pushed the "amended grey" option back to the -dev list for community comments
20:28:46 <ttx> #link https://review.openstack.org/403829
20:28:47 <mordred> sdague: just drive on the flat
20:28:54 <ttx> There were a number of public objections, but not for the same reasons. Let me summarize them
20:29:05 <ttx> jaypipes basically thinks we should not have vendor teams in OpenStack, prefers the soft black option
20:29:11 <ttx> #link https://review.openstack.org/#/c/403836/
20:29:23 <ttx> It is, I think, the crux of the issue: is allowing driver teams more destructive than not allowing them ?
20:29:33 <ttx> Jay Faulkner and Bob Melander advocate for a more weakly-worded clause around drivers extending APIs
20:29:43 <ttx> I proposed an alternate wording in the comments, that would cover the Ironic case
20:29:52 <ttx> 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 <ttx> as it affects all drivers, in-tree or out-tree.
20:30:11 <mordred> I agree with anyone saying we should be stricter about APIs, fwiw
20:30:14 <ttx> Next, cdent and John Davidge object to "strongly preferring" in-tree drivers
20:30:26 <ttx> 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 <ttx> 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 <smcginnis> ttx: +1
20:30:49 <dhellmann> because quite a lot of our driver APIs are not well defined
20:30:50 <mordred> ++
20:30:51 <ttx> John Davidge also objects to the obfuscation of brands in team names, making lives of users more miserable
20:31:04 <ttx> 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 <dtroyer> I think in-tree reference drivers (like LVM in the cinder case) are good to maintain
20:31:10 <mordred> ttx: can you give an example?
20:31:11 <ttx> if only because they won't find in-tree drivers in there
20:31:12 <mtreinish> 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 <dtroyer> would support moving the rest
20:31:19 <sdague> it's not just our driver APIs being not well defined
20:31:39 <ttx> So in parallel with this we should invest in making the driver section of the OpenStack marketplace actually usable
20:31:44 <ttx> And probably make sure that project docs reference drivers too.
20:31:46 <sdague> many people complain that it is hard to get things into openstack
20:31:59 <ttx> Andreas Scheuring and jaypipes wondered how that obfuscation might work in practice
20:32:04 <sdague> if you have to coordinate feature adds across multiple git repos thaat gets so much harder
20:32:09 <ttx> but I think we have a good example case with the "Winstackers" team, and we have a history of creative naming
20:32:20 <ttx> OK, so let's take those one by one. First the proposed modifications to grey:
20:32:27 <ttx> * Softening the language around drivers extending API. Good idea, bad idea ?
20:32:34 <mtreinish> ttx: bad idea
20:32:37 <mordred> bad idea
20:32:42 <dhellmann> 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 <flaper87> yeah, I'd prefer not to soften the language
20:33:03 <fungi> keeping in mind that it sounds like most neutron drivers today "extend" the neutron api in at least some ways
20:33:05 <ttx> should we go after Ironic for having such a capability in their drivers ?
20:33:07 <dhellmann> the bit after the comma comes after the comment, so it's not as clear
20:33:08 <dims> +1 to not soften the language
20:33:15 <mordred> fungi: don't even get me started on that
20:33:16 <mtreinish> fungi: yep...
20:33:20 <fungi> (of course, maybe that provides a lot of examples for why it's a bad idea?)
20:33:26 <sdague> neutron drivers already do this, it has caused substantial pain
20:33:29 <EmilienM> bad idea, I agree
20:33:30 <jroll> ttx: oh, that would be fun :)
20:33:33 <sdague> ttx: bad idea
20:33:39 <dtroyer> ++
20:33:39 <bswartz> 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 <bswartz> I strongly prefer in-tree drivers
20:34:02 <ttx> great segway
20:34:05 <ttx> * "Strongly encouraging" in-tree drivers. Good idea, bad idea ?
20:34:10 <dhellmann> ttx: I thought ironic used that API extension point for evolving new APIs
20:34:13 <sdague> ttx: good idea
20:34:15 <EmilienM> +1
20:34:25 <flaper87> ttx: +1
20:34:25 <stevemar> so cinder wants in-tree and neutron wants out-of-tree :)
20:34:29 <dhellmann> ttx: it's not actually "in-tree" though, see my earlier comment
20:34:30 <dims> good idea
20:34:36 <bswartz> manila wants in-tree as well
20:34:39 * ttx reads
20:34:45 <stevemar> jroll: what about ironic?
20:34:50 <mtreinish> stevemar: iiuc neutron is the only thing this really effects in practice
20:34:54 <mordred> 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 <jroll> 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 <stevemar> mtreinish: agreed
20:35:03 <mtreinish> because the other projects don't support out of tree drivers
20:35:16 <dhellmann> 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 <mordred> I do not agree with the objections to out of tree drivers
20:35:19 <dhellmann> ttx: ^^
20:35:20 <mordred> in fact
20:35:22 <jroll> 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 <ttx> dhellmann: oh right
20:35:31 <dhellmann> it's about repo ownership
20:35:40 <mordred> 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 <ttx> dhellmann: got it
20:35:43 <fungi> 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 <mordred> fungi: ++
20:35:53 <ttx> yeah, then I'm not convinced by that objection
20:35:54 <jroll> ironic also tries to keep the driver API stable, but doesn't make promises (though we'd love to get there)
20:36:05 <ttx> * Brand obfuscation in team names. Good idea, bad idea ?
20:36:08 <dhellmann> 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 <fungi> 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 <dhellmann> and to encourage collaboration, not more driver teams
20:36:21 <jroll> fungi: except in projects like nova that actively write code to disallow loading out-of-tree drivers :)
20:36:34 <mordred> ttx: I thnk brand obfuscation is a tricky subject
20:36:35 <bswartz> mordred: forget about screwing driver developers -- it's the driver developers that are screwing the projects (in some cases)
20:36:46 <jroll> fungi: (but then people will just patch the tree, etc, you can't win)
20:36:49 <smcginnis> jroll: Same for Cinder re: "tried to keep the driver API stable, but doesn't make promises"
20:36:50 <fungi> jroll: which can be "solved" by also distributing a nova fork, probably happens
20:36:54 <jroll> yep
20:36:56 <fungi> right, thath
20:37:09 <sdague> jroll: there is still a hook for loading out of tree drivers
20:37:13 <ttx> mordred: I added it after dsicussing with fungi ways to avoid to turn the project team list into a walking billboard
20:37:34 <sdague> we do tell people it's not officially supported and they should be working in the community instead
20:37:41 <mordred> 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 <jroll> sdague: I'm skeptical, would love to see that after the meeting
20:37:45 <fungi> 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 <dtroyer> I like the team name vs repo name distinction, didn't catch that the first time through
20:38:10 <ttx> dtroyer: ++
20:38:13 <sdague> mordred: the nova docker driver that is abandoned?
20:38:38 <dhellmann> fungi : will we also forbid the use of trademarks in the team mission descriptions?
20:38:40 <mordred> 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 <ttx> I guess it's easy to change our stance on the brand obfuscation thing. Team renames are cheap
20:38:56 <mtreinish> sdague: there is a clone of it in the zun repo. It'll never die :)
20:38:57 <ttx> I'm willing to give it a try though
20:39:02 <fungi> 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 <mordred> I just don't think we know enough to make a hard rule on that
20:39:11 <ttx> for reasons outlined by fungi
20:39:18 <jroll> 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 <jroll> or ttx ^
20:39:52 <ttx> jroll: yes
20:39:59 <jroll> ok, thanks
20:40:08 <fungi> 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 <dhellmann> it will be interesting to see what effect, if any, the obfuscation rule has
20:40:24 <ttx> jroll: think Winstackers doing a nova-hyperv repo
20:40:31 <jroll> ttx: good example, thanks
20:40:39 <ttx> dhellmann: as I said we can easily come back on that one
20:40:43 <dhellmann> yeah
20:40:45 <ttx> OK, so that leaves us with the crux described above. Do we want vendor-led driver teams or not
20:40:51 <ttx> 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 <dims> +1 to no trademarks in the team/deliverable/repo names for vendor led teams
20:41:18 <mordred> I think they are valuable, although I totally understand the concerns with their existence
20:41:20 <fungi> 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 <ttx> 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 <dtroyer> 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 <mordred> dtroyer: ++
20:41:50 <dhellmann> 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 <dims> dtroyer : yep
20:42:28 <fungi> 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 <ttx> 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 <ttx> (by core I mean contributions to the consuming service)
20:43:19 <dtroyer> 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 <stevemar> dtroyer: good point
20:43:59 <flaper87> 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 <dhellmann> I suppose if we say no to the teams, we just wouldn't see their efforts at all.
20:44:07 <mordred> 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 <ttx> 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 <mordred> even if we don't like that vendor
20:44:21 <dhellmann> mordred : yes, good point
20:44:24 <dims> my opinion, driver team option is a safety valve to keep folks in. so +1
20:44:26 <jroll> 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 <smcginnis> mordred: +1
20:44:31 <fungi> 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 <mordred> fungi: +
20:44:42 <mordred> fungi: ++
20:44:44 <jroll> sam is a heavy driver (heh) of a lot of ironic's networking work
20:45:04 <mordred> jroll: yes. that is the healthy way to do things and what we should _always_ prefer
20:45:07 <dhellmann> jroll : I think it speaks highly that they asked to be an official team under the existing rules.
20:45:08 <sdague> 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 <dtroyer> 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 <dtroyer> s/cose/code/
20:45:21 <mordred> dtroyer: ++
20:45:23 <jroll> (I can't speak for other vendor teams, of course)
20:45:44 <sdague> and it's part of the workflow that lets someone understand how to work on common code
20:45:52 <mordred> 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 <fungi> 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 <jroll> 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 <mordred> 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 <ttx> 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 <jroll> allows folks on both sides to document why it doesn't fit
20:46:25 <sdague> because, our workflow is different enough from what's considered norms today, that any additional ways to get there are good
20:46:28 <dtroyer> fungi: I would hope in that case moving back into the project team oversight is what happens
20:46:34 <flaper87> jroll: indeed
20:46:44 <johnthetubaguy> 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 <fungi> dtroyer: if the consuming project team would allow it, but some do not want that added responsibility
20:46:56 <dhellmann> johnthetubaguy : ++
20:47:05 <ttx> 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 <mordred> johnthetubaguy: ++
20:47:29 <ttx> I can live by both outcomes at this point (grey or softblack)
20:47:30 <jroll> dhellmann: :)
20:47:42 <johnthetubaguy> at least its explicitly messy
20:47:47 <johnthetubaguy> (now)
20:47:51 <ttx> any other advocate for "out" ?
20:48:06 <mtreinish> what I'm still struggling with is what "in" actually means here, and the benefits it provides a driver team
20:48:13 <ttx> (Because if I read your previous answers I should actually not modify grey)
20:48:28 <mtreinish> like the infra workflow was always available to them as was hosting a repo in openstack/
20:48:40 <ttx> mtreinish: they become an official openstack project team, with controlled /limited scope
20:48:41 <dims> mtreinish : access to horizontal teams
20:48:49 <ttx> mtreinish: vote for TC
20:48:58 <jroll> mtreinish: docs.openstack.org access is the main thing people want, from what I've heard
20:48:59 <ttx> PTG space
20:49:03 <stevemar> thanks for asking mtreinish
20:49:26 <mtreinish> so docs.o.o, a tc vote, and ptg access?
20:49:27 <dhellmann> 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 <stevemar> jroll: the part of docs.o.o? the developer docs? or guides?
20:49:31 <jroll> ATC/PTG, folks are happy to have, but don't care as much, afaict
20:49:33 <thingee> jroll +1 heard that from neutron folks
20:49:50 <jroll> stevemar: being able to publish anything anywhere on that site (primarily dev docs, but now install guide plugins etc)
20:49:57 <mordred> 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 <mtreinish> dhellmann: well in this case it matters because we're defining a new subset of projects that is different
20:50:02 <thingee> stevemar vendors want to be able to document setting up an environment with their drivers.
20:50:20 <stevemar> thingee: that sounds perfectly reasonable
20:50:30 <dhellmann> mtreinish : why does that make it matter? are you worried we're giving up too much somehow?
20:50:34 <thingee> I agree. current rules disallow neutron drivers today though
20:50:35 <ttx> If you made your decision can you cast your +1 for either proposal ? Just so that we know where we stand
20:51:09 <ttx> Looks like overwhelming support for grey as it stands
20:51:23 <fungi> 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 <ttx> I'm fine approving it now since we covered all the objections that were raised and decided to bypass them
20:51:48 <mtreinish> 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 <dhellmann> fungi : we can guide them when they apply for status
20:52:10 <dims> agree dhellmann
20:52:17 <fungi> dhellmann: yes, i hope we'll be aware enough to do so
20:52:23 <ttx> yes we need to accompany those, and probably write a bunch for the project team guide
20:52:26 <dhellmann> 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 <mordred> mtreinish: yah - I do not think we should allow single-vendor services
20:52:58 <dhellmann> I also don't think we should keep driver teams if they do not accept valid contributions from outside the vendor.
20:53:03 <thingee> mordred mtreinish ++
20:53:04 <mordred> dhellmann: ++
20:53:11 <mordred> dhellmann: we should maybe encode that
20:53:16 <mtreinish> dhellmann: I'm trying to weigh what the community gets vs what the vendor gets
20:53:21 <dhellmann> perhaps, I had trouble coming up with wording
20:53:23 <ttx> ok, should we approve this now or discuss it one more time
20:53:26 <mordred> dhellmann: fair
20:53:35 <ttx> because I have stuff to discuss in open discussion
20:53:45 <dhellmann> 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 <jroll> dhellmann: I feel like the outside contributions thing is part of "open development"
20:54:00 <dhellmann> ttx: ok
20:54:05 <dhellmann> jroll : yep
20:54:06 <fungi> i'm okay pressing forward. while grey is not my preference, my concerns are addressed sufficiently by it
20:54:23 <flaper87> I'm ok with the proposal as it is
20:54:33 <stevemar> ttx: is today the cutoff for driver teams getting ptg space?
20:54:37 <dims> y, already has my +1
20:54:44 <EmilienM> same
20:54:51 <ttx> stevemar: not really. But some teams have been patiently waiting that we get our house in order
20:55:19 <ttx> mtreinish: ?
20:55:25 <ttx> can you live by it ?
20:55:28 <stevemar> gotcha
20:55:45 <mtreinish> 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 <ttx> concerns that we can address in subsequent changes ?
20:56:29 <mtreinish> I'm not sure, I think it's a more fundamental question about why
20:56:33 <flaper87> ttx: perhaps we should postpone it till next year with the language one
20:56:43 <ttx> ok, let's not rush it
20:56:47 <thingee> yes, four mins left too
20:56:47 <ttx> #topic Open discussion
20:56:53 <ttx> * Joint TC/Board meeting
20:57:02 <ttx> 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 <mtreinish> like I think the rules outlined make sense, I'm just worried about the implications of it
20:57:15 <ttx> They are now looking into a specific 1-day or 2-day workshop to make progress on the "OpenStack futures" discussion
20:57:19 <ttx> Which might be tied to a future ops meetup or OpenStack Day or leadership training to make the trip worthwhile
20:57:29 <ttx> Long story short, won't happen on Sunday or Friday of the PTG, so you can book your flights
20:57:36 <dims> great thanks ttx
20:57:42 <ttx> (I'll likely arrive Saturday afternoon, so I'm happy to see people on Sunday)
20:57:44 <persia> Tying it to something is very appealing for those of us who wish to observe.
20:57:55 <ttx> * Election officials for Pike PTL elections
20:58:00 <ttx> We have volunteers to be "officials": tristanC & diablo_rojo
20:58:06 <ttx> (They said they would not run for PTL election)
20:58:13 <jroll> persia: ++
20:58:16 <ttx> 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 <dhellmann> ttx: ++
20:58:23 <dtroyer> ++
20:58:28 <ttx> * Skipping next two meetings
20:58:32 <fungi> thanks for volunteering, tristanC and diablo_rojo!
20:58:32 <ttx> Dec 27 is likely to be lightly-attended
20:58:36 <dims> ++ ttx
20:58:36 <EmilienM> ttx: no objection
20:58:39 <ttx> Jan 3... we could have a meeting then, especially since we now have a bit of a backlog
20:58:43 <ttx> you tell me
20:58:43 <johnthetubaguy> ++ for both of those
20:58:45 <dims> +1 to skip
20:58:53 <mtreinish> +1
20:58:57 <dtroyer> +1 on Jan 3 next meeting
20:59:02 <dhellmann> +1 to skip the 27th and meet on Jan 3
20:59:07 <dims> +1 to Jan 3
20:59:14 <johnthetubaguy> yeah, 3rd seems fine for me
20:59:15 <fungi> i'll need excusing from any meeting on the 27th but am available for the 3rd
20:59:16 <flaper87> I'll be out on Jan 3, likely
20:59:20 <EmilienM> wait, I thought we would meet and celebrate together
20:59:23 <EmilienM> oh well, +1 then :-)
20:59:29 <ttx> let's close the driver-team stuff on Jan 3rd ?
20:59:29 <thingee> +1 to skip 27th, next meeting jan 3
20:59:35 <ttx> mtreinish: you'll be around ?
20:59:42 <mtreinish> on jan 3rd?
20:59:43 <mtreinish> yeah
20:59:47 <ttx> ok
20:59:50 <sdague> +1 for skip 27th
20:59:55 <ttx> #agreed skip the 27th and meet on Jan 3
21:00:00 <ttx> Anything else, anyone ?
21:00:11 <ttx> with 0 seconds left ?
21:00:15 <jroll> he says at the buzzer :)
21:00:21 <ttx> #endmeeting