20:01:42 <ttx> #startmeeting tc
20:01:43 <openstack> Meeting started Tue Aug  2 20:01:42 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:46 <openstack> The meeting name has been set to 'tc'
20:01:48 <ttx> Hello everyone! Our agenda for today:
20:01:53 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:55 * flaper87 bows and says hi
20:02:03 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:02:16 <flaper87> ++
20:02:17 <ttx> #topic Limited Use of Alternate Programming Languages vs. Policy and process for alternate programming languages
20:02:28 <ttx> (NB: if the discussion gets too noisy we might switch to voice turns, but let's try simple first)
20:02:35 <ttx> We have two proposals on how we could selectively allow alternate programming languages
20:02:41 <ttx> #link https://review.openstack.org/339175
20:02:45 <ttx> #link https://review.openstack.org/346243
20:03:02 <ttx> The first one from dims I would summarize as "allow selectively after analysis"
20:03:14 <ttx> The second one from notmyname I would summarize as "allow by default, get progress reports, potential veto before merge"
20:03:16 * edleafe_ reads on his phone
20:03:30 <ttx> Both introduce the concept of two tier of languages (official/supported vs. alternate/unsupported) as a way to clearly state what the "default" languages are.
20:03:39 <thingee> that was my understanding of each as well
20:03:48 <dims> good summary ttx
20:03:51 <ttx> Both assume that we actually want to allow usage of such alternate languages whenever that usage is "warranted" (i.e. when the default languages can't be used to solve the issue at hand)
20:04:01 <ttx> (rather than, say,  find a way to artificially keep things written in another language outside of official "OpenStack")
20:04:15 <ttx> So maybe we should first discuss that (agree on the end goal), and if we do, then discuss the less painful and most efficient way to reach it
20:04:20 <mtreinish> o/
20:04:25 <mordred> o/
20:04:31 <ttx> (i.e. the best way to discourage gratuitous usage of alternate languages and limit team frustration when rejected)
20:04:43 <ttx> So question to TC members to kick this off: how much do you like the idea of allowing usage of alternate languages whenever that usage is "warranted" ?
20:05:13 <mtreinish> ttx: define warranted
20:05:30 <mtreinish> that's my issue with proposals like that because it's always kinda subjective
20:05:33 <flaper87> not much. My concerns remain and I think we'll have a hard time defining warranted objectively
20:05:36 <ttx> mtreinish: as defined above: when the default languages can't be used to solve the issue at han
20:05:38 <ttx> d
20:05:41 <dims> one thing to add ttx, in my proposal, TC acts as a gatekeeper for new languages and the cross project team acts as keeper for allowing projects to use the blessed languages on a need basis
20:05:46 <flaper87> My concerns == community impact
20:06:36 <russellb> i like the idea of allowing usage of alternative languages when warranted.  (for some definition of warranted)
20:06:37 <gordc> flaper87: community impact on the project or on openstack?
20:06:44 <flaper87> gordc: both ?
20:06:44 <mordred> gordc: openstack
20:06:52 <flaper87> but yeha, mostly openstack
20:06:56 <thingee> gordc: both
20:07:03 <gordc> ack.
20:07:16 <ttx> johnthetubaguy seems +1 on the intent if I read his comments correctly (he had to drop off the meeting)
20:07:36 <mordred> so ... I don't have well structured thoughts here, even though the topic has been lurking for quite a while now
20:07:45 <dhellmann> my reluctance to take this path is still based on the teams asking to go first. One team hasn't demonstrated to me that they need to use another tool, and the other team hasn't demonstrated that they have the community commitment to be the right group to establish best practices for a new tool.
20:07:47 <prometheanfire> how are we going to track the dep trees of these new languages, will this need to be done in requirements?
20:07:58 <devananda> after a quick skim of the current state of both specs, i don't see a clear and objective definition of how the TC can decide what is or is not "warranted"
20:08:00 <gordc> if it's openstack, i'm assuming it's always going to have some non-trivial impact.
20:08:03 <notmyname> hasn't the idea of alternate languages already come up when javascript was added to python?
20:08:49 <mordred> notmyname: no, not really
20:08:50 <ttx> notmyname: I think it was more discussed when we decided to keep Horizon "in" OpenStack
20:09:03 <mordred> javascript is not an alternate language for writing openstack services
20:09:03 <ttx> and JS being grandfathered in as a result
20:09:16 <flaper87> mordred: ++
20:09:19 <annegent_> to me, the line is about REST API services also
20:09:21 <mordred> I do not think JS and openstack is a relevant comparison, grandfathered or no
20:09:23 <dims> mordred : ++
20:09:24 <notmyname> mordred: horizon isn't an openstack service?
20:09:24 <ttx> yeah, I don't place Go in the same group as JS (or YAML for the matter)
20:09:25 <mordred> annegent_: yes
20:09:36 <annegent_> the "pain outweighs gains" warranted line
20:09:37 <mordred> notmyname: it does not implement a server process in javascript
20:09:42 <ttx> basically we have one language for one task currently
20:09:44 <annegent_> er, maybe I mean that the other way 'round
20:09:44 <mugsie> well, just to play devils advocate ... there is nothing in the policy that blocks a nodejs server project ...
20:09:50 <mordred> notmyname: it uses javascript in browser to interact with the REST API it has that is written in python
20:09:51 <devananda> mordred's point is key -- and also goes to the other languages in your proposal, notmyname
20:09:59 <annegent_> mugsie there is policy that blocks that now.
20:10:03 <devananda> bash and yaml are languages, sure, but have not been used to write an openstack service
20:10:17 <mordred> we have PLENTY of non-python code in openstack
20:10:29 <notmyname> I think my point is that the supported language set used to be len 1, and now it's len > 1. so the idea of "only python is sufficient for openstack" seems to have already been crossed off the list
20:10:33 <notmorgan> devananda: if you write an openstack service in yaml (only), I'll be so impressed.
20:10:35 <annegent_> #link http://governance.openstack.org/resolutions/20150901-programming-languages.html
20:10:44 <mordred> all of that code is in service either of specific communities (ruby for puppet/chef) or domain specific piurposes (browser actions)
20:10:59 <jroll> notmorgan: I need deva doing useful things, please don't challenge him :D
20:11:00 <ttx> yes, so there seems to be room for allowing extra languages whenever Python can really not be used (think JS)
20:11:05 <mordred> notmyname: I can see why you'd think that, but I disagree
20:11:13 <mtreinish> jroll: but I kinda want to see a service all in yaml too :)
20:11:19 <mordred> notmyname: and I refer to my previous 2 sentences
20:11:20 <notmorgan> jroll: *shiftyeyes*
20:11:27 <jroll> hah
20:11:51 <dhellmann> could we cut the chatter today, please?
20:12:01 * edleafe is back home
20:12:15 <mordred> dhellmann: ++
20:12:35 * jroll apologizes
20:12:38 <ttx> The way I see it, we are OK with adding languages where Python can't be used. If Go was used to implement a piece that handled disk i/o in Swift I think we wouldn't have the same discussion -- the issue here is that it also is used for code that we usually run Python for (the REST API)
20:12:41 <flaper87> ttx: are we waiting for other votes from other TC members? How can we move the discussion forwarD?
20:12:42 <flaper87> ops
20:12:46 <flaper87> you faster than me
20:12:57 <mordred> it has been and continues to be my position that if we're going to start rewriting parts of openstack services in not-python, it should be as part of an effort to completely rewrite everything
20:13:12 <notmyname> ttx: an internal api that happens to be rest-ish right now and may or may not be in the future
20:13:16 <ttx> hence the risk of contagion to other services and the threat of gratuitous usage
20:13:25 <russellb> and if we were rewriting everything, i dont' think language would be problem #1 to deal with
20:13:35 <mordred> it is my opinion that the cost of just having some bits of some services in python and some in go is not a clear enough win to justify the cost
20:13:36 <mugsie> so, is the problem the people who asked to use the language, or the possibility of the new language. the former seems to be the bone of contention for some people
20:13:41 <notmyname> ttx: that's what we've been working on in swift in golang
20:13:46 <ttx> notmyname: good point -- do you mean there wouldn't be a rewrite of the proxy server in Go ?
20:13:53 <thingee> russellb: +1
20:14:05 <mordred> russellb: ++
20:14:33 <notmyname> ttx: I'm not interested in that right now. IMO there's a ton of other stuff we should be focusing on, and the ecosystem cost to dropping python (actually, wsgi) from the proxy server would be huge
20:15:06 <notmyname> ttx: clarification: I'm not interested in a golang proxy server. I am interested in this discussion and your thoughts
20:15:09 <ttx> flaper87: to answer your question, I want to have an idea of how much we support the end goal of those two proposals. We ended up the previous run with the idea that we could explore selectively adf
20:15:13 <ttx> adding*
20:15:19 <ttx> rather than blanket adding
20:15:28 <thingee> as from the thread kevin fox posted on issues that pre-date big tent ... there are some other priority technical issues to be dealt with
20:15:31 <ttx> Those two proposals propose selective add
20:15:53 <ttx> so are we ok with that goal ? No point in debating the details of each if we aren't.
20:16:11 <notmyname> mugsie: good question :-)
20:16:16 <ttx> Personally I'm fine with the idea, but would like the implementation to prevent contagion
20:16:23 <mordred> ttx: I am not on board with that goal, personally, no
20:16:26 <flaper87> ttx: you might want to use a #vote here, I guess
20:16:32 <flaper87> That way I think it'd be clearer
20:16:36 <mordred> so, consider me in the "no, I don't think it's worth debating details" camp
20:16:39 <ttx> ok, let me set that up
20:16:43 <flaper87> and it'd also stay logged/summarized
20:17:07 <devananda> fwiw, I am still not convinced we need to add another language, like Go, within the openstack namespace, for implementing components of the services that a) are implementable in python b) could be implemented as an external library and then consumed by existing python
20:17:25 <flaper87> I'd also try to avoid the "if warranted" part in the question as that's, imho, not relevant to this vote
20:17:36 <mugsie> flaper87: ++
20:17:45 <annegent_> I'd also say I'm unconvinced of a warranted need for a service rewrite in Golang.
20:17:53 <mordred> flaper87: ++
20:17:58 <ttx> #startvote Do we agree with the end goal of selectively allowing extra languages in OpenStack whenever Python ends up not being not the optimal tool for the task? yes, no
20:17:59 <openstack> Begin voting on: Do we agree with the end goal of selectively allowing extra languages in OpenStack whenever Python ends up not being not the optimal tool for the task? Valid vote options are yes, no.
20:18:00 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:18:02 <edleafe> devananda: +1
20:18:06 <ttx> does that work ?
20:18:10 <mordred> ttx: actually ...
20:18:16 <mordred> I think it would be worth being clearer
20:18:22 <ttx> #undo
20:18:23 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x7f5bbf2ca950>
20:18:36 <mordred> since as notmyname points out we already have other lnaguages
20:18:37 <dhellmann> you might have to endvote first? that removed a link...
20:18:37 <russellb> heh, that undo didn't quite work ..
20:18:38 <ttx> #endvote
20:18:38 <openstack> Voted on "Do we agree with the end goal of selectively allowing extra languages in OpenStack whenever Python ends up not being not the optimal tool for the task?" Results are
20:18:43 <ttx> sigh
20:18:53 <ttx> #link  https://review.openstack.org/346243
20:18:55 <ttx> le sigh
20:18:58 <mordred> I think the thing we're talking about is specifically key/necessary components of services
20:19:07 <flaper87> "Do we agree with the end goal of selectively allowing extra languages in OpenStack?"
20:19:08 <dhellmann> #link http://governance.openstack.org/resolutions/20150901-programming-languages.html
20:19:25 <ttx> mordred: propose alt text
20:19:30 <mordred> "Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purposes of writing services?"
20:19:36 <flaper87> mordred: ++
20:19:46 * devananda deletes what he was typing
20:19:48 <devananda> mordred: ++
20:19:50 <dims> "when absolutely necessary"? :)
20:19:54 <ttx> mordred: dedfine services, as the objectserver is an internal node in Swift... would that count ?
20:20:00 <mordred> ttx: yes
20:20:05 <ttx> Would the dns proxy from designate count ?
20:20:09 <russellb> "However we should not limit OpenStack service projects to these three programming languages in the future, as it would either mean using suboptimal tools, not being able to address specific problem spaces, or artificially excluding specific project teams."
20:20:10 <mordred> it's a key/required part of the swift service
20:20:22 <devananda> russellb: three?
20:20:36 <russellb> devananda: quote from the resolution dhellmann linked, bash/JS/Python
20:20:43 <mordred> that hummingbird is not the rest api itself does not make it any more essential in a world where it's merged, to swift as a service
20:20:48 <ttx> mordred: ok, so services/nodes
20:20:50 <mordred> s/more/less/
20:21:00 <ttx> let me cast that one
20:21:01 <mordred> sorry for that mistype -it really does change the meaning of the sentence
20:21:06 <mugsie> ttx: miniDNS is also a required sub service of designate
20:21:21 <mordred> mugsie: we do not write miniDNS
20:21:27 <mugsie> designate does
20:21:40 <mordred> oh - is that the go dns thing?
20:21:51 <mugsie> designate-mdns is (currently) a pythoin DNS server
20:22:00 <mordred> so yes - I agree, it's the equivilent example
20:22:00 <mugsie> mdns stands for miniDNS
20:22:18 <annegent_> is miniDNS something that can be reviewed and packaged separately?
20:22:28 <ttx> #startvote Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purpose of writing services? yes, no
20:22:29 <openstack> Begin voting on: Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purpose of writing services? Valid vote options are yes, no.
20:22:30 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:22:39 <mordred> #vote no
20:22:41 <flaper87> #vote no
20:22:43 <mtreinish> #vote no
20:22:46 <ttx> #vote yes
20:22:48 <thingee> annegent_: this was our proposal to have the separate swift component written in go be packaged separately.
20:22:51 <dims> #vote yes
20:22:58 <dhellmann> #vote no
20:23:00 <thingee> #vote no
20:23:03 <russellb> #vote yes
20:23:05 <ttx> (for some serious amount of "selectively"
20:23:06 <ttx> )
20:23:10 <annegent_> #vote no
20:23:31 * edleafe wishes he could vote...
20:23:37 <sdague> #vote no
20:23:48 <ttx> #endvote
20:23:49 <openstack> Voted on "Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purpose of writing services?" Results are
20:23:50 <openstack> yes (3): dims, ttx, russellb
20:23:51 <openstack> no (7): annegent_, mtreinish, thingee, sdague, mordred, dhellmann, flaper87
20:24:00 <ttx> OK, so far from consensus with heavy leaning on NO
20:24:10 <ttx> My next question then would be...
20:24:23 <ttx> How do we address Swift needs ? What is their next step ?
20:24:43 <notmyname> fantastic question
20:24:43 <ttx> They clearly rujn into an issue where Python don't get them the disk i/o behavior they need
20:25:02 <thingee> ttx: when this was originally proposed, the TC recommended it be packaged separate for the component that warrants a different language.
20:25:12 <russellb> artificial code split of in/out of OpenStack is kind of lame IMO...
20:25:18 <jbryce> russellb: ++
20:25:18 <mugsie> russellb: ++
20:25:19 <edleafe> Wasn't the suggestion that hummingbird be packaged separately rejected becuase it would "fracture the team"?
20:25:25 <mugsie> yes
20:25:31 <dougwig> russellb: so is an inconsistent policy in this case.
20:25:32 <ttx> russellb: yes, I'm not happy with that solution either
20:25:32 <devananda> thingee: that has been my suggestion a couple times, but it creates a significant impact on any developer(s) writing the go-side of that
20:25:59 <ttx> All those who voted no, would the "external" development be your answer to the "next step" question, or do you have other ideas ?
20:26:27 <thingee> devananda: for the folks who have leaned on separate packaging, it was to reduce the impact by having it be on a project, not the entire community.
20:26:37 <notmyname> beyond the team impact (which would be huge), it would also have a significantly high technical cost, and beyond that, it would force us into a situation of presenting to users an upstream "openstack" version that isn't supported/maintained or just flat out missing
20:26:49 <mordred> ttx: IFF the external development item can be installed via normal distro package mangaers in a way that allows for pip + other-requirements to express the need
20:27:28 <edleafe> notmyname: there are lots of requirements that are used by projects that are not part of OpenStack
20:27:35 <tdasilva> does "external" development mean completely outside of the openstack namespace?
20:27:40 <mordred> ttx: if the thing is an external component that is onlyu installable by cloning a git repo and running a build process somewhere, I do not think that would be particularly useful
20:27:42 <edleafe> that doesn't make them any less 'upstream'
20:27:44 <dhellmann> tdasilva : no
20:27:45 <ttx> tdasilva: no, just outside of TC's reach
20:27:48 <flaper87> ttx: that would be the solution I'd propose too.
20:27:57 <ttx> so smae tooling
20:28:06 <flaper87> tdasilva: CI/gerrit/etc will still be available
20:28:13 <ttx> which kinda reduces the technical pain, but the lameness stays imho
20:28:26 <tdasilva> so we would break apart a repo like openstack/swift and openstack/hummingbird just because....seems really lame
20:28:36 <jbryce> for me it’s not just about hummingbird, it’s about losing the thing that has made openstack work as a competitive maketplace of ideas. tools will change and grow. many of the things we use for our great development process around python didn’t exist in their form before we put them together over the last few years. future innovation is going to happen in languages other than python and that can happen in openstack or
20:28:36 <jbryce> outside of openstack, wherever those contributors feel welcome
20:28:36 <russellb> lame++ :)
20:28:41 <mugsie> i will give an example from designates side - for us to add a new record type  (A, AAAA, CNAME, etc) we would have to release a version of designate that created the tables, then a version of mdns that could render it to wire format, then a version of designate that used the version of mdns with tghe new code
20:28:47 <devananda> same tooling, with the end goal of being packaged by various distros and installable via apt/yum/... would be technically feasible and yet still alienate that team
20:28:57 <russellb> jbryce: ++
20:29:22 <mordred> another option is to write performance critical bits in cython or something similar
20:29:28 <jbryce> sometimes it feels to me like when a proprietary company gets really stuck on the decision of what to do when they have a cash machine on an existing product while facing a disruption from a cheaper competitor
20:29:49 <ttx> There is another solution, which is to grant Swift a specific exception, but it's also lame because it's just one more way Swift is special, and this time it's not coming from them
20:29:50 <jbryce> mordred: the thing is, developers in our community already wrote a more performant version. they wrote winning code and a winning implementation
20:30:01 <mtreinish> mordred: that is the normal pattern for something like this
20:30:06 <mugsie> mordred: that is a possiblity  - but are we allowed?
20:30:19 <mugsie> its C, whihc is not on the list
20:30:38 <edleafe> mordred: you could write them in go and compile to a Python module
20:30:43 <mugsie> which comes back to the "ever have a new language vote" that just happened
20:30:47 <russellb> right, not sure why that's different or better (Python C bindings)
20:31:10 <dougwig> if you're setting the expectation of non-python projects in infra as non-openstack projects, what kind of priority level for support will there be for breakages?  i would implicitly assume it's less than official projects?
20:31:40 <ttx> dougwig: best effort I would say, yes
20:31:46 <mugsie> which some of the critical gate infra structure might rely on
20:32:22 <jbryce> the thing that can keep an open community from falling into that proprietary company trap (milk the cash cow or disrupt yourself because someone else will do it if you don’t), is that we don’t have the income imperative and we can develop these technologies in the open and see which approaches are working or not.
20:32:28 <mugsie> i.e. if there is a bug in hummingbird and it is an unoffical project - but it blocks the gate for $reason - what do we do?
20:32:35 <annegent_> jbryce my sense is that it's the plugability that I struggle with. If you can't make the golang piece plugable it means you're abandoning the other service implementation?
20:32:42 <mordred> mugsie: actually, cythion  is done in a python syntax, and pip/setuptools deals with it just fine
20:32:44 <mordred> so to me it's still 'python'
20:33:08 <mugsie> mordred: OK, I would not have made that distinction.
20:33:28 <annegent_> jbryce which is what I read from notmyname "presenting to users an upstream "openstack" version that isn't supported/maintained or just flat out missing"
20:33:32 <mordred> jbryce: I hear that argument, I really do. I'm not ignoring it. just in my personal best judgement it is not currently worth the pain
20:33:40 <annegent_> jbryce it's still too black and white.
20:34:11 <dhellmann> my concerns about doing this, in this way, starting with this team, are too long for irc, so: http://paste.openstack.org/show/545744/
20:34:25 <ttx> My desired outcome here is that we find a solution for Swift that lets them use the tech they need, but without creating a contagion effect of gratuitous rewrites throughout OpenStack services. I'd also like an outcome where other Python coders in our community would go and help Designate write their stuff in Python (or allow them to use Go too if that ends up not being possible, but I don't
20:34:27 <ttx> believe in that). Feels like I'm a minority though
20:34:49 <mordred> jbryce: I do not believe we have achieved the success we have achieved by letting everyone do everything in whatever way they feel. in fact, I think we have achieved success in spite of the amount of divergence we already have. I do not believe introduction of more divergence will lead to greater success
20:34:55 <ttx> #link http://paste.openstack.org/show/545744/
20:34:59 <russellb> ttx: i'm with you.
20:35:13 <mordred> that is, of course, merely my point of view, and as always, I'm happy to defer to others happily should I wind up to be wrong
20:35:30 <mugsie> dhellmann: so, your conceres are still the teams, not the "should we have another language" ?
20:35:33 <russellb> but i'm not getting the feeling that any positions are changing here
20:35:35 <mugsie> concerns*
20:36:01 <dhellmann> mugsie : both, but this is why I'm comfortable sticking with "no" for now
20:36:28 <devananda> jbryce: innovation is happening in many languages, not just golang or python, but our development process/tooling is, as you pointed out, pushing the envelope of what can be done with python. allowing in another language doesn't immediately create the same benefits for that languages' developers
20:36:46 <dhellmann> mugsie : all of the community division and technical divergence concerns I have would be addressed better by a team that had proven willing to collaborate on those areas in the past
20:36:51 <sdague> mordred: I think I mostly agree with you there, especially as someone that has wrangled with a lot of that divergence (though less so than dhellmann)
20:37:07 <JayF> devananda: jbryce: My fear; and I think the underlying fear in jbryce's comments, is that we'll lose smart folks who want to point their brain in that direction, rather than winning them over to the "OpenStack way"
20:37:10 <jbryce> devananda: but goland is the other language where innovation is happening amount OUR developers already. right now. dramatically improving the operation of a core service
20:37:11 <devananda> jbryce: in fact, trying to enable the same scale of development process we have done in Python for other languages will take away resources from what we're doing with pyhton today
20:37:45 <mordred> jbryce: it improves the operational performance. it does not improve its alignment with the operation of the other openstack services
20:37:45 <jbryce> devananda: that’s assuming that making an inclusive decision here will not include anyone else who wants to pitch in on those things
20:37:46 <ttx> So my read of the TC today is "the majority of us don't want to selectively add alternate languages, components in another language should be written as unofficial repositories and be depended on" -- is that correct ?
20:38:13 <dhellmann> ttx: that is my position, for now
20:38:17 <flaper87> ttx: yes
20:38:24 <annegent_> mine as well
20:38:27 <mordred> ttx: yes
20:38:29 <ttx> I'll info it then
20:38:40 <mugsie> dhellmann: what could be done to help move your position?
20:38:57 <dhellmann> mugsie : address the concerns I've described in that pastebin
20:39:13 <ttx> #info the majority of us don't want to selectively add alternate languages, components in another language should be written as unofficial repositories and be depended on
20:39:26 <annegent_> mugsie I won't speak for dhellmann but addressing the concerns listed there would help show a willingness and attitude shift.
20:39:29 <dhellmann> mugsie : and not just ticking the boxes, but demonstrating a difference in approach over the long term
20:39:46 <mordred> annegent_, dhellmann ++
20:39:47 <ttx> still need to read that pastebin
20:39:52 <mugsie> dhellmann: and for designate - I would think we cover most if not all of these
20:40:09 <russellb> what we call "in" vs "out" of openstack is feeling more and more artificial and meaningless ... this position makes that worse
20:40:32 <dhellmann> mugsie : in the email thread where this came up someone showed significant performance improvements with what seemed like quite small changes to designate, so you haven't met the technical bar, in my mind
20:40:34 <jbryce> russellb: ++
20:40:49 <ttx> russellb: worse, but not unfixable in the future
20:41:04 <mugsie> dhellmann: they were not "quite small"
20:41:09 <dhellmann> russellb : my position isn't set in stone. this is how I feel today, based on what I've seen
20:41:15 <ttx> i.e. having a separate repo for the Go piece kinda makes sense to me
20:41:16 <mordred> russellb: same with dhellmann
20:41:22 <mordred> I could totally be convinced
20:41:22 <dhellmann> mugsie : ok, my impression was that some were things like moving database queries out of tight loops
20:41:27 <mordred> I just have not yet been convinced
20:41:30 <ttx> i.e. one language per repo
20:41:40 <ttx> that's sane practice anyway
20:41:44 <dhellmann> mugsie : I have not tried to dig into the patches myself, so I may be completely misunderstanding
20:41:51 <notmyname> ttx: shall we drop rst and yaml and bahs from repos that include python?
20:42:00 <mordred> notmyname: no, and you know that's not the case
20:42:00 <mtreinish> ttx: yeah, that would make things much easier to swallow for me too
20:42:15 <mtreinish> I work in some dual language repos, it makes things more difficult
20:42:31 <mugsie> dhellmann: there was never any patches. just numbers, and a direction to "go use caching"
20:42:44 <ttx> notmyname: ask distro packagers (that's where my belief comes from) and they will tell you the same thing
20:42:52 <mugsie> which, for a component that can be global distributed is .... interesting
20:43:07 <devananda> notmyname: that's a strawman. rst and yaml are not service languages, they're documentation and configuration.
20:43:36 <annegent_> russellb jbryce in and out, it's a false dichotomy that I won't buy into. I'm definitely willing to keep discussing and become convinced of a solution.
20:44:25 <dougwig> this entire discussion feels to me like we are letting day-to-day operational concerns define the vision and scope of openstack, which feels entirely backwards to me.  IMO.
20:44:25 <edleafe> annegent_: +1
20:44:25 <JayF> To be clear; an alternative not yet mentioned here would be for swift to voluntarily choose to not be an official openstack project anymore as a whole, correct?
20:44:26 <jbryce> annegent_: you just told them it’s out
20:44:47 <mordred> re: in and out - I don't think this has created a false dichotomy at all. I think that we've said "we want to be able to install openstack via  a combination of pip and distro packaging"
20:45:09 <ttx> So the way forward that the majority recommends for Swift is, if I read right, to land the alternate object server in Go (hummingbird) into a specific repo and make it unofficial for the time being
20:45:15 <mordred> many of our python projects have dependencies that are not written in python - but we consume them from stanard linux distro sources
20:45:32 <mordred> where those components is developed, whether in openstack's repos or elsewhere, is irrelevant
20:45:33 <flaper87> JayF: it wasn't mentioned here but it was mentioned when this discussion started. I'm not advocating for that, though.
20:45:45 <ttx> I have the feeling this is not the last time we discuss this
20:45:50 <flaper87> ttx: ++
20:45:53 <mugsie> dougwig: ++
20:45:56 <flaper87> ttx: but that's good, isn't it ?
20:46:09 <edleafe> Please don't forget the middle ground of gopy - https://github.com/go-python/gopy
20:46:16 * flaper87 has no problems with revisitng this again in the future
20:46:23 <ttx> yes, it's good, just not sure how practical the proposed way forward is for Swift
20:46:35 <jbryce> mordred: i disagree that it’s irrelevant. but we may need to be on a beach to really have this discussion. = )
20:46:52 <flaper87> ttx: It's a start, for sure.
20:46:55 <mordred> jbryce: :)
20:47:07 <ttx> We need to switch topic
20:47:10 <mordred> jbryce: I think what I'm trying to say is that if people are hearing a weird false distinction, then we're communicating something wrong
20:47:19 <mordred> the actual thing is quite clear and distinc to me
20:47:30 <dhellmann> mugsie : you're right, I don't see actual patches in http://lists.openstack.org/pipermail/openstack-dev/2016-May/094568.html
20:47:33 <mordred> jbryce: I'd be more than happy to use you as a sounding board to figure out who we're being unclear though
20:47:43 <tdasilva> I just don't understand how this decision helps with all the arguments being made. In the end, swift will be forced to create another repo, where we you have swift developers in reviewing/writing code in both. It won' t really help with the 'community impact' anyway...
20:48:01 <mugsie> dhellmann: fwiw i asked - I was quite interested in them
20:48:16 <ttx> tdasilva: I think the idea is taht it will prevent contagion and further fragmentation
20:48:25 <tdasilva> will it?
20:48:25 <mordred> tdasilva: we're focused on the total of openstack developers broadly, not the swift developers specifically. yes, this will suck for swift. sometimes things suck for one part of a larger whole
20:48:26 <dhellmann> mugsie : good, and I expect there's a lot more to the story that I haven't heard
20:48:45 <ttx> tdasilva: I'm not convinced, which is why I voted for some sort of compromise
20:49:06 <gordc> is there a requirement that they maintain both the 'unofficial' go version and the 'official' python version?
20:49:17 <flaper87> The compromise I voted for is to start with this and evaluate the growth and impact as it comes
20:49:24 <flaper87> Also, what dhellmann said in the pastebin
20:49:24 <ttx> gordc: no
20:49:25 <tdasilva> mordred: it's not just that it sucks for swift, but we might be forcing other projects to follow the same route.
20:49:43 <ttx> gordc: a lot of things in openstack depend on components written in other languages outside teh official projects
20:50:02 <ttx> nothing says 'everything has to be python'
20:50:06 <mordred> tdasilva: my desire would be that they learn from this experience and don't get themselves into such a rough place
20:50:17 <flaper87> mordred: ++
20:50:23 <ttx> ok, next topic
20:50:25 <notmyname> mordred: nice project you got there. shame if something were to happen to it
20:50:44 <ttx> #topic Adds a docs: URL entry to projects.yaml
20:50:52 <ttx> #link https://review.openstack.org/316396
20:50:55 <annegent_> thanks dhellmann for the patche
20:50:59 <annegent_> patching
20:51:10 <ttx> this one is close but it's a rebase hell so I think we can quickly rebase / review / merge it in-meeting and be done
20:51:19 <mtreinish> I had a question inline, it lgtm though
20:51:20 <annegent_> notmyname threats do not have a place here.
20:51:25 <annegent_> mtreinish ok
20:51:31 <annegent_> mtreinish I can look
20:51:41 <mtreinish> it was just about projects that use developer/ for everything not just contribution docs
20:51:59 * flaper87 not a super fan of the missing `api` items but he's got no strong opinions there
20:52:12 <dhellmann> mtreinish : that's a good point
20:52:30 <annegent_> mtreinish oh right. that's not what we're looking for _quite_ yet, mostly need to get a handle on the sizes.
20:52:43 <mugsie> it is a lot of projects
20:52:49 <notmyname> apologies, my last comment wasn't meant to be a threat at all. it didnt' translate in text
20:53:17 <ttx> notmyname: I read it as joke fwiw
20:53:18 <mugsie> and linking to designate/developer has a lot of completly unreleated docs
20:53:18 <annegent_> such as, Oslo has 28 of the 80 contributor docs links
20:53:35 <mtreinish> annegent_: size as in the number of things that have things up on docs.o.o/developer?
20:53:52 <ttx> annegent_: given how difficult it is to merge things without triggering a merge conflict, I'd rather approve it now if we can
20:54:09 <dhellmann> ttx: ++
20:54:11 <mugsie> should this not link to the actual contributor docs?
20:54:13 <annegent_> mtreinish mugsie yeah, basically a content audit when there's 80 projects, what percentage are developer-centric? Turns out quite a lot on a page basis.
20:54:19 <thingee> ttx: +1
20:54:22 * dims just finished reading the pastebin
20:54:22 <mtreinish> ttx: I was fine with landing it as is, since it helps. I was just worried about the messaging around contributor (or whatever it was)
20:54:24 <annegent_> ttx yay yes
20:54:24 <flaper87> ttx: ++
20:54:28 <mtreinish> but we can fix that in a followup
20:54:34 <ttx> ok, let's merge it now then, please pile on +1s
20:54:36 <annegent_> mtreinish yes, I do want to address that eventually...
20:54:38 <dhellmann> mugsie : with this patch in place, I think annegent_ could ask teams to "fix" their links either in this repo, or by getting publishing working, or both
20:55:04 <annegent_> mugsie also I think it might help us think more about "frameworks" for docs rather than "write the docs"
20:55:14 <mugsie> dhellmann: annegent_ ack
20:55:23 <mugsie> annegent_: you read my mind :)
20:55:33 <annegent_> :) check!
20:56:01 <mtreinish> dhellmann: did you mean to -1 the patch? There wasn't a reason on it
20:56:15 <dhellmann> mtreinish : no, I can't remember how to use gerrit
20:56:19 <annegent_> heh
20:56:44 <mtreinish> dhellmann: heh, that's what I figure it was :)
20:57:03 <dhellmann> mtreinish : thanks for pointing that out :-)
20:57:07 <ttx> ok, merging now
20:57:24 <ttx> hopefully
20:57:43 <ttx> #topic Open discussion
20:57:52 <ttx> I'll miss next week meeting again -- flaper87 still interested in replacing me ?
20:57:52 <annegent_> thanks all, whew!
20:58:05 <flaper87> ttx: yup, I'll be around
20:58:17 <amrith> annegent_ ++
20:58:25 <dims> dhellmann : will you be posting that pastebin somewhere? Mailing list? gerrit comment?
20:58:30 <dhellmann> I would appreciate some more feedback on the "goals" process proposal: https://review.openstack.org/#/c/349068/
20:58:34 <ttx> Anything else, anyone ?
20:58:46 <flaper87> #link https://review.openstack.org/#/c/342069/
20:58:48 <ttx> dhellmann: I was a bit surprised at the initial reaction on it... A lot of people seemed to conflate defining a few release themes into some intolerable intrusion in project design territory
20:58:49 <dhellmann> dims : I hadn't planned to post it anywhere other than these meeting logs
20:58:53 <flaper87> round-table discussions for meetbot
20:58:57 <flaper87> needs some love
20:59:00 * flaper87 will ping infra folks
20:59:02 <flaper87> mordred: https://review.openstack.org/#/c/342069/
20:59:04 <flaper87> :P
20:59:06 <dims> dhellmann : the content may get lost :(
20:59:08 <dhellmann> ttx: I was less surprised by that than the concern about being kicked out immediately
20:59:09 <russellb> flaper87: cool patch :)
20:59:14 <flaper87> russellb: thanks :D
20:59:20 <dhellmann> dims : ok, I'll post it as a comment on your patch
20:59:26 <dims> thanks dhellmann !
20:59:32 * flaper87 will add more to it as soon as the first version lands
21:00:12 <anteaya> thanks ttx
21:00:16 <amrith> dhellmann, yes, surprising reactions.
21:00:34 <ttx> ok, end of meeting, thanks everyone
21:00:37 <russellb> bye, all
21:00:41 <ttx> #endmeeting