20:01:06 <ttx> #startmeeting tc
20:01:07 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:08 <prometheanfire> oh, this should be fun
20:01:11 <openstack> The meeting name has been set to 'tc'
20:01:14 <mtreinish> o/
20:01:15 <russellb> o/
20:01:20 * flaper87 bows
20:01:20 * prometheanfire lurks
20:01:32 <ttx> Hi everyone!
20:01:35 <ttx> We have accumulated a sane backlog... Our agenda for today:
20:01:41 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:49 <ttx> #topic Clarify language about expectations for cycle-with-intermediary releases
20:01:55 <ttx> #link https://review.openstack.org/318319
20:02:17 <ttx> This one is just a language clarification. Saw no objection, just got enough votes
20:02:29 <ttx> So will approve now unless someone screams
20:02:41 <dims> ttx : sounds good
20:02:47 * notmorgan screams for ice cream?
20:02:55 <ttx> #topic Adds a docs:devdocs tag to indicate if project publishes devdocs
20:02:59 * flaper87 wants icecream
20:03:01 <ttx> #link https://review.openstack.org/316396
20:03:12 <ttx> This one is slightly more contentious. Anne proposes a tag to describe which projects have developer docs
20:03:22 <thingee> can we avoid discussing the maturity level in this topic please.
20:03:30 <ttx> I think that's a valid piece of information for users, but I also think it's accurately communicated through:
20:03:34 <ttx> http://docs.openstack.org/developer/openstack-projects.html
20:03:39 <ttx> thingee: I think we can
20:03:41 <mestery> thingee: ++
20:03:49 <ttx> So.. I'm unconvinced of the benefit of maintaining this in two places
20:03:58 <annegentle> ttx my only concern with  using openstack-projects.html is it's a manual process to keep that updated
20:03:58 <russellb> can it be applied per repo?
20:04:12 <sdague> ttx: we maintain diversity tags in 2 places ?
20:04:15 <russellb> aren't those docs usually a per repo thing?
20:04:22 <ttx> annegentle: it's also a manual process to update the tags ?
20:04:24 <thingee> russellb: tags today allow that, so yes?
20:04:26 <annegentle> russellb not in my findings unfortunately
20:04:30 <sdague> how is this different than that?
20:04:41 <russellb> thingee: ack
20:04:52 <dhellmann> sdague : where do we do that?
20:05:00 <ttx> sdague: I don't understand
20:05:02 <mtreinish> annegentle: just curious could we use the script in the existing place?
20:05:12 <annegentle> ttx oh I don't see it as super manual when I can run a script.
20:05:12 <sdague> we created a tag for diversity based on data you can find elsewhere
20:05:46 <annegentle> my idea is to start with this tag, then expand to different docs:
20:05:46 <annegentle> tags to indicate which projects are more complete in their
20:05:48 <annegentle> doc coverage.
20:05:50 <ttx> 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 <annegentle> derp paste
20:06:12 <annegentle> I'd like to have a starting point, and what we tell early projects now is "at least write contrib docs"
20:06:16 <dhellmann> 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 <sdague> ttx: it seems like value from the project overview perspective.
20:06:20 <flaper87> and I believe it's different from the diversity tag
20:06:28 <annegentle> then we can add more doc tags for what else is written/maintained
20:06:38 <thingee> this would assumes the user is someone interested in the development processes of a project.
20:06:46 <annegentle> 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 <johnthetubaguy> annegentle: so if we autogenerated the info into the generated html, would that do the same thing?
20:07:05 <annegentle> thingee yeah, it's an audience-centric view. Not the greatest approach.
20:07:07 <ttx> 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 <sdague> the whole point of tags was to provide one stop shop for information about a project that is useful to consumers
20:07:17 <mtreinish> johnthetubaguy: yeah, that's what I was wondering
20:07:22 <sdague> ttx: but you still need to know where to find that other thing
20:07:31 <sdague> you are assuming a lot of pre knowledge
20:07:37 <thingee> as oppose to today where we have a tag recognizing installation docs and the user is someone who is deploying something
20:07:45 <thingee> ops tag actually
20:07:47 <annegentle> mtreinish johnthetubaguy maybe? so take openstack-projects.html and do something?
20:07:51 <fungi> 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 <johnthetubaguy> aggregating data is useful, when exploring projects
20:08:01 <ttx> 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 <annegentle> fungi that's true, and a fair point.
20:08:24 <notmorgan> i just want to say i don't have a strong view here.
20:08:31 <fungi> 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 <notmorgan> i will support the direction annegentle would like to see it go.
20:08:49 <sdague> honestly, I feel like replicating information that can be done nearly automatically has very low cost, and at least some benefit
20:08:58 <notmorgan> sine i think she has a solid understanding of the needs on this front.
20:09:00 <rockyg> uh, as a "user", I'll go wherever I might find an answer, so the tag would be useful
20:09:05 <annegentle> I think mtreinish might be onto something, where we "quality check" the completeness of openstack-projects.html.
20:09:06 <ttx> 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 <johnthetubaguy> sdague: thinking a similar thing, honestly
20:09:20 <notmorgan> ttx: that is 100% fair
20:09:25 <johnthetubaguy> I mean skip the tag, and just add something into the rendered html?
20:09:36 <thingee> 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 <dims> the link to the doc for a project is more valuable than the tag itself..
20:09:53 <flaper87> I'm honestly more concerned about what other tags we're considering for the docs group than this one per se.
20:09:55 <mestery> dims: ++
20:09:58 <annegentle> johnthetubaguy honestly I'm not in love with "devdocs" tag because it's not that meaningful to end users
20:10:05 <dhellmann> johnthetubaguy : yeah, I suggested adding URLs instead of a tag
20:10:06 <ttx> also as a data point, the existence of an install doc is maintained as an ops tag
20:10:15 <dims> dhellmann : ++
20:10:17 <annegentle> I wanted to get this up there as a POC to see if we could automate docs tags...
20:10:19 <sdague> adding urls would also be fine with me
20:10:23 <johnthetubaguy> dhellmann: I missed that, that would work
20:10:24 <rockyg> dhellmann, ++
20:11:05 <ttx> I'd say that adding urls feels like less useless duplication, at least one can get to the doc from there
20:11:09 <annegentle> dhellmann I like that idea because looking now, people tend to point to a wiki page, blech.
20:11:09 <johnthetubaguy> given nova vs compute, for dev and api docs, its handy to have a lookup
20:11:12 <dhellmann> 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 <dims> annegentle : agree
20:11:25 <mestery> I like dhellmann's idea of the urls to be honest
20:11:36 <flaper87> So, URLs and we're good ?
20:11:37 <sdague> dhellmann: maybe, there is typically a base entry point
20:11:38 <flaper87> :D
20:11:39 <annegentle> all: and for the next trick, how to figure out which projects are lacking API docs?
20:11:40 <russellb> urls ++
20:11:43 <ttx> dhellmann: so adding to the deliverable grammar rather than use a tag ?
20:11:55 <sdague> annegentle: and I agree, api doc url is also good here
20:11:58 <johnthetubaguy> annegentle: a URL?
20:12:17 <dhellmann> ttx; right, I propose a data model in a comment on anne's patch
20:12:19 <annegentle> johnthetubaguy well, it also gets to "are you publishing to a known URL pattern or not?"
20:12:50 <ttx> 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 <ttx> s/was/as
20:13:13 <dhellmann> ttx: yeah, staleness is going to be a bit of a concern either way
20:13:20 <annegentle> I'd still like ideas for discovering which projects are off-pattern... ideas?
20:13:24 <ttx> ok, so let's express that in the review and morve formward ?
20:13:30 <flaper87> ++
20:13:33 <annegentle> yes please add to review
20:13:41 <ttx> annegentle: you can easily check which project is missing the extra devdoc yaml entry
20:13:52 <ttx> even easier than checking presence of tag
20:14:08 <annegentle> ttx yep that pattern will help immensely, is it ok to then spread to other doc types? Please comment on review.
20:14:17 <dhellmann> 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 <sdague> 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 <dims> dhellmann : love it
20:14:32 <annegentle> sdague they are for api-ref for sure already
20:14:34 <ttx> 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 <sdague> annegentle: in a one time move
20:14:40 <annegentle> sdague by not publishing the same way
20:14:54 <annegentle> ttx ok put an example in the review, thanks!
20:15:09 <annegentle> I'll take on which doc urls in a revision
20:15:13 <johnthetubaguy> annegentle: sdague: as an aside, I guess we need to fix that with redirects or something, but thats a difference conversation
20:15:15 <dhellmann> annegentle : see my comment from May 23
20:15:16 <ttx> doc: - devdoc:<URL> - install:<URL> etc
20:15:33 <ttx> OK, I think we can iterate on the review and offline
20:15:33 <annegentle> johnthetubaguy we do redirects a lot now, but yes, that would be ideal
20:15:34 <dhellmann> s/devdoc/contribdoc/
20:15:39 <annegentle> dhellmann cool
20:15:50 <annegentle> ttx yep! Thanks
20:15:55 <ttx> I propose we move on to next topic
20:16:01 <flaper87> ++
20:16:05 <ttx> #topic Trim tc-approved-release tag to just base IaaS projects - initial discussion
20:16:10 <ttx> #link https://review.openstack.org/314691
20:16:19 <ttx> 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 <ttx> Only Doug and I have been posting comments on this one so far (as TC members)
20:16:43 <notmorgan> i don't understand the intentioin here. it seems superfluous to do?
20:16:48 <mtreinish> ttx: well and me :)
20:16:50 <ttx> Proposal is to limit tc-approved-release to "Base IaaS" projects, removing heat, horizon, ironic, sahara, ceilometer and trove
20:16:54 <ttx> mtreinish: obviously :)
20:16:58 <thingee> I think this is some other kind of tag. Also this will be difficult to determine.
20:17:01 <dhellmann> notmorgan: not just superfluous, but against the established process
20:17:04 <ttx> 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 <notmorgan> dhellmann: fair enough
20:17:16 <ttx> 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 <ttx> with changes to the list being Board-driven rather than TC-driven
20:17:25 <thingee> And I'm curious on the value. Was that explained somewhere?
20:17:32 <ttx> Of course we could change that, but I think in that case we should update the tag description as well
20:17:48 <mugsie|mobile> Or a new tag?
20:17:49 <notmorgan> dhellmann: i voted and concur with your vote.
20:17:51 <dhellmann> yeah, this tag was defined very carefully to avoid having to keep having this discussion at all
20:18:00 <mtreinish> 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 <thingee> so new tag ... if there's value
20:18:17 <notmorgan> thingee: i said as much in my review.
20:18:19 <dims> thingee  mugsie|mobile ++
20:18:26 <ttx> thingee: yes
20:18:27 <dougwig> this tag has some overlap with computer:starter-kit idea, imo.
20:18:30 <dhellmann> mtreinish : if there are issues with projects on the list, we should address those one at a time.
20:18:31 <mtreinish> I can respin it as a new tag, thats easy enough to
20:18:37 <dougwig> /this tag/this change/
20:18:56 <dims> mtreinish : sounds like the right thing to do
20:18:56 <thingee> sigmavirus24: yea what about compute:starter-kit as dougwig suggested
20:19:01 <ttx> 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 <mestery> dougwig: Good point
20:19:07 <sigmavirus24> huh?
20:19:12 <dhellmann> mtreinish : like http://governance.openstack.org/reference/tags/starter-kit_compute.html ?
20:19:14 <notmorgan> ttx: starterkit seems to cover this anyway
20:19:14 <sigmavirus24> How did I get pulled into this?
20:19:16 <flaper87> thingee: you meant dougwig
20:19:16 <flaper87> :D
20:19:20 <flaper87> sigmavirus24: typo
20:19:21 <notmorgan> sigmavirus24: typo?
20:19:24 <sigmavirus24> ah
20:19:28 <thingee> sigmavirus24: http://governance.openstack.org/reference/tags/starter-kit_compute.html
20:19:29 <dims> :)
20:19:30 <jroll> 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 <mestery> notmorgan: lol
20:19:41 <johnthetubaguy> 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 <mugsie|mobile> Why should only base iaas be covered by defcore?
20:20:13 <notmorgan> johnthetubaguy: it is mostly historical. it was a baseline to start with, long term it should be something we can drop
20:20:13 <dhellmann> johnthetubaguy : the tag is an implementation of our duties under the bylaws w.r.t. the defcore committee
20:20:15 <mtreinish> 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 <notmorgan> just not yet
20:20:15 <thingee> sigmavirus24: oh heh, for some reason I thought I read last night you starting this, sorry
20:20:25 <ttx> 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 <sigmavirus24> thingee: no worries :D
20:20:29 <dhellmann> 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 <notmorgan> ttx: right, starterkit i see as the intention of this change.
20:20:46 <dhellmann> 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 <mtreinish> 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 <notmorgan> ttx: in spirit if not in the letter
20:21:02 <thingee> notmorgan, dhellmann +1
20:21:06 <ttx> notmorgan: except it's larger than starter-kit
20:21:19 <notmorgan> ttx: hence my view it's the spirit of the change
20:21:21 <dims> "has-interop-tests"?
20:21:27 <notmorgan> even though it's a narrower tag (starterkit)
20:21:29 <johnthetubaguy> mtreinish: it does feel wrong to side step our obligations around maintaining the tag
20:21:34 <sdague> tags are cheap, so lets not overload existing things
20:21:36 <dhellmann> mtreinish : if we end up with 2 interop processes, we're going to have different versions of interoperability
20:21:47 <mugsie|mobile> 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 <mugsie|mobile> (Or Designate, but I would argue we should be base iaas)
20:22:17 <ttx> 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 <dhellmann> ttx: it's not our job to define trademark programs
20:22:30 <notmorgan> so, lets invert this.
20:22:33 <ttx> dhellmann: right
20:22:34 <dhellmann> that's the board's job
20:22:34 <johnthetubaguy> so tested for interop and in the OpenStack-powered compute are not the same thing right?
20:22:40 <thingee> dhellmann: +1
20:22:42 <notmorgan> if defcore wants to propose the "trademark" tag
20:22:43 <dhellmann> and they're doing that by creating different programs as needed
20:22:43 <flaper87> dhellmann: ++
20:22:45 <notmorgan> let them.
20:22:48 <dims> dhellmann : we need something to reflect which ones we cover under trademark programs?
20:22:49 <notmorgan> and i'll support it
20:22:53 <notmorgan> i don't want the TC to define it
20:22:57 <ttx> 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 <mtreinish> 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 <ttx> markvoelker: ++
20:23:07 <notmorgan> defcore/board.
20:23:11 <johnthetubaguy> notmorgan: hence my suggestion of adding the tag to every project, if thats what we want to do
20:23:22 <dhellmann> 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 <flaper87> markvoelker: ++
20:23:30 <notmorgan> johnthetubaguy: i'd rather let this tag die long term. it's very historical
20:23:39 <dims> markvoelker ++
20:23:39 <flaper87> we can have a tag for what projects are interoperable, as it's been mentioned already
20:23:43 <johnthetubaguy> notmorgan: I am OK deleteting it
20:23:45 <dhellmann> 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 <johnthetubaguy> markvoelker: totally +1 that
20:23:48 <sdague> right, tc-approved-release is what the TC has said the board can consider for interop
20:23:50 <ttx> notmorgan: unfortunately the bylaws change very slowly
20:23:57 <notmorgan> ttx: yes i know.
20:23:57 <cdent> 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 <dhellmann> 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 <sdague> cdent: well, it's more subtle than that
20:24:17 <mugsie|mobile> cdent: ++
20:24:21 <flaper87> cdent: I don't think that's the intention
20:24:21 <notmorgan> cdent: we have unfortunately already delegated that long ago
20:24:34 <dhellmann> cdent : not abdicate, collaborate
20:24:38 <notmorgan> cdent: but the intention here is not to have the TC dictate what is defcore sprecifc
20:24:49 <cdent> sdague: I know it is more subtle than that, but it does _sound_ that way.
20:25:00 <sdague> 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 <notmorgan> cdent: but have defcore propose from their side as well getting collaboration
20:25:05 <dhellmann> 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 <dhellmann> and of course anyone can go to defcore meetings and argue points there
20:25:25 <hogepodge> cdent: defcore is a board process which seeks direction from tc
20:25:26 <sdague> 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 <notmorgan> 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 <dhellmann> that process is open, and done through code review
20:25:36 <ttx> cdent: the weapon you can enforce interoperability with is trademark programs -- and that's the board prerogative
20:25:42 <sdague> and we've generally agreed at this point the menu is bigger than defcore needs, and that's fine
20:25:51 <sdague> because nothing on the menu is rediculous
20:25:52 <notmorgan> so i'd rather have the proposal inverted if we're using it in this way
20:26:03 <dhellmann> sdague : right, we never want this list to be too much smaller than what defcore needs/wants
20:26:06 <dims> so we should not take things out of that menu
20:26:08 <notmorgan> we work with defcore to determien what the tag is. anyway i think i've said enough.
20:26:10 <ttx> cdent: they get to define what the OpenStack[tm] can be applied to
20:26:19 <sdague> 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 <dhellmann> notmorgan : all of that work was already done, that's how the tag was created in teh first place
20:26:31 <notmorgan> dhellmann: right
20:26:40 <flaper87> dhellmann: ++
20:26:44 <notmorgan> dhellmann: so nothing to change imo
20:26:48 <dhellmann> sdague : right, that's what we said when we created the tag
20:26:56 <rockyg> ++
20:27:01 <dhellmann> I feel like there's just some history here that folks don't remember/know/understand.
20:27:05 <sdague> we can decide that stuff should come off the menu. That's fine, that's a very specific different thing.
20:27:15 <edleafe> dhellmann: ++
20:27:18 <mestery> dhellmann: ++
20:27:22 <dhellmann> sdague: yes, but we should do that deliberatively and one project at a time
20:27:32 <sdague> but I don't think we want to conflate that with what's actually being interop tested
20:27:34 <dims> dhellmann : agree
20:27:35 <dhellmann> and with "reasons" beyond "cleaning up"
20:27:37 <notmyname> dhellmann: seems like a good summary of a lot of openstack discussions ;-)
20:27:40 <sdague> because it always was supposed to be larger
20:27:45 <ttx> I should probably unearth links to the orginal discussion for context
20:27:46 <dhellmann> notmyname : so true
20:27:56 <dims> sdague : so we need a tag that reflects what's being defcore-tested
20:28:02 <sdague> dims: that would be fine
20:28:02 <dims> at this moment
20:28:20 <hogepodge> sdague: dims: defcore is a very small subset of openstack, "core", and we could communicate that better.
20:28:27 <dhellmann> 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 <annegentle> mtreinish so is that the need, to indicate whats tested?
20:28:44 <sdague> hogepodge: right, given the amount of confusion, I think a tag would actually be quite useful
20:28:48 <dims> dhellmann : yep, so we don't need to do that here
20:28:51 <hogepodge> sdague: +1
20:28:55 <ttx> 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 <sdague> because I bet most of the TC doesn't know what the list is :)
20:29:00 <sdague> even though they could look it up
20:29:06 <dims> haha
20:29:06 <rockyg> dhellmann, dims ++
20:29:18 <rockyg> Defined in DefCore repo.
20:29:19 <dims> one google search away :)
20:29:22 <mtreinish> 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 <hogepodge> ttx: sdague: especially since compute will capture keystone, cinder, nova, glance, neutron. it's confusing
20:29:36 <dhellmann> sdague : how about a link from http://governance.openstack.org/reference/tags/tc-approved-release.html to that info?
20:29:49 <dims> mtreinish : what yardstick would you use to measure that?
20:29:49 <mugsie|mobile> and again,  why should that list only be iaas?
20:29:54 <annegentle> mtreinish that was originally the starter kit
20:30:11 <sdague> annegentle: it's not
20:30:13 <mestery> annegentle: I didn't think the starter kit was for interop
20:30:18 <hogepodge> but, a defcore tag should say 'defcore' to prevent even more confusion
20:30:20 <sdague> mestery: ++
20:30:31 <mtreinish> annegentle: maybe, but if so I feel there is a disconnect in the messaging then
20:30:32 <annegentle> sdague mestery ok, right, it was for computing
20:30:34 <mestery> yes
20:30:41 <annegentle> mtreinish nope I'm wrong :)
20:30:42 <sdague> right, lets not conflate things
20:30:58 <johnthetubaguy> mestery: are you suggesting the menu is too big for defcore right now, or something different?
20:31:03 <sdague> because there are a few different slices here, which have very close member sets, but they are for different reasons
20:31:12 <flaper87> so, the time is almost up for this topic. Can we summarize the discussion and write down the main take-aways ?
20:31:13 <sdague> and that was the whole problem with the "integrated release"
20:31:23 <mestery> johnthetubaguy: I'm not suggesting anything, I was just saying the "compute:starter" tag was not indicating interop
20:31:24 <dhellmann> right
20:31:39 <dims> mestery : ack
20:31:41 <johnthetubaguy> mestery: sorry, I used the wrong name, that was for mtreinish
20:31:51 <mestery> johnthetubaguy: heh, no worries :)
20:32:08 <anteaya> so many m's
20:32:11 <mtreinish> johnthetubaguy: I think it is, like horizon isn't likely ever gonna be an interop requirement
20:32:13 <sdague> mtreinish / hogepodge so how about a whole new tag here?
20:32:26 <johnthetubaguy> mestery: my typing skills at 9pm are even worse than normal!
20:32:39 <dhellmann> 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 <sdague> mtreinish: well, I think I agree with dhellmann that we should do deletes from that 1 at a time.
20:32:44 <mtreinish> 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 <flaper87> johnthetubaguy: try it at 10pm :P
20:32:47 <notmorgan> johnthetubaguy: the old "m<tab>" trap
20:32:53 <notmorgan> johnthetubaguy: i am very familiar with it.
20:32:57 <mtreinish> sdague: sure, I can do it as that
20:32:58 <mugsie|mobile> mtreinish: but why does it have to be iaas?
20:33:11 <mugsie|mobile> flaper87: I feel your pain
20:33:20 <mtreinish> mugsie|mobile: well what kinda of openstack cloud doesn't use iaas as a base?
20:33:23 <johnthetubaguy> flaper87: we should compare hours after evening meal or something, heh
20:33:30 <ttx> 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 <flaper87> ok, I guess we'll iterate again over the new patchset with the new tag
20:33:39 <mestery> ttx: ++
20:33:41 <thingee> ttx: +1
20:33:47 <dhellmann> mtreinish : I think you're trying to pull the TC into an area that's the board's responsibility.
20:33:49 <johnthetubaguy> mtreinish: sdague: yeah, I am +1 the one by one removal, FWIW
20:33:52 <mtreinish> I'm fine with working it as a new tag
20:33:57 <dougwig> mtreinish: can you really get a large group of people to define IaaS the same way?
20:34:00 <ttx> There might be room for another tag (or not) but let's wait until that is proposed ?
20:34:03 <hogepodge> sdague: yes, defcore has meaning and a tag to capture that is useful
20:34:04 <mtreinish> dhellmann: interop is very much a TC thing
20:34:06 <johnthetubaguy> and a new tag for the new thing sounds like a nice idea too
20:34:11 <sdague> hogepodge: ++
20:34:13 <dhellmann> mtreinish : defining sets of things though?
20:34:19 <sdague> ok, so mtreinish has 2 todos, right?
20:34:29 <flaper87> We should wait for mtreinish's new PS and comment there.
20:34:29 <ttx> We are approaching our timebox
20:34:30 <johnthetubaguy> 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 <sdague> new tag, plus propose any appropriate deletes?
20:34:40 <mugsie|mobile> jroll ++
20:34:47 <thingee> jroll: heh
20:34:49 <hogepodge> mtreinish: I'd like for projects outside of defcore to define what interop means to them too, again, guidance
20:34:50 <sdague> and we move on those in gerrit
20:34:51 <dhellmann> where "appropriate deletes" includes detailed reasons beyond cleaning things up
20:34:52 <edleafe> jroll: ++
20:34:56 <mtreinish> jroll: I was thinking only from the api side, not the functionality
20:34:59 <sdague> dhellmann: absolutely
20:35:00 <jroll> (I get the removal motivation here, but "not IaaS" heh)
20:35:04 <jroll> mtreinish: yeah, fair
20:35:11 <johnthetubaguy> dhellmann: +1
20:35:16 <dims> mtreinish : +1
20:35:30 <mtreinish> jroll: in the ironic case it goes through nova for the most part :)
20:35:36 <sdague> jroll: yeh, ironic is super weird in not having a user API from an interop perspective
20:36:02 <ttx> OK, let's move on to next topic
20:36:06 <sdague> 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 <jroll> 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 <thingee> ttx: +1 move on
20:36:30 <sdague> jroll: agree
20:36:47 <ttx> please follow-up on that review
20:36:54 <ttx> #topic Add golang as an approved language - benefits vs. costs, and the scope clarification option
20:37:00 <ttx> #link https://review.openstack.org/312267
20:37:07 * edleafe gets popcorn
20:37:12 <ttx> 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 <flaper87> edleafe: share
20:37:26 <ttx> So I presented two alternatives: "yes" and "no and do things in other languages as OpenStack dependencies"
20:37:29 <thingee> 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 <ttx> 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 <ttx> Finally, a "yes but everything that can be done in Python should still be done in Python" option emerged recently
20:38:04 <dhellmann> ttx: I like the distinction, but that thread got off track so fast I didn't follow up
20:38:07 <notmorgan> so i think adrian otto summed up my vew perfectly: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095827.html
20:38:09 <ttx> 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 <mestery> dhellmann: ++ to that
20:38:25 <ttx> TC members, please order the following options in descending order of preference
20:38:30 <ttx> #1: Yes to golang, without restrictions
20:38:33 <annegentle> I enjoyed the trip in the five years ago time machine
20:38:34 <dhellmann> ttx: it is extremely unlikely that if we approve the use of golang we could avoid having projects start rewriting things
20:38:40 <ttx> #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 <ttx> #3: Components requiring golang should really be developed as OpenStack dependencies, no need to expand the language set now
20:39:00 <edleafe> annegentle: yeah, I remember the discussion, but missed that meeting
20:39:00 <ttx> #4: Some other solution: remaining options don't work for me
20:39:09 <ttx> At this stage I think I'm 3,2,1,4
20:39:10 <notmorgan> #2, #1, #3
20:39:11 <dims> 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 <thingee> 3, 2, 1, 4
20:39:20 <flaper87> #3 #2 #1
20:39:35 <notmorgan> and very strongly prefer #2 to #3
20:39:38 <dougwig> dhellmann: are some of those rewrites good things, or is it all bad?
20:39:38 <dims> #2 #1 #3 #4
20:39:47 <mtreinish> 3,2,1,4
20:40:00 <annegentle> My preference: 3, 2, 1
20:40:04 <dhellmann> dougwig : the comments I saw made no distinction and were effectively "I'll rewrite everything because I can"
20:40:08 <johnthetubaguy> 2,3,4,1
20:40:09 * notmorgan doesn't see 4 as an option.
20:40:17 <dhellmann> 3, 2, 4, 1
20:40:17 <sdague> 3,2,1,4 I think, though 2 & 3 are kind of close for me
20:40:34 <ttx> notmorgan: #4 is "none of the above"
20:40:34 * dhellmann waits for ttx to apply condorcet rules in his head
20:40:34 <mestery> #2 #3 #1
20:40:41 <mtreinish> notmorgan: well #4 is the cause of and solution to all of life's problem
20:40:42 <flaper87> dhellmann: lol
20:40:42 <notmorgan> ttx: hence i don't see it as an option ;)
20:40:46 <johnthetubaguy> 2 and 3 are a very close call for me too, honestly
20:40:57 <dims> mtreinish : that's #41 :)
20:41:00 <ttx> dhellmann: I didn't really expect 3 to be so popular given the silence on that thread
20:41:00 <fungi> dougwig: there's at least one project who suggested they wanted to rewrite a component in go because someone had already done a poc in it so reusing that would be less work than trying to optimize the python code in place
20:41:01 * flaper87 hands johnthetubaguy a coin
20:41:19 <dhellmann> ttx: every time I started to reply there were another 10 messages to read...
20:41:21 <mugsie|mobile> fungi: that is a bit of an over simplification
20:41:26 <mtreinish> dims: nah, it's actually beer :) (it's a simpsons quote)
20:41:33 <dims> :)
20:41:39 <flaper87> dhellmann: it took me a good piece of today to catch up
20:41:48 <ttx> dhellmann: untrue! that thread was pretty calm
20:41:48 <sdague> ttx: or it's just hard to build up the emotional energy for it
20:42:00 <dougwig> dhellmann: fungi: wow, i would expect programmer standard laziness to not ditch oslo et al without a good reason.
20:42:01 <dhellmann> ttx: maybe I should be checking email more often
20:42:02 <annegentle> does the diff between 3 and 2 then require defining dependency borders?
20:42:14 <fungi> mugsie|mobile: best summary i have, though i'm sure there's more to it for that case
20:42:21 <ttx> annegentle: #2 is simple, it's just yes with some words added
20:42:23 <mugsie|mobile> There is
20:42:24 <mtreinish> dhellmann: heh, yeah I was in a similar situation on that thread
20:42:36 <annegentle> that is, does the difference get into the plugin boundaries also?
20:42:44 <notmorgan> ttx: basically (i'll quote adrian): "Openstack projects shall use Python as the preferred programming language. Golang may be used as an alternative if the project leadership decides it is justified."
20:42:48 <dhellmann> dougwig : I think NIH is trumping laziness in those cases
20:42:50 <notmorgan> something like that ^ annegentle
20:42:55 <ttx> annegentle: #3 is more tricky. We need to explain what "everything where python is not sufficient should really be an openstack dependency" actually means in specific cases
20:43:03 <annegentle> notmorgan the problem with aotto's language though is "what's project leadership" defined as
20:43:08 <dougwig> dhellmann: won't those types produce lousy python anyway? i'm not sure that's better.
20:43:14 <mugsie|mobile> dhellmann: not so, in some of them we do not need any olso.* libs
20:43:15 <thingee> annegentle: bingo
20:43:18 <annegentle> ttx okay, yeah, that's what I thought.
20:43:21 <flaper87> annegentle: <3
20:43:22 <notmorgan> annegentle: i prefer a change to "demonstrobly needed"
20:43:27 <notmorgan> aka how swift justified it
20:43:28 <ttx> annegentle: in some cases it's simple (think gnocchi). In others it's complex (think Swift)
20:43:30 <annegentle> notmorgan and then that five year history lesson was nice in talking about autonomy
20:43:32 <notmorgan> that was good.
20:43:37 <dims> notmorgan : demonstrate to who? TC?
20:43:38 <dhellmann> mugsie|mobile : you're not doing configuration?
20:43:43 <jroll> notmorgan: which comes down to #1, right? "project leadership" implies no TC interaction there
20:43:56 <dims> that's why i prefer #2
20:43:58 <notmorgan> jroll: it is defining loose bounds
20:44:02 <thingee> notmorgan: we're already seeing other projects' leadership jumping on this now.
20:44:05 <notmorgan> jroll: a social and community project
20:44:08 <sdague> dhellmann: or logging
20:44:11 <notmorgan> s/project/contract
20:44:11 <edleafe> jroll: exactly. It's open season at that point
20:44:20 <ttx> dims: I think we can recognize a good technical rationale when we see one. The one posted for Swift explaining that they exhausted their options to solve their issue with Python was pretty compelling
20:44:26 <notmorgan> it's about phrasing.
20:44:34 <notmorgan> but that is why i said #2 then #1
20:44:39 <dims> ttx : i mean do projects have to come to TC for a decision?
20:44:50 <notmorgan> dims: please no.
20:44:56 <dims> exactly notmorgan
20:45:06 <jroll> so it's #1 then
20:45:12 <mestery> jroll: seems like it
20:45:20 <jroll> (to be clear, I'm personally okay with that)
20:45:34 <notmorgan> jroll: shrug, i disagree, but it's close enough i can't argue further.
20:45:34 <dougwig> so you want to prevent the SME's that have solid reasons due to the people problems around handling the abusers?
20:45:40 <thingee> ttx: others would argue as we've seen in notmyname's original thread that they've exhausted their options as well, even though some people in the community disagree. This is why I think special casing won't work.
20:45:55 <mestery> dougwig: I want no such thing.
20:46:01 <dhellmann> thingee : yeah, there's no way to special case this
20:46:01 <notmorgan> thingee: i believe the teardown was mostly of designate less of swift.
20:46:05 <thingee> saying you're going to have the community as oppose to the TC special case these as well is already showing a divide in agreement
20:46:07 <dougwig> (for the record, i'm not planning to write anything in go.)
20:46:18 <notmorgan> thingee: of the cases that were "exaughsted"
20:46:22 <flaper87> thingee: ++
20:46:25 <ttx> so #3 is more popular than #2. But most people aren't ready to fight the emotional battle that #3 means (including figuring out how a #3 would look like)
20:46:33 <annegentle> I'll be honest, it feels a little like we're giving up on the cross project discipline needed to make OpenStack operable. So if we're resigned to "welp, projects are gonna do what projects gonna do" then #2.
20:46:39 <annegentle> (that took me a while to type, heh)
20:46:50 <thingee> notmorgan: again, how to define when something has been exhausted ... there's already a split in the community from notmyname's original thread.
20:46:57 <ttx> annegentle: yeah, I can see how #2 is much more.. comfortable
20:46:58 <dhellmann> annegentle : that's disappointing, but seems true
20:46:58 <thingee> determine*
20:47:04 <flaper87> ttx: I'm ready
20:47:06 <anteaya> annegentle: I agree with you
20:47:11 <notmorgan> i strongly prefer #2 and #1 to #3
20:47:18 <anteaya> annegentle: I think your observation is accurate and disappointing
20:47:19 <mestery> notmorgan: ME too
20:47:21 <annegentle> notmorgan what's special casing again?
20:47:31 <dtroyer_zz> annegentle: yes, because there is a set of questions that many are actively avoiding and #3 hits them head on
20:47:39 <thingee> annegentle: swift can, but others can't, for now
20:47:39 <dhellmann> notmorgan : how would you define where it's appropriate?
20:47:39 <annegentle> notmorgan "only this project is coolkids?"
20:47:43 <notmorgan> annegentle: i'm for a simple phrasing that directs where it should be used, so sure #1
20:47:56 <ttx> so #3 is preferred to #2 but the people who prefer #2 feel more strongly about it
20:48:01 <edleafe> dtroyer_zz: avoidance and/or exhaustion
20:48:13 <notmorgan> annegentle: very simple phrasing. the expectation is you will demonstrate it as swift came to the table.
20:48:26 <notmorgan> but if that means i really mean option #1, then sure, option 1
20:48:39 <thingee> If you're concerned about community divide, I think either decision is going to result in that... so we shouldn't use that argument.
20:48:42 <jroll> notmorgan: well, the question is who you must demonstrate it to
20:48:46 <edleafe> ttx: so what happens when someone doesn't think the "clear description" applies to their case?
20:49:00 <jroll> notmorgan: if that is "project leadership" e.g. "ironic core team", I think that means #1. I think #2 means "TC"
20:49:00 <mestery> edleafe: Which will happen almost immediatly
20:49:05 <edleafe> s/someone/some project
20:49:09 <ttx> So here is what I propose
20:49:15 <notmorgan> i'd also be ok with saying "and not to replace the wsgi/API layer"
20:49:17 <ttx> morgan can champion option #2
20:49:25 <notmorgan> ttx: sounds to me i'm championing #1
20:49:30 <notmorgan> based on the folks here.
20:49:35 <johnthetubaguy> jroll: that wasn't my read really, #2 was just there are some guidelines, I thought?
20:49:39 <mestery> notmorgan: I think it does too
20:49:39 * dims champion's #2 :)
20:49:40 <ttx> Someone (I'll do it if nobody else has the energy for it) can champion option #3
20:49:55 <sdague> notmorgan: honestly, I would be much more comfortable with a project that was fully go than half and half
20:50:11 * edleafe would champion #3 if he were on the TC
20:50:18 <mugsie|mobile> Well, are we not already in #2 if projects have to get TC approval?
20:50:20 <notmorgan> but lets be fair, i am at the point of "can we stop with this convo, we already have javascript, some java, bash, python, etc"
20:50:37 <mugsie|mobile> As the current policy allows for TC allowed exceptions
20:50:42 <notmorgan> and i'm willing to go with "hey infra, is this going to be a problem specifically with our resources and do you have a solid reason not to support go"
20:50:43 <thingee> mugsie|mobile: that's a question of who would police this. thread has said TC to community.
20:50:46 <notmorgan> from that standpoint
20:50:48 <annegentle> ttx I'm not totally sure what tasks it would take to get to #3
20:50:53 <bswartz> we have java?
20:50:59 <dhellmann> notmorgan : and docs, and release, and i18n, and...
20:51:02 <notmorgan> bswartz: some. not a lot.
20:51:03 <anteaya> notmorgan: I don't think the decision is infra's
20:51:04 <sdague> because the boundary and skills are very different at that point. I think assuming that you are going to get a bunch of folks that are good at reviewing 2 langs in one tree is odd.
20:51:07 * bswartz blinks
20:51:12 <ttx> annegentle: right, up to the champion to come up with a description of what his world would look like
20:51:18 <anteaya> infra's job is to support the decisions the tc makes, not make them
20:51:19 <mtreinish> sdague: ++
20:51:21 <edleafe> anteaya: but infra's feedback is majorly important
20:51:26 <dims> dhellmann : i spent a few days looking at kubernetes repo
20:51:31 <notmorgan> anteaya: i am asking if itwould cause an issue with resources.
20:51:35 <annegentle> #3 is pretty sweeping technically isn't it ttx ?
20:51:36 <jroll> johnthetubaguy: I guess I'm trying to understand where morgan is at, but if #2 is "follow these guidelines" it's roughly equivalent to #1 to me (because the real concerns are fragmenting community and such, and I don't think usage boundaries will help that)
20:51:41 <notmorgan> anteaya: after that, i'm willing to accept it.
20:51:41 <anteaya> edleafe: yes it is, but infra is in the business of how, not what
20:51:41 <sdague> ttx: I guess that's a #5
20:51:49 <ttx> I thought the temperature read would bury #3, but since it's not buried, we need to investigate how feasiable it would be
20:51:59 <anteaya> notmorgan: that is a different question, and a fair one for infra
20:52:00 <sdague> #1 except the whole project has to be in one language
20:52:17 <ttx> sdague: oh boy, a new one
20:52:22 <notmorgan> anteaya: if there is a real concern aka, we don't have resources, we can't do it because golang is doesn't produce the same results in CI and we need to solve that first"
20:52:26 <dims> sdague : i can buy that
20:52:32 <notmorgan> anteaya: then we have a hit list that needs to be addressed first
20:52:33 <ttx> sdague: not sure what that one brings ?
20:52:40 <johnthetubaguy> jroll: ah, gotcha
20:52:41 <bswartz> sdague: that's a good idea but it kills horizon doesn't it?
20:52:45 <sdague> it brings a much more defined boundary
20:52:45 <fungi> bswartz: "have" java in the sense that there are java-based projects using our infrastructure, running jobs there and publishing/releasing from there
20:52:47 <ttx> sdague: avoid dual-language core reviewers ?
20:52:57 <dougwig> if #3, what about all the data plane projects that are currently in python? shouldn't the ideological divide apply there?
20:53:00 <notmorgan> anteaya: and that is what i feel infra has said that it isn't an issue.
20:53:10 <anteaya> notmorgan: right and as far as I know, notmyname has been working on an etherpad to address these questions
20:53:14 <dtroyer_zz> bswartz: that particular point keeps getting lost...
20:53:19 <dims> sdague : do we then say, new project cannot do what swift does?
20:53:24 <sdague> in the same way we assume projects interop over REST to each other, we assume that is a language neutral boundary we're all good with
20:53:28 <flaper87> dougwig: data plane is really the wrong distinction
20:53:43 <anteaya> notmorgan: it will be work, infra has not said the work is insurmountable, not that I have seen
20:53:45 <notmorgan> anteaya: right and that is where i place my blockers outside of that... i'm for adding/accepting it.
20:53:46 <sdague> because otherwise we're going to get all these odd internal cross language protocols that are different in every instance
20:54:13 * jroll wonders how the oslo team feels given there could eventually be a flood of oslo libs written in go
20:54:13 <dougwig> flaper87: ok then, how about !control plane?
20:54:19 <anteaya> notmorgan: that is fine, as long as we are clear that infra is not left being responsible for more that it is willing to be
20:54:20 <dhellmann> sdague : does that mean these projects wouldn't emit notifications on the message bus?
20:54:26 <edleafe> sdague: you'll also have two sets of cores for a project
20:54:39 <flaper87> dougwig: still wrong, you're kicking out glance, basically.
20:54:39 <sdague> dhellmann: they'd need an oslo.messaging
20:54:41 <notmorgan> anteaya: nope, i am asking for technical reasons based on our CI and infra that would be the reasons to hold off accepting
20:54:44 <sdague> and config, log
20:54:46 <notmorgan> anteaya: not "is this a good idea"
20:54:52 <notmorgan> anteaya: we're on the same page.
20:54:59 <dougwig> flaper87: yeah, i'm highlighting that it's an odd distinction we're drawing.
20:55:12 <jroll> sdague: ++ curious how oslo team feels here
20:55:19 <notmorgan> for the record. if we make a decision that is kicking a project out, i am against it categorically
20:55:21 <anteaya> notmorgan: seems we are, yes
20:55:26 <notmorgan> based upon this topic.
20:55:26 * flaper87 is trying to understand what #5 looks like
20:55:33 <dims> harlowja : around?
20:55:34 <thingee> five mins left
20:55:34 <ttx> Last question, I know who feels strongly against #3, who feels strongly against #2 ?
20:55:38 <annegentle> partially my sense is that #3 is where reality is sitting for swift, they have the ability to "plugin" and operate some golang code. Maybe I'm wrong though.
20:55:56 <gordc> lucky for swift, they don't use oslo. (unless that's changed)
20:55:57 <dhellmann> jroll : I hope no one is expecting the Oslo team to write those things. Some might, but I don't really know how many are interested.
20:55:58 <notmorgan> i worry #3 leads to dropping swift
20:56:04 <notmorgan> that is my strongest concern there.
20:56:12 <annegentle> gordc oh yeah and it's a total pain to scrape their config opt
20:56:18 <jroll> annegentle: they'd essentially need to move all of swift out of openstack, or ship that piece outside of openstack as a replacement to an in-openstack thing
20:56:21 <jroll> dhellmann: ++
20:56:25 <edleafe> notmorgan: but isn't hummingbird more of a plugin for swift?
20:56:26 <ttx> notmorgan: would you have some time in the coming week so that we can study this more closely ?
20:56:27 <sdague> dhellmann: no, I would expect that to be part of the cost of bringing in a new language environment
20:56:35 <notmorgan> ttx: maybe.
20:56:40 <mestery> jroll: Right, notmyname said as much last week at the meeting I believe
20:56:41 <dims> ttx : i'd oppose #3
20:56:43 <johnthetubaguy> I thought the go bit of swift plugged into the python API bit?
20:56:44 <jroll> edleafe: no, it's a replacement of one "binary" required to run swift
20:56:46 <dtroyer_zz> sdague: +++
20:56:49 <jroll> AIUI
20:56:49 <edleafe> notmorgan: in the same sense as a C library in Python
20:56:50 <harlowja> dims whats up
20:57:05 <ttx> dims: noted. Wondering if anyone strongly opposes #2
20:57:08 <johnthetubaguy> jroll: hmm, I thought I checked that last week, and I was told the opposite
20:57:09 <thingee> ttx: I'm against #2 so far ... just because I haven't heard a good "description" of this special casing would happen.
20:57:17 <thingee> or who would police it
20:57:18 <ttx> thingee: noted
20:57:22 <dougwig> why would we keep the python backend for swift in openstack, if the recommended backend by that team is the go version?  just because it's python?
20:57:25 <johnthetubaguy> jroll: but that was my initial assumption
20:57:27 <jroll> johnthetubaguy: I could be wrong, but I'm curious how they're plugging go into python if so
20:57:31 <harlowja> i don't mind learning go, as long as there are people to help in supporting it (aka, oslo not == go dumping ground, lol)
20:57:33 <mestery> Right, the distinction between #1 and #2 is the line we draw, and that will be hard to do
20:57:35 <johnthetubaguy> jroll: +1
20:57:52 <flaper87> thingee: ++
20:57:56 <sdague> I mostly think the details of #2 are hard to get right
20:58:05 <thingee> sdague: yes
20:58:06 <flaper87> sdague: could you summarize #5 in the review ?
20:58:07 <notmyname> jroll: johnthetubaguy: happy to go over it, but not going to happen in the last 2 minutes
20:58:09 <dims> mestery : ttx : #1 is open season, so we can skip that
20:58:10 <ttx> sdague: #3 is not easier,might even be impossible
20:58:13 <johnthetubaguy> so I was seeing #2 as a set of guidelines
20:58:15 <jroll> johnthetubaguy: sounds like it's the object server rewritten, notmyname correct?
20:58:17 <gordc> sdague: agreed, same for #3.
20:58:19 <redbo> It's not an API binding, hummingbird is a web server.
20:58:24 <harlowja> go already uses the equivalent of oslo.config anyway via flags (The precursor to oslo.config anyway); so there u go :-P
20:58:25 <notmorgan> edleafe: possibly, i worry if you say hummingbird is a plugin, you now have a thing where swift is recommended "don't use the python impl"
20:58:33 <flaper87> ttx: time check
20:58:43 <ttx> flaper87: moving to Open discussion onw
20:58:45 <ttx> now
20:58:47 <johnthetubaguy> if #2 means its policed by some central group, I am against it
20:58:54 <johnthetubaguy> at least I think I am
20:58:59 <dims> johnthetubaguy : #2 is guidlines we publish
20:59:04 <dims> IMHO
20:59:05 <johnthetubaguy> dims: right, thats fine
20:59:12 * edleafe admires johnthetubaguy's certainty!
20:59:14 <notmorgan> johnthetubaguy: i'd just opt out of gating things at that point.
20:59:16 <ttx> I identified stakeholders for the next step, and will be in touch, trying to make progress with a resolution on this
20:59:24 <ttx> #topic Open discussion
20:59:40 <ttx> Last minute comments on anything else ?
20:59:40 <johnthetubaguy> edleafe: well, I mean in the context of defining #2
20:59:46 <notmyname> I'm not a fan of the whole "2 gladiators fighting it out for their respective armies" thing (ie champions for some viewpoint that then represent that view to everyone)
21:00:01 <ttx> notmyname: oh, that's not what I meant
21:00:04 <notmorgan> uh
21:00:08 <notmorgan> i have last mingute thing
21:00:11 <notmorgan> sec
21:00:14 <dims> notmyname : i think i signed up to propose a change to the review to reflect #2 :)
21:00:28 <notmorgan> gothicmindfood wanted to communicate that for the leadership thing, she will be sending an email out to the atendees in the next couple days
21:00:34 <notmorgan> look for it
21:00:35 <edleafe> johnthetubaguy: :)
21:00:43 <notmyname> dims: ack :-)
21:00:44 <notmorgan> we have a full (20 person) session scheduled.
21:00:47 <annegentle> cool notmorgan
21:01:03 <ttx> notmyname: I'm trying to see who cares enough to spend some time on refining what their solution would look like.
21:01:07 <notmorgan> so 24-48hrs there should be an email to the individuals not to the ML
21:01:15 <jroll> woot
21:01:24 <anteaya> ttx: that was how I interpreted it
21:01:25 * notmorgan is going to lean on notmyname for help on this championing
21:01:25 <thingee> time
21:01:28 <notmyname> ttx: ok
21:01:34 <notmorgan> notmyname: you're getting volunteered ;)
21:01:36 <notmorgan> hehe
21:01:41 <ttx> notmyname: I'll be in touch with you so that you can explain to me the various reasons why #3 is just plain impossible.
21:01:50 <notmyname> ttx: ok :-)
21:01:59 <ttx> (like, technically)
21:02:20 <ttx> alright time is up
21:02:23 <ttx> #endmeeting