20:01:06 #startmeeting tc 20:01:07 Meeting started Tue May 24 20:01: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:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:08 oh, this should be fun 20:01:11 The meeting name has been set to 'tc' 20:01:14 o/ 20:01:15 o/ 20:01:20 * flaper87 bows 20:01:20 * prometheanfire lurks 20:01:32 Hi everyone! 20:01:35 We have accumulated a sane backlog... Our agenda for today: 20:01:41 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:49 #topic Clarify language about expectations for cycle-with-intermediary releases 20:01:55 #link https://review.openstack.org/318319 20:02:17 This one is just a language clarification. Saw no objection, just got enough votes 20:02:29 So will approve now unless someone screams 20:02:41 ttx : sounds good 20:02:47 * notmorgan screams for ice cream? 20:02:55 #topic Adds a docs:devdocs tag to indicate if project publishes devdocs 20:02:59 * flaper87 wants icecream 20:03:01 #link https://review.openstack.org/316396 20:03:12 This one is slightly more contentious. Anne proposes a tag to describe which projects have developer docs 20:03:22 can we avoid discussing the maturity level in this topic please. 20:03:30 I think that's a valid piece of information for users, but I also think it's accurately communicated through: 20:03:34 http://docs.openstack.org/developer/openstack-projects.html 20:03:39 thingee: I think we can 20:03:41 thingee: ++ 20:03:49 So.. I'm unconvinced of the benefit of maintaining this in two places 20:03:58 ttx my only concern with using openstack-projects.html is it's a manual process to keep that updated 20:03:58 can it be applied per repo? 20:04:12 ttx: we maintain diversity tags in 2 places ? 20:04:15 aren't those docs usually a per repo thing? 20:04:22 annegentle: it's also a manual process to update the tags ? 20:04:24 russellb: tags today allow that, so yes? 20:04:26 russellb not in my findings unfortunately 20:04:30 how is this different than that? 20:04:41 thingee: ack 20:04:52 sdague : where do we do that? 20:05:00 sdague: I don't understand 20:05:02 annegentle: just curious could we use the script in the existing place? 20:05:12 ttx oh I don't see it as super manual when I can run a script. 20:05:12 we created a tag for diversity based on data you can find elsewhere 20:05:46 my idea is to start with this tag, then expand to different docs: 20:05:46 tags to indicate which projects are more complete in their 20:05:48 doc coverage. 20:05:50 We have a page that lists dev docs. Anne proposes that we build tags that say "yes, there is a devdoc entry for the project on that page". I'm not sure what added value that brings to the user 20:05:51 derp paste 20:06:12 I'd like to have a starting point, and what we tell early projects now is "at least write contrib docs" 20:06:16 sdague : ah, yeah. I think I made the same argument against that tag, too. This case is even "worse" in the sense that it's a binary flag. At least for diversity it's a summary of the data collected elsewhere. 20:06:17 ttx: it seems like value from the project overview perspective. 20:06:20 and I believe it's different from the diversity tag 20:06:28 then we can add more doc tags for what else is written/maintained 20:06:38 this would assumes the user is someone interested in the development processes of a project. 20:06:46 I could skip to a "docs:drift" tag instead, which would measure the time diff between when RST files were last updated versus code files 20:07:03 annegentle: so if we autogenerated the info into the generated html, would that do the same thing? 20:07:05 thingee yeah, it's an audience-centric view. Not the greatest approach. 20:07:07 In the case of the diversity, you have to interpret a pie chart into a boolean, not just copy a boolean into another boolean 20:07:08 the whole point of tags was to provide one stop shop for information about a project that is useful to consumers 20:07:17 johnthetubaguy: yeah, that's what I was wondering 20:07:22 ttx: but you still need to know where to find that other thing 20:07:31 you are assuming a lot of pre knowledge 20:07:37 as oppose to today where we have a tag recognizing installation docs and the user is someone who is deploying something 20:07:45 ops tag actually 20:07:47 mtreinish johnthetubaguy maybe? so take openstack-projects.html and do something? 20:07:51 worth noting, contributor documentation is often expected by contributors to be found in the git repo for the project they just cloned or are browsing, so also having it published in a rendered form on docs.openstack.org seems sort of secondary 20:08:00 aggregating data is useful, when exploring projects 20:08:01 sdague: you mean, we need to assume people look for documentation by clicking on a linkk saying "Documentation" on almost every openstack website ? 20:08:07 fungi that's true, and a fair point. 20:08:24 i just want to say i don't have a strong view here. 20:08:31 for example, most of our projects have a CONTRIBUTING.rst in the top-level directory, few of them actually publish that anywhere in a rendered form 20:08:34 i will support the direction annegentle would like to see it go. 20:08:49 honestly, I feel like replicating information that can be done nearly automatically has very low cost, and at least some benefit 20:08:58 sine i think she has a solid understanding of the needs on this front. 20:09:00 uh, as a "user", I'll go wherever I might find an answer, so the tag would be useful 20:09:05 I think mtreinish might be onto something, where we "quality check" the completeness of openstack-projects.html. 20:09:06 I'm just trying to avoid extra bureaucracy and stale data. If Anne thinks she can maintain the tag alright, why not 20:09:06 sdague: thinking a similar thing, honestly 20:09:20 ttx: that is 100% fair 20:09:25 I mean skip the tag, and just add something into the rendered html? 20:09:36 I don't see a strong benefit of being able to see this information at a glance besides knowing the doc coverage as annegentle mentioned. If it can be maintained easily, i don't see harm in in it. I also don't have a strong opinion. 20:09:46 the link to the doc for a project is more valuable than the tag itself.. 20:09:53 I'm honestly more concerned about what other tags we're considering for the docs group than this one per se. 20:09:55 dims: ++ 20:09:58 johnthetubaguy honestly I'm not in love with "devdocs" tag because it's not that meaningful to end users 20:10:05 johnthetubaguy : yeah, I suggested adding URLs instead of a tag 20:10:06 also as a data point, the existence of an install doc is maintained as an ops tag 20:10:15 dhellmann : ++ 20:10:17 I wanted to get this up there as a POC to see if we could automate docs tags... 20:10:19 adding urls would also be fine with me 20:10:23 dhellmann: I missed that, that would work 20:10:24 dhellmann, ++ 20:11:05 I'd say that adding urls feels like less useless duplication, at least one can get to the doc from there 20:11:09 dhellmann I like that idea because looking now, people tend to point to a wiki page, blech. 20:11:09 given nova vs compute, for dev and api docs, its handy to have a lookup 20:11:12 urls work for this tag, but will be a bit complicated for "is covered by an install guide" since there may be several 20:11:20 annegentle : agree 20:11:25 I like dhellmann's idea of the urls to be honest 20:11:36 So, URLs and we're good ? 20:11:37 dhellmann: maybe, there is typically a base entry point 20:11:38 :D 20:11:39 all: and for the next trick, how to figure out which projects are lacking API docs? 20:11:40 urls ++ 20:11:43 dhellmann: so adding to the deliverable grammar rather than use a tag ? 20:11:55 annegentle: and I agree, api doc url is also good here 20:11:58 annegentle: a URL? 20:12:17 ttx; right, I propose a data model in a comment on anne's patch 20:12:19 johnthetubaguy well, it also gets to "are you publishing to a known URL pattern or not?" 20:12:50 dhellmann: this still creates a maintenance cost and a risk of stale data, but I can see it was having higher value, so that compensates 20:13:00 s/was/as 20:13:13 ttx: yeah, staleness is going to be a bit of a concern either way 20:13:20 I'd still like ideas for discovering which projects are off-pattern... ideas? 20:13:24 ok, so let's express that in the review and morve formward ? 20:13:30 ++ 20:13:33 yes please add to review 20:13:41 annegentle: you can easily check which project is missing the extra devdoc yaml entry 20:13:52 even easier than checking presence of tag 20:14:08 ttx yep that pattern will help immensely, is it ok to then spread to other doc types? Please comment on review. 20:14:17 annegentle : if we specify base URLs in code, and slugs in the YAML, then all of the functional URLs will have to follow the pattern. 20:14:23 this data really shouldn't get very stale. If people are randomly moving docs urls all over the place, that's a way different problem 20:14:30 dhellmann : love it 20:14:32 sdague they are for api-ref for sure already 20:14:34 you can have a doc: entry at the same level as tag entries, and then list URLs to various types of docs 20:14:38 annegentle: in a one time move 20:14:40 sdague by not publishing the same way 20:14:54 ttx ok put an example in the review, thanks! 20:15:09 I'll take on which doc urls in a revision 20:15:13 annegentle: sdague: as an aside, I guess we need to fix that with redirects or something, but thats a difference conversation 20:15:15 annegentle : see my comment from May 23 20:15:16 doc: - devdoc: - install: etc 20:15:33 OK, I think we can iterate on the review and offline 20:15:33 johnthetubaguy we do redirects a lot now, but yes, that would be ideal 20:15:34 s/devdoc/contribdoc/ 20:15:39 dhellmann cool 20:15:50 ttx yep! Thanks 20:15:55 I propose we move on to next topic 20:16:01 ++ 20:16:05 #topic Trim tc-approved-release tag to just base IaaS projects - initial discussion 20:16:10 #link https://review.openstack.org/314691 20:16:19 Let's timebox the initial discussion on this one to 20 minutes to give room to make progress on the golang discussion 20:16:38 Only Doug and I have been posting comments on this one so far (as TC members) 20:16:43 i don't understand the intentioin here. it seems superfluous to do? 20:16:48 ttx: well and me :) 20:16:50 Proposal is to limit tc-approved-release to "Base IaaS" projects, removing heat, horizon, ironic, sahara, ceilometer and trove 20:16:54 mtreinish: obviously :) 20:16:58 I think this is some other kind of tag. Also this will be difficult to determine. 20:17:01 notmorgan: not just superfluous, but against the established process 20:17:04 In my comment I noted the proposal is a bit incompatible with how we said we'd use 'tc-approved-release' when it was first created 20:17:09 dhellmann: fair enough 20:17:16 i.e. it was not meant to describe "Base IaaS" projects, it was only meant to fulfill our obligations under the Foundation bylaws 20:17:22 with changes to the list being Board-driven rather than TC-driven 20:17:25 And I'm curious on the value. Was that explained somewhere? 20:17:32 Of course we could change that, but I think in that case we should update the tag description as well 20:17:48 Or a new tag? 20:17:49 dhellmann: i voted and concur with your vote. 20:17:51 yeah, this tag was defined very carefully to avoid having to keep having this discussion at all 20:18:00 ttx: right, but as long as the borad process is being used to determine technical things like interop requirements I think we should take a more active role in determining what is included there 20:18:05 so new tag ... if there's value 20:18:17 thingee: i said as much in my review. 20:18:19 thingee mugsie|mobile ++ 20:18:26 thingee: yes 20:18:27 this tag has some overlap with computer:starter-kit idea, imo. 20:18:30 mtreinish : if there are issues with projects on the list, we should address those one at a time. 20:18:31 I can respin it as a new tag, thats easy enough to 20:18:37 /this tag/this change/ 20:18:56 mtreinish : sounds like the right thing to do 20:18:56 sigmavirus24: yea what about compute:starter-kit as dougwig suggested 20:19:01 I can see the cost of that tag (endless discussions on what is "Base IaaS" and not sure what value it brings to end users of openstack 20:19:02 dougwig: Good point 20:19:07 huh? 20:19:12 mtreinish : like http://governance.openstack.org/reference/tags/starter-kit_compute.html ? 20:19:14 ttx: starterkit seems to cover this anyway 20:19:14 How did I get pulled into this? 20:19:16 thingee: you meant dougwig 20:19:16 :D 20:19:20 sigmavirus24: typo 20:19:21 sigmavirus24: typo? 20:19:24 ah 20:19:28 sigmavirus24: http://governance.openstack.org/reference/tags/starter-kit_compute.html 20:19:29 :) 20:19:30 mtreinish: so 'base' here means 'covered by defcore'? 20:19:31 * notmorgan makes it a point to bring sigmavirus24 into every convo now 20:19:41 notmorgan: lol 20:19:41 if we don't want to talk about the tag, should we not either delete it, or added to everything? 20:19:45 * sigmavirus24 shakes head 20:20:12 Why should only base iaas be covered by defcore? 20:20:13 johnthetubaguy: it is mostly historical. it was a baseline to start with, long term it should be something we can drop 20:20:13 johnthetubaguy : the tag is an implementation of our duties under the bylaws w.r.t. the defcore committee 20:20:15 sure, compute starter kit is similar, but the problem is for the purpose of actually enforcing interop the tc isn't actually asserting those projects. Its saying anything which was in the intergrated release pre big tent can be used 20:20:15 just not yet 20:20:15 sigmavirus24: oh heh, for some reason I thought I read last night you starting this, sorry 20:20:25 notmorgan: starterkit has value ("what should I start with"). Not sure "What are the 'Base IaaS' projects" is a question users have and we need to provide an answer for 20:20:27 thingee: no worries :D 20:20:29 so we need the tag, unless we come up with another way to do that, but we have the tag so we don't need another way to do it 20:20:46 ttx: right, starterkit i see as the intention of this change. 20:20:46 the name of the tag was, as described in its definition, selected specifically because that's what the bylaws call this list 20:20:55 if defcore is the only trademark thing which as a community we're also using to enforce interop I fele like we should be a bit more targetted in what we say should be used there 20:20:57 ttx: in spirit if not in the letter 20:21:02 notmorgan, dhellmann +1 20:21:06 notmorgan: except it's larger than starter-kit 20:21:19 ttx: hence my view it's the spirit of the change 20:21:21 "has-interop-tests"? 20:21:27 even though it's a narrower tag (starterkit) 20:21:29 mtreinish: it does feel wrong to side step our obligations around maintaining the tag 20:21:34 tags are cheap, so lets not overload existing things 20:21:36 mtreinish : if we end up with 2 interop processes, we're going to have different versions of interoperability 20:21:47 mtreinish: why? Should we not aim to have trove etc checked for interop? 20:22:05 * dims nods with mugsie|mobile 's question 20:22:14 (Or Designate, but I would argue we should be base iaas) 20:22:17 I kind of see what mtreininsh wants though...; there are things in tc-approved-release we'd likely never ever want in the "OpenStack-powered compute" trademark program 20:22:28 ttx: it's not our job to define trademark programs 20:22:30 so, lets invert this. 20:22:33 dhellmann: right 20:22:34 that's the board's job 20:22:34 so tested for interop and in the OpenStack-powered compute are not the same thing right? 20:22:40 dhellmann: +1 20:22:42 if defcore wants to propose the "trademark" tag 20:22:43 and they're doing that by creating different programs as needed 20:22:43 dhellmann: ++ 20:22:45 let them. 20:22:48 dhellmann : we need something to reflect which ones we cover under trademark programs? 20:22:49 and i'll support it 20:22:53 i don't want the TC to define it 20:22:57 dhellmann: also compute is not the only trademark they might want to create 20:22:58 * markvoelker notes that it is possible to create other Components than what is in DefCore today, and give them their own interop/Powered badges 20:22:59 dhellmann: it's not, but we also use it to say this is what we mean to be interoperable (with defcore) which feels like a technical thing 20:23:06 markvoelker: ++ 20:23:07 defcore/board. 20:23:11 notmorgan: hence my suggestion of adding the tag to every project, if thats what we want to do 20:23:22 dims : yes, the tc-approved-release is our list of projects we consider reasonable for defcore to be looking at -- the ones we've agreed for them to look at 20:23:23 markvoelker: ++ 20:23:30 johnthetubaguy: i'd rather let this tag die long term. it's very historical 20:23:39 markvoelker ++ 20:23:39 we can have a tag for what projects are interoperable, as it's been mentioned already 20:23:43 notmorgan: I am OK deleteting it 20:23:45 we can't have a membership change in the TC having big changes in that list, because it takes a while for defcore to move 20:23:48 markvoelker: totally +1 that 20:23:48 right, tc-approved-release is what the TC has said the board can consider for interop 20:23:50 notmorgan: unfortunately the bylaws change very slowly 20:23:57 ttx: yes i know. 20:23:57 It sounds like people are wanting to abdicate technical responsibility (for interoperability) to defcore, which seems contrary to what I would hope a _technical_ committee is for. 20:24:15 notmorgan : no, no, it's not historical -- the current membership is historical but the tag is definitely something we have to keep up with 20:24:16 cdent: well, it's more subtle than that 20:24:17 cdent: ++ 20:24:21 cdent: I don't think that's the intention 20:24:21 cdent: we have unfortunately already delegated that long ago 20:24:34 cdent : not abdicate, collaborate 20:24:38 cdent: but the intention here is not to have the TC dictate what is defcore sprecifc 20:24:49 sdague: I know it is more subtle than that, but it does _sound_ that way. 20:25:00 because the board owns the mission of the commercial competition space. So they really should be the one to come up with commercial certifications they feel best fit in the marketplace 20:25:01 cdent: but have defcore propose from their side as well getting collaboration 20:25:05 the tc has input into defcore through this tag and through statements about future technical direction (see my pending proposals for examples) 20:25:22 and of course anyone can go to defcore meetings and argue points there 20:25:25 cdent: defcore is a board process which seeks direction from tc 20:25:26 and the TC has the ability to say, via tc-approved-release, this is the menu of things we're ok with you building from 20:25:27 but the board and defcore comittee owns the trademark stuff. I just can't see us defining the tag w/o directed input from the board and defcore 20:25:29 that process is open, and done through code review 20:25:36 cdent: the weapon you can enforce interoperability with is trademark programs -- and that's the board prerogative 20:25:42 and we've generally agreed at this point the menu is bigger than defcore needs, and that's fine 20:25:51 because nothing on the menu is rediculous 20:25:52 so i'd rather have the proposal inverted if we're using it in this way 20:26:03 sdague : right, we never want this list to be too much smaller than what defcore needs/wants 20:26:06 so we should not take things out of that menu 20:26:08 we work with defcore to determien what the tag is. anyway i think i've said enough. 20:26:10 cdent: they get to define what the OpenStack[tm] can be applied to 20:26:19 and if the board feels there is another cert they want to spur competition / market on, they can ask the tc to put more on the menu 20:26:23 notmorgan : all of that work was already done, that's how the tag was created in teh first place 20:26:31 dhellmann: right 20:26:40 dhellmann: ++ 20:26:44 dhellmann: so nothing to change imo 20:26:48 sdague : right, that's what we said when we created the tag 20:26:56 ++ 20:27:01 I feel like there's just some history here that folks don't remember/know/understand. 20:27:05 we can decide that stuff should come off the menu. That's fine, that's a very specific different thing. 20:27:15 dhellmann: ++ 20:27:18 dhellmann: ++ 20:27:22 sdague: yes, but we should do that deliberatively and one project at a time 20:27:32 but I don't think we want to conflate that with what's actually being interop tested 20:27:34 dhellmann : agree 20:27:35 and with "reasons" beyond "cleaning up" 20:27:37 dhellmann: seems like a good summary of a lot of openstack discussions ;-) 20:27:40 because it always was supposed to be larger 20:27:45 I should probably unearth links to the orginal discussion for context 20:27:46 notmyname : so true 20:27:56 sdague : so we need a tag that reflects what's being defcore-tested 20:28:02 dims: that would be fine 20:28:02 at this moment 20:28:20 sdague: dims: defcore is a very small subset of openstack, "core", and we could communicate that better. 20:28:27 dims : well, that gets us back into redefining things that are defined elsewhere. DefCore has that info, and there's a trademark site that lists the current rules. 20:28:31 mtreinish so is that the need, to indicate whats tested? 20:28:44 hogepodge: right, given the amount of confusion, I think a tag would actually be quite useful 20:28:48 dhellmann : yep, so we don't need to do that here 20:28:51 sdague: +1 20:28:55 It's not completely crazy to have a tag that reflects current defcore projects. Not sure that's a question that people actually have, but I can see it clarifying things 20:28:56 because I bet most of the TC doesn't know what the list is :) 20:29:00 even though they could look it up 20:29:06 haha 20:29:06 dhellmann, dims ++ 20:29:18 Defined in DefCore repo. 20:29:19 one google search away :) 20:29:22 annegentle: well I was more trying to define a set of what the tc thinks is base set of projects for interop 20:29:35 ttx: sdague: especially since compute will capture keystone, cinder, nova, glance, neutron. it's confusing 20:29:36 sdague : how about a link from http://governance.openstack.org/reference/tags/tc-approved-release.html to that info? 20:29:49 mtreinish : what yardstick would you use to measure that? 20:29:49 and again, why should that list only be iaas? 20:29:54 mtreinish that was originally the starter kit 20:30:11 annegentle: it's not 20:30:13 annegentle: I didn't think the starter kit was for interop 20:30:18 but, a defcore tag should say 'defcore' to prevent even more confusion 20:30:20 mestery: ++ 20:30:31 annegentle: maybe, but if so I feel there is a disconnect in the messaging then 20:30:32 sdague mestery ok, right, it was for computing 20:30:34 yes 20:30:41 mtreinish nope I'm wrong :) 20:30:42 right, lets not conflate things 20:30:58 mestery: are you suggesting the menu is too big for defcore right now, or something different? 20:31:03 because there are a few different slices here, which have very close member sets, but they are for different reasons 20:31:12 so, the time is almost up for this topic. Can we summarize the discussion and write down the main take-aways ? 20:31:13 and that was the whole problem with the "integrated release" 20:31:23 johnthetubaguy: I'm not suggesting anything, I was just saying the "compute:starter" tag was not indicating interop 20:31:24 right 20:31:39 mestery : ack 20:31:41 mestery: sorry, I used the wrong name, that was for mtreinish 20:31:51 johnthetubaguy: heh, no worries :) 20:32:08 so many m's 20:32:11 johnthetubaguy: I think it is, like horizon isn't likely ever gonna be an interop requirement 20:32:13 mtreinish / hogepodge so how about a whole new tag here? 20:32:26 mestery: my typing skills at 9pm are even worse than normal! 20:32:39 I'd be OK with a tag reflecting what defcore is using. I don't think we need a tag "suggesting" an interop set of any sort. 20:32:39 mtreinish: well, I think I agree with dhellmann that we should do deletes from that 1 at a time. 20:32:44 johnthetubaguy: and I think a base interop set shouldn't be things that consume other openstack apis (but maybe that's just my opinion) 20:32:45 johnthetubaguy: try it at 10pm :P 20:32:47 johnthetubaguy: the old "m" trap 20:32:53 johnthetubaguy: i am very familiar with it. 20:32:57 sdague: sure, I can do it as that 20:32:58 mtreinish: but why does it have to be iaas? 20:33:11 flaper87: I feel your pain 20:33:20 mugsie|mobile: well what kinda of openstack cloud doesn't use iaas as a base? 20:33:23 flaper87: we should compare hours after evening meal or something, heh 20:33:30 OK, I think there is general agreement that whatever this tag is trying to convey, tc-approved-release is probably not the right place for it 20:33:36 ok, I guess we'll iterate again over the new patchset with the new tag 20:33:39 ttx: ++ 20:33:41 ttx: +1 20:33:47 mtreinish : I think you're trying to pull the TC into an area that's the board's responsibility. 20:33:49 mtreinish: sdague: yeah, I am +1 the one by one removal, FWIW 20:33:52 I'm fine with working it as a new tag 20:33:57 mtreinish: can you really get a large group of people to define IaaS the same way? 20:34:00 There might be room for another tag (or not) but let's wait until that is proposed ? 20:34:03 sdague: yes, defcore has meaning and a tag to capture that is useful 20:34:04 dhellmann: interop is very much a TC thing 20:34:06 and a new tag for the new thing sounds like a nice idea too 20:34:11 hogepodge: ++ 20:34:13 mtreinish : defining sets of things though? 20:34:19 ok, so mtreinish has 2 todos, right? 20:34:29 We should wait for mtreinish's new PS and comment there. 20:34:29 We are approaching our timebox 20:34:30 so interop is a TC thing, trademarks is a board thing, right? 20:34:31 * jroll wonders what world bare metal machines aren't IaaS :P 20:34:32 new tag, plus propose any appropriate deletes? 20:34:40 jroll ++ 20:34:47 jroll: heh 20:34:49 mtreinish: I'd like for projects outside of defcore to define what interop means to them too, again, guidance 20:34:50 and we move on those in gerrit 20:34:51 where "appropriate deletes" includes detailed reasons beyond cleaning things up 20:34:52 jroll: ++ 20:34:56 jroll: I was thinking only from the api side, not the functionality 20:34:59 dhellmann: absolutely 20:35:00 (I get the removal motivation here, but "not IaaS" heh) 20:35:04 mtreinish: yeah, fair 20:35:11 dhellmann: +1 20:35:16 mtreinish : +1 20:35:30 jroll: in the ironic case it goes through nova for the most part :) 20:35:36 jroll: yeh, ironic is super weird in not having a user API from an interop perspective 20:36:02 OK, let's move on to next topic 20:36:06 which isn't that it's not an important project, it's just that by rule it can't be defcore, which doesn't do admin apis 20:36:22 sdague: right, I get that it's an interop thing, and I'd agree for now, but we should be clear about that rather than saying "IaaS" 20:36:27 ttx: +1 move on 20:36:30 jroll: agree 20:36:47 please follow-up on that review 20:36:54 #topic Add golang as an approved language - benefits vs. costs, and the scope clarification option 20:37:00 #link https://review.openstack.org/312267 20:37:07 * edleafe gets popcorn 20:37:12 Last week I tried to reframe the choices we actually had on this one, since I think we can't really say "no" to golang in official OpenStack projects as they stand 20:37:17 edleafe: share 20:37:26 So I presented two alternatives: "yes" and "no and do things in other languages as OpenStack dependencies" 20:37:29 current thread http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#95452 20:37:38 * edleafe hands flaper87 a handful 20:37:39 That said, nobody on the thread did really support my "official scope drives official languages" theory -- and then the discussion on that thread went sideways 20:37:47 * rockyg opens one eye and reaches for edleafe's popcorn 20:37:51 Finally, a "yes but everything that can be done in Python should still be done in Python" option emerged recently 20:38:04 ttx: I like the distinction, but that thread got off track so fast I didn't follow up 20:38:07 so i think adrian otto summed up my vew perfectly: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095827.html 20:38:09 So I'd like to take a temperature read (not a vote) to clarify current TC members positions on this before we continue the discussion 20:38:13 dhellmann: ++ to that 20:38:25 TC members, please order the following options in descending order of preference 20:38:30 #1: Yes to golang, without restrictions 20:38:33 I enjoyed the trip in the five years ago time machine 20:38:34 ttx: it is extremely unlikely that if we approve the use of golang we could avoid having projects start rewriting things 20:38:40 #2: Yes to golang, with clear description on where it is appropriate to use it (i.e. when Python can't be used) 20:38:51 #3: Components requiring golang should really be developed as OpenStack dependencies, no need to expand the language set now 20:39:00 annegentle: yeah, I remember the discussion, but missed that meeting 20:39:00 #4: Some other solution: remaining options don't work for me 20:39:09 At this stage I think I'm 3,2,1,4 20:39:10 #2, #1, #3 20:39:11 ttx : i would like to add some guidance on projects that want to pick up go and tell them beware of these things before you go down this road 20:39:16 3, 2, 1, 4 20:39:20 #3 #2 #1 20:39:35 and very strongly prefer #2 to #3 20:39:38 dhellmann: are some of those rewrites good things, or is it all bad? 20:39:38 #2 #1 #3 #4 20:39:47