20:02:01 <ttx> #startmeeting tc
20:02:01 <dims_> o/
20:02:01 <openstack> Meeting started Tue May 17 20:02:01 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:05 <annegentle> here
20:02:05 <openstack> The meeting name has been set to 'tc'
20:02:08 <dims_> o/
20:02:09 <ttx> Hi everyone...
20:02:12 <ttx> Our agenda for today:
20:02:15 <flaper87> o/
20:02:21 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:21 * rockyg shifts position as foot fell asleep in last meeting
20:02:29 <ttx> A small appetizer first
20:02:36 <annegentle> snacktime!
20:02:38 <thingee> o/
20:02:39 * edleafe lurks innocently
20:02:39 * notmorgan drinks coffee.
20:02:39 <ttx> #topic Add Zanata dev team as extra ATC
20:02:44 <ttx> #link https://review.openstack.org/313934
20:02:48 * notmorgan offers coffee to thingee.
20:03:02 <ttx> I18n PTL proposes to add a few Zanata developers as extra ATCs, to recognize their role in providing and improving the tool that is central to the I18n team work
20:03:15 * thingee has the shakes
20:03:15 <ttx> This already has more than enough votes to pass, so I'll approve this now unless someone objects and wants to discuss it further
20:03:20 <mestery> Seems straightforward to me
20:03:32 <annegentle> yep!
20:03:37 <flaper87> yup
20:03:38 <ttx> ok then, approved
20:03:51 <dims_> yep
20:03:59 <ttx> #topic Add golang as an approved language - technical benefits discussion
20:04:16 <ttx> (timeboxing this one to 40 minutes so we have the time to discuss openstack-salt)
20:04:20 <ttx> #link https://review.openstack.org/312267
20:04:27 <ttx> Last week we (mostly) discussed community costs, with two identified categories
20:04:35 <ttx> - the base cost of community fragmentation every time we add a language
20:04:46 <ttx> - the cost to OpenStack cross-project to support the added language (Infra, Release management, Docs, QA...)
20:04:57 <ttx> On the latter I think most teams have started evaluating the cost to them
20:05:09 <ttx> but it will probably take a few more days before we can collate the results and truly weigh the benefits against the cost
20:05:15 <ttx> So let's discuss benefits
20:05:23 <ttx> The idea here is that Go allows us to overcome performance/IO/concurrency limitations in Python
20:05:35 <ttx> Or, as nicely summarized by ayoung on the thread: "Python for most things. Javascript for web out of necessity. Go for native tuning."
20:05:44 <ttx> And as it goes I think Go is probably the solution for that domain that would generate the less community fragmentation
20:05:51 <ayoung> what did I do now?
20:05:53 <ttx> In the long ML thread(s) I spotted two major objections to that
20:06:00 <dims_> ayoung : all good :)
20:06:02 <ttx> ayoung: you nicely summarized
20:06:07 <mestery> ayoung: I think you brought some good sanity and a nice quote to this discussion around Golang :)
20:06:13 <ttx> (A) is around Python and performance -- suggesting that you can totally write code in "Python" that would perform as well as Go
20:06:17 <mestery> ttx: ++
20:06:25 <russellb> +1 to Go being solution that creates least fragmentation for addressing that problem space in our community
20:06:28 <ttx> (B) is that the main driver for Go seems to come from the need to do smart / data-plane work (in Swift or Designate) while OpenStack is otherwise dumb / control-plane (we integrate external data-plane solutions)
20:06:41 <ttx> My take is that (A) is a bit weak -- I trust the Swift folks to have tried to optimize their Python code and not have jumped on the Go bandwagon lightly
20:06:57 <ttx> (B), though, triggers an essential question for the Technical Committee:
20:07:17 <ttx> Should we add Go to better embrace smart/data-plane projects, or should we spin out smarty/data-plany things as external open source projects and limit OpenStack's mission to integrating them ?
20:07:33 <ttx> I.e. is the need for Go in core OpenStack a clear sign that we are overstepping our mission bounds ?
20:07:37 <sdague> that's an interesting question
20:07:39 <notmorgan> I agree A isn't strong or a reason to block Golang (or any other language)
20:07:40 <mestery> ttx: It's an interesting question
20:07:45 <ttx> (and smart things like hypervisors, databases, message queues, DNS proxies or object stores should be their own external open source projects, coded in whatever language is most appropriate ?)
20:08:03 <dims_> we should not be turning people away!
20:08:17 <ttx> dims_: we can't host all the open source in the world either
20:08:28 <dims_> ttx : not asking for that either
20:08:28 <ttx> but we should definitely try to integrate with most ?
20:08:32 <dhellmann> could the dns proxy designate is building work as an external project? does it talk directly to their database or anything like that?
20:08:39 <mestery> I think we should look at these in a case by case basis
20:08:44 <mugsie> dhellmann: it does talk directly to our db
20:08:48 <johnthetubaguy> right, some folks will thrive better on their own, the tricky bit is choosing who that should be
20:09:00 <mestery> I mean, in the case of swift and designate, if we say no to Golang, we have forced them to use github or some other place to host a piece of their SW
20:09:02 <flaper87> What would having them as external projects mean? Would they be under the openstack org but not part of our governance?
20:09:05 <notmorgan> ttx: so let me be sure i get what you're saying: designate API would still be in scope, the dns proxy would not?
20:09:05 <annegentle> seeing all the difficulty getting common doc toolsets working, I'd like to encourage more onion layers in the ecosystem
20:09:05 <mugsie> it is not so much a proxy as a DNS master that serves to the DNS servers that we integrate with
20:09:15 <flaper87> Would they have to be moved to some other org?
20:09:16 <mugsie> it is kind of core to our control plane
20:09:26 <dhellmann> mugsie : ok, so integration would become a bit more complicated that way unless that thing had an API for talking to it somehow
20:09:31 <mugsie> yeah
20:09:46 <dhellmann> notmorgan : yeah, that's how I understood it
20:09:47 <notmorgan> ttx: similar for object store, the API and similar would all be part of scope, but the actual bits that (for example write to disk) would not?
20:09:47 <annegentle> flaper87 it's more "why the OpenStack org" to me, we have plenty on our plate that we're not delivering on.
20:09:58 <notmorgan> dhellmann: just making sure we have that clearly outlined.
20:10:01 <ttx> It's a larger question obviously, we are back at "what is OpenStack" again
20:10:05 <flaper87> annegentle: that's how I read it too
20:10:06 <mestery> The analogy to Neutron and [OVN, ODL, midonet, etc.] is interesting here. In that case, we do have many external implementations not in openstack itself
20:10:25 <edleafe> annegentle: +1
20:10:28 <dims_> why do we have to equate OpenStack === Python?
20:10:33 * dhellmann wonders if we'll only ever answer "what is openstack?" when we can ask it as "what was openstack?"
20:10:35 <sdague> right, ovn went off to solve the in tree SDN out of tree
20:10:39 <ttx> If it's just about "an integration engine for providing infrastructure-as-a-service" then it shouldn't need much more than Python
20:10:43 <dtroyer> mestery: those all have reasons to exist without OpenStack, the project under consideration arguably does not (the golang portion)
20:10:47 <mestery> sdague: ++
20:10:59 <mugsie> dtroyer: ++
20:11:01 <ttx> the problem is it's also an object store, a queue, a DNS proxy...
20:11:05 <russellb> right, because we felt the ovs community was a good palce to do that (and make it more reusable outside of openstack)
20:11:12 <fungi> fwiw, saying "no" to go wouldn't necessarily mean hosting outside our infrastructure. we just added a c-based project for swift the otehr day (the liberasurecode dependency they've adopted)
20:11:17 <mestery> russellb: Exactly
20:11:19 <dhellmann> dtroyer : which part of what project?
20:11:23 <russellb> i do agree we should encourage more reusability outside of our community where it makes sense
20:11:36 <mestery> russellb: ++
20:11:36 <thingee> dims_: I don't think it's OpenStack === python ... it's us reevaluating our scope as a result of golang being brought up because of the current scope.
20:11:38 <notmorgan> fungi: ++
20:11:42 <dtroyer> dhellmann: the hummingbird branch of swift
20:11:49 <annegentle> I would like to see outroads rather than inroads. And I don't believe it's saying Python is OpenStack.
20:11:51 <mestery> thingee: Well said
20:12:10 <dhellmann> dtroyer : when I looked at that branch today, the readme said the object service was feature complete -- so I think there's a whole rewrite in there
20:12:32 <dtroyer> dhellmann: for one part of the project, not the entire project
20:12:34 <ttx> mestery, dims: they could still be developed on openstack infrastructure
20:12:39 <annegentle> thingee yeah, scope.
20:12:40 <dims_> thingee : designate and swift are just trying to do what they do better for our users
20:12:40 <notmyname> it's not, nor is the current hummingbird branch what we want to bring into master whole-cloth
20:12:48 <dims_> so where is the scope creep?
20:12:52 <notmorgan> notmyname: good to know.
20:12:56 <notmorgan> notmyname: thanks :)
20:13:02 <dhellmann> dtroyer, notmyname: ok, given the list of things that are there, it's not clear what parts are/aren't rewritten
20:13:03 <notmyname> "it's not" == the hummingbird branch is not feature complete, and is not a full rewrite of anything
20:13:04 <thingee> dims_: no arguments there.
20:13:06 <johnthetubaguy> so swift is OpenStack, they feel they need to use Go, that bit doesn't seem like a scope creep at least?
20:13:30 <dims_> johnthetubaguy : they are delivering what they delivered before, but better...
20:13:32 <dhellmann> notmyname : ok, so that readme is just wrong?
20:13:38 <johnthetubaguy> dims_: right
20:13:49 <mestery> I am tending to evaluate 312267 on the basis of "swift and designate want to use Golang", but perhaps the review is wider and we're worried about the net it will cast?
20:13:57 <johnthetubaguy> so a slight tangent... we are not saying its a good idea to have the swift API in Go and python, right?
20:14:08 <dhellmann> mestery : yeah, the most recent comment about starting to rewrite everything bothers me
20:14:16 <annegentle> dims_ To me, the scope creep is the cross project work. For example, choosing to have infra work on this integration rather than say, https on the docs site. Having to document best practices for operators to integrate these projects. Packagers time spent with Go needs instead of IaaS projects.
20:14:16 <notmorgan> mestery: i think the net is wide and i don't want to evaluate this as "project X wants golang"
20:14:17 <mestery> dhellmann: I agree
20:14:18 <thingee> dims_: however, we as a community are effected by these decisions. I think it's healthy for us to talk about current scope.
20:14:36 <dims_> thingee : yep, understoof
20:14:37 <mugsie> dhellmann: yeah, that was definitly not my intention (rewrite everything)
20:14:49 <notmyname> dhellmann: from the community perspective, yes. the branch has been focused on a subset of functionality that is the current feature set for rackspace cloud files. and everyone will agree that there's a huge lack of docs on it right now. that's one of the things we're working on over the next six months
20:14:51 <notmorgan> mestery: it's the wrong approach, because we're not looking at project X. project X just has a case to propose this right now and is justifying the conversation.
20:15:07 <annegentle> mestery I'm not evaluating 312267 for just swift and designate. I can't. We're drowning here.
20:15:07 <dhellmann> mugsie : could you envision the dns server you're working on being a thing outside of openstack that you talk to from designate?
20:15:14 <notmorgan> mestery: the wider reasoning for including golang is the important thing to consider.
20:15:19 <mestery> notmorgan: But if we say no to Golang, will swift and designate just not use it?
20:15:23 <mestery> What happens to them if we say no?
20:15:24 <mugsie> well, it is replacing a currently existing one
20:15:32 <ttx> mestery: there are three potential outcomes to this: yes to golang, no to golang, and spin out some pieces (don't really need to answer that go question after all)
20:15:33 <mestery> Do they move their Golang pieces somewhere else?
20:15:34 <dhellmann> notmyname : ok, thanks for clarifying
20:15:42 <ttx> I don't think the second solution is an option
20:15:48 <mestery> notmyname: What happens if hte TC says no to Golong?
20:15:57 <mestery> Do you just move your swift Golang pieces somewhere else?
20:15:58 <annegentle> mestery they can use it and we won't stop them. They can move it without bringing additional burdens to the middle.
20:16:07 <thingee> ttx: +1
20:16:13 <mugsie> mestery: in our case as a project we probably won't, but I know a certain large cloud provider will keep it
20:16:17 <notmyname> mestery: I have no idea. I haven't wanted to consider that. I don't think there are good options for anyone at that point
20:16:23 <mestery> notmyname: right
20:16:26 <ttx> mestery: I think that's sidestepping the question. I don't see why we'd say no to golang and still say that smart/data-plane projects are ok
20:16:38 <greghaynes> Have we actually established that there is a need for designate to rewrite in go? I still havent seen anything to that effect, or are we just saying we don't mind despite not showing that?
20:16:39 <notmorgan> ttx: exactly.
20:16:40 <ttx> so "no to golang" is not really an option I think.
20:16:47 <mestery> ttx: OK, so then I am not sure why we'd say no to Golang here
20:16:49 <mestery> ttx: Right
20:16:49 <mestery> :)
20:16:53 <mestery> ttx: We're on the same page!
20:16:54 <russellb> i tend to think +1 to golang, assume people don't rewrite stuff lightly, and address real problems if/when they arise
20:16:55 <ttx> but "we should only do dumb things" is one option
20:17:05 <ttx> So to summarize...
20:17:10 <notmorgan> greghaynes: as much as i want to talk about that, i'd like to table that to the side for purposes here.
20:17:25 <ttx> If we say smart/dataplany things are in scope of openstack, I think we need to approve golang as a nice omplement tool
20:17:29 <ttx> +c
20:17:36 <russellb> it already is in a number of places
20:17:38 <dims_> ttx +1
20:17:39 <mestery> Yeah
20:17:41 <russellb> i don't see how we can change that
20:17:41 <mestery> ttx: +1
20:17:46 <notmorgan> ttx: ++
20:17:54 <annegentle> ttx does that approval then imply approval for all the cross-project work to be "blessed?"
20:17:58 <ttx> If we say openstack should only be dumb / controlplany stuff, then I think Python is plenty enough
20:17:58 <dhellmann> russellb : why can't we change that?
20:18:07 <russellb> dhellmann: not easily, at least
20:18:11 <dougwig> greghaynes: the "but python could do that" arguments are reminiscient of early debates between perl and python and C. technically, C could do everything python does, too. that's not always the end of the question.
20:18:11 <annegentle> ttx or take priority even?
20:18:15 <dhellmann> russellb : this is openstack, nothing is easy
20:18:18 <russellb> :)
20:18:27 <ttx> russellb: it's easy to enter the tent, it's easy to exit it
20:18:32 <dtroyer> annegentle: I think that means those who what officiality are on the hook to provide support for the requirements that follow
20:18:49 <thingee> big tent is not hotel california.
20:18:52 * flaper87 lost connection for a bit so no idea what's easy/hard to do
20:18:53 <flaper87> thingee: lol
20:18:56 <notmorgan> ttx: so i want to quote a comment on the golang thread.
20:19:00 <russellb> i don't know that it's easy to remove neutron, for example
20:19:02 <mestery> thingee: That's a twitter quote right there :)
20:19:03 <notmorgan> ttx: that worries me. it's related to all this.
20:19:16 <bswartz> I'm curious to know what the proposed performance improvement is with golang vs python. I saw a document that showed something like a 60% speedup -- but that seemed rather pathetic to me. Normally people don't consider major architectural changes for anything less than an order of magnitude improvement. There's a reason we don't have 1.6 gigabit ethernet.
20:19:17 <notmorgan> ttx: "If Go was accepted as an officially supported language in the OpenStack community, I'd be the first to start to rewrite as much code as possible in Go."
20:19:19 <notmorgan> ttx: ^ That worries me.
20:19:30 <greghaynes> I dont mean to debate the specifics of designate, I am mostly trying to figure out if this is making a general rule for a single specific case...
20:19:39 <ttx> notmorgan: yeah, I can see that. People using the shiny thing just because it's in the toolbelt
20:19:41 <annegentle> dtroyer but they seem to get official approval with this patch, without having to prove that they'll provide resources.
20:19:42 <flaper87> notmorgan: exactly my point
20:20:00 <ttx> notmorgan: I think that's part of the community cost
20:20:18 <notmorgan> ttx: yep.
20:20:20 <flaper87> I think the technical motivations behind Golang are fine but the community aspect of this change keeps worrying me.
20:20:24 <ttx> but if we want to enable dataplany things, I think that a cost we need to accept to pay
20:20:28 <thingee> bswartz: from notmyname's messages to the ML, while it's not impossible to achieve the same without enough time investment, it's picking the right tool to start,
20:20:32 <dtroyer> annegentle: I never saw approval as a commitment of existing resources to carry the load, and I don't think it should be
20:20:33 <timsim> greghaynes: The single case being swift? or Designate?
20:20:38 <greghaynes> timsim: swift
20:20:58 <thingee> /without/with/
20:21:02 <annegentle> ttx I still sense the community cost is too high.
20:21:27 <ttx> annegentle: explain ?
20:21:29 <annegentle> dtroyer hence my concern as someone who needs more community resources.
20:21:31 <dims_> annegentle : what would reduce community cost?
20:21:52 <ttx> annegentle: in a specific team cost, or just general community desintegration ?
20:22:06 <notmyname> bswartz: there more (and "realer") data in a talk from the tokyo summit https://www.openstack.org/summit/tokyo-2015/videos/presentation/omg-objects-the-unscaly-underbelly-of-openstack-swift
20:22:08 <annegentle> ttx team costs. spreading out the burden for tooling
20:22:17 <flaper87> ttx: I believe it'd affect both, tbh. There's a single project impact and a broader impact
20:22:18 <dims_> annegentle : fair point
20:22:22 <mugsie> annegentle: what tooling are you thinking of?
20:22:23 <johnthetubaguy> so there is totally a need for resources for to maintain the go related infrastructure, thats not small
20:22:36 <ttx> annegentle: for release management the costs are minor. Infra seems to be on top of what would be required... any other team with concerns ?
20:22:37 <johnthetubaguy> infra stuff, docs stuff, etc
20:22:40 <annegentle> mugsie infra, docs, test, packaging, operating
20:22:49 <mugsie> docs should not be affected for exam ple
20:23:03 <dhellmann> mugsie : every cross project team has tools that work with projects in one way or another
20:23:03 <flaper87> ttx: annegentle I'd add oslo in there too
20:23:05 <annegentle> mugsie my understanding is a desire to support golang docs
20:23:15 <ttx> hmm
20:23:25 <mugsie> for internal docs, but shpinx for "naritive" docs
20:23:30 <johnthetubaguy> (adds translation to the above list)
20:23:32 <fungi> my biggest concern for a "community cost" is finding a good answer as to how to get ahead of the inevitable "us vs. them" split that will ensue if we have some people working only on python and some working only on go
20:23:42 <mugsie> at least that was the plan that last I heard
20:23:44 <annegentle> mugsie also while infra stands up go infrastructure, we don't get them to work on a spec that has been written twice in the last two years. http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html
20:24:00 <notmyname> fungi: any different than people working on neutron vs people working on horizon?
20:24:05 <clarkb> fungi: there is also a third party with high overhead. The people that necessarily work in both worlds to fight off the wolves acusing them of breaking things constantly
20:24:10 <ttx> Frankly, I don't think we can support smart/dataplany things without adding a language that several projects have found useful to deliver such things. I'm not convinced we should be in the business of doing domain-specific smart things though
20:24:23 <notmyname> fungi: there isn't a "vs". we all make openstack.
20:24:23 <fungi> notmyname: true. we're definitely trying to break down silos already and get everyone to work on everything
20:24:33 <fungi> that's teh point of the project-teams gathering
20:24:35 <sdague> ttx: so that feels like a different resolution you want to propose
20:24:37 <russellb> ttx: agree that ideally we should not
20:24:47 <mestery> sdague: ++
20:24:48 <russellb> no more than necessary / last resort
20:24:53 <russellb> or pre-existing ..
20:24:54 <notmorgan> ttx: 100% agreeed we must have a language to deliver these things if we support that
20:25:01 <sdague> which we'd kind of want to resolve before we ask the specific go question, right?
20:25:02 <annegentle> I don't think it's about a split or schism. It's about "what do I work on to make OpenStack better?"
20:25:13 <ttx> sdague: one that would make this one irrelevant, but yes. This resolution basically unearthed a real question that has been there below the surface forever
20:25:14 <dims_> annegentle : ++
20:25:22 <fungi> so i'm less concerned if we significantly increase the costs of participating for people who only want to focus on "part of openstack"
20:25:22 <thingee> sdague: yes
20:25:39 <annegentle> fungi ah, interesting.
20:25:47 <amrith> fungi, that's an interesting view.
20:25:54 <fungi> means it's time for me to bone up on go programming
20:25:56 <amrith> I think most people participate only on a 'part of openstack'
20:25:58 <dtroyer> fungi: ++
20:26:02 <sdague> right, I guess you could see the early rumblings of it in the zaqar vote
20:26:10 <ttx> If we want to be all thongs to all people, we'll need more languages
20:26:16 <notmyname> fungi: you and me both ;-)
20:26:16 <ttx> things*
20:26:28 <dims_> :)
20:26:48 * amrith looks around and sees that edleafe isn't nearby so says C# .NET and runs away
20:26:49 <annegentle> amrith true and it makes us as a whole look like we're slow, say, trying to get API reference standards for example
20:26:49 <dtroyer> ttx: I don't think we should beall things to all people, but I also don't think that's the counter here
20:27:01 <ttx> I'm just not convinced we should be in the business of writing a database or an hypervisor or a message queue. I think we are in the business of integrating those things
20:27:09 * edleafe laughs at amrith
20:27:22 <russellb> ttx: agreed with that.
20:27:24 <thingee> ttx: +1
20:27:26 <amrith> :{
20:27:26 <mestery> ttx: +1
20:27:29 <notmorgan> so, i am inclined to agree, i will be against writing a database (in openstack) or a hypervisor.
20:27:39 <amrith> annegentle, I see what you mean (and I agree with you).
20:27:44 <dougwig> if i did write a database, it wouldn't be in python.
20:27:47 <notmorgan> not to say they couldn't be part of the larger ecosystem.
20:27:55 <amrith> I'm curious though about fungi's comment. something to think about there.
20:27:56 <johnthetubaguy> ttx: that feels correct
20:27:59 <notmorgan> dougwig: regardless of the underlying language
20:28:12 <ttx> object storage now... is in the grey area. But still sufficiently in the white zone so that it kinda need another language to do things well
20:28:13 <annegentle> As I look at all the REST APIs that need docs, it's possible there are 30 of them. 10 have docs. That has nothing to do with "do we add golang?" and that's my concern for OpenStack as a whole. Distraction by governance.
20:28:24 <flaper87> ttx: why is it in the grey area?
20:28:30 <notmyname> ttx: and I'd phrase that as "swift integrates different persistent storage technologies today". but yes, it has a data plane API instead of provisioning object storage systems
20:28:32 <dhellmann> ttx: why is object storage special?
20:28:35 <mugsie> annegentle: 10 have docs on the api-site
20:28:38 <edleafe> There's a huge difference between only working on part of OpenStack and only caring about part of OpenStack
20:28:42 <notmorgan> flaper87: it's where the split between api and data plane ends up in object store
20:28:44 <annegentle> mugsie 30 exist in projects.yaml
20:28:50 <greghaynes> that is what is going on with swift though, and thats why they need a new language at the end of the day - they are basically a database
20:28:58 <mugsie> yeah,  but other projects are doc'd else where
20:29:03 <annegentle> mugsie and all are moving off api-site.
20:29:04 <ttx> dhellmann: it's arguably more high-level than a database or a hypervisor ?
20:29:06 <flaper87> notmorgan: well, it feels data to me
20:29:10 <notmorgan> flaper87: it's a different place than most openstack-projects.
20:29:20 <annegentle> mugsie in their repos with no collective website for end-users to use
20:29:28 <notmorgan> flaper87: think of it more like "API" users interact with and "bits that put things on disk"
20:29:39 <annegentle> mugsie we can talk more about it after the golang discussion if you're curious
20:29:40 * amrith agrees with greghaynes; i know of zero high performance databases written in Python.
20:29:41 <dhellmann> ttx: gnocchi is a database built on top of an object storage
20:29:42 <bswartz> dhellmann: swift is special because the API and the implementation of the API are not separate things
20:29:49 <flaper87> notmorgan: glance ? :P
20:29:51 <notmorgan> flaper87: the API has to be some-what dataplane-y to succeed. you don't make swift api to interact with.
20:29:51 <mugsie> annegentle: I would argue that was around tooling / timing. as soon as the os-api-ref was done, we started moving
20:29:53 * flaper87 ducks
20:30:08 <dhellmann> bswartz : that's an implementation detail of swift, though, isn't it?
20:30:18 <ttx> greghaynes: yeah, we want go because we are writing a sort of database. It feels like we should ask ourselves the question of whether that's what we should be doing... before we add the language
20:30:34 <notmyname> dhellmann: no. that's a fundamental part of object storage
20:30:44 <notmorgan> flaper87: anyway you get it. object store is slightly different but it still is close enough to non-dataplane to not really raise flags.
20:30:51 <ttx> dhellmann: we shoudl not be in the business of writing a time-series database either
20:30:53 <bswartz> dhellmann: if we follow the model of cinder or manila, there would be a swift API the plugable implementations -- and some or most of those implementation would live outside the tent
20:30:58 <johnthetubaguy> dhellmann: so swift doesn't have a plugin for ceph right?
20:31:02 <notmorgan> flaper87: frm wher ethe split actually is.
20:31:05 <greghaynes> ttx: agreed
20:31:06 <notmyname> johnthetubaguy: that exists in the ecosystem
20:31:12 <bswartz> and* plugable implementations
20:31:16 <dhellmann> ttx: ok. my point was just that "level" is relative
20:31:19 <notmorgan> johnthetubaguy: my understanding is it easily could or be part of the ecosystem al.. what notmyname said
20:31:33 <dhellmann> johnthetubaguy : not that I'm aware of
20:31:35 <dhellmann> bswartz : I agree
20:31:36 <dougwig> so if an open-source implementation doesn't exist for some new service, you have to go elsewhere to build it? if the poppy folks had decided to write their own CDN stuff to include, we'd ask them to go elsewhere? how is that community building?  is the big tent really just streamlined incubation for REST wrappers?
20:31:39 <johnthetubaguy> notmyname: well its a swift API implementation, not a plugin to swift though?
20:31:40 <annegentle> notmyname so why not have hummingbird in the ecosystem? I may have missed the reason spelled out in the thread.
20:31:46 <mugsie> dougwig: ++
20:31:48 <johnthetubaguy> its not like abstracting the two systems to a common API
20:32:01 <notmyname> johnthetubaguy: https://github.com/openstack/swift-ceph-backend
20:32:09 <notmorgan> johnthetubaguy: you can layer under the swift python api connection to librados. this isn't radosgw.
20:32:13 <hogepodge> Swift not being pluggable is one of the biggest complaints I have on defcore enforcement
20:32:16 <johnthetubaguy> notmyname: I stand corrected
20:32:16 <notmyname> johnthetubaguy: also https://github.com/openstack/swiftonfile
20:32:34 <dhellmann> let's not get side-tracked talking about pluggability
20:32:34 <notmyname> and other proprietary stuff that NetApp, EMC, and others have built
20:32:52 <notmorgan> hogepodge: ^ i think that is really a misrepresentation as i've bene looking at this for a bit recently, actually wanted to ping you on that later today re: this (post meeting)
20:32:52 <notmyname> hogepodge: but it is. just not where you want it to be pluggable
20:32:57 <mugsie> should we drop octavia then, if we are not doing dataplane services. or is it OK if we have a data plane esq thing, that is plugable?
20:32:59 <johnthetubaguy> so it seems odd to kick half of swift out of the big tent.. but is that what we are suggesting here?
20:33:11 <ttx> annegentle: to come back to your objection ('cost is too high even if we agree we want dataplany things in') -- that means "no to golang" would have to be an option. I just don't know what the world would look like if we chose that option
20:33:16 <hogepodge> dhellmann language woukdnt be an issue if it were pluggable, but I'll step back
20:33:25 <bswartz> johnthetubaguy: I would suggest kicking the go parts out and keeping the python parts in
20:33:37 <dhellmann> hogepodge : I think I see where you're going, yeah
20:33:47 <johnthetubaguy> but then we are streaming data in python, into go, which sounds... odd
20:33:59 <mestery> So are we fundamentally coming back to ttx's question about openstack being wrappers for existing dataplane things? Feels like we are.
20:34:07 <notmorgan> mestery: we are
20:34:17 <johnthetubaguy> yeah, I am really thinking, so what does this mean for swift
20:34:26 <dtroyer> mestery: and that feels like it is dangerously close to the "are we implementations or API specs"
20:34:27 <thingee> I don
20:34:29 <dougwig> doesn't that also boil down to, "if you want to innovate, go elsewhere" ?
20:34:30 <amrith> well mestery are we saying wrappers or specifically 'python wrappers'?
20:34:32 <mestery> dtroyer: Right
20:34:40 <mestery> dougwig: That's what I'm trying to get at
20:34:44 <dhellmann> mugsie : maybe if octavia is a load balancer vs. configuring a load balancer
20:34:52 <mestery> I mean, if we're saying that, where does that leave things like swift, octavia, etc.?
20:34:57 <johnthetubaguy> well, we are saying we are API implementations, which is a slightly odd place I guess
20:35:11 <sdague> johnthetubaguy: it's API plus glue
20:35:12 <mestery> This seems to me to be a fundamental thing we're discussing now, with much greater impact than adding Golang
20:35:14 <edleafe> dougwig: "innovate" doesn't mean "do it differently"
20:35:16 <dims_> our strength as a community is because of inclusiveness and choice...
20:35:17 <mestery> johnthetubaguy: Exactly
20:35:19 <dhellmann> dtroyer : we are the implementation of the abstraction layer
20:35:21 <johnthetubaguy> sdague: true, I meant + glue
20:35:25 <sdague> because a lot of things need a lot of glue to hold together
20:35:32 <dougwig> edleafe: innovate also doesn't mean "always do it the same".
20:35:45 <ttx> OK, so we have two potential outcomes: yes to go and dataplany things, no to dataplany things (and no need for go). Does anyone think "no to go but yes to dataplany things" is an option ?
20:35:49 <thingee> FWIW I don't think the streamlined stuff makes sense. I think people should just be using native apis of object stores. Projects like cinder that use swift and ceph today will back up can continue to provide an interface to those with some feature.
20:35:54 <notmorgan> sdague: ++, but i use gaffer tape these days.
20:36:04 <mugsie> ttx: depends on the "dataplany things definition"
20:36:06 <johnthetubaguy> dims_: its also a big weakness, but thats a different discussion
20:36:08 <dtroyer> dhellmann: so independant of language, should the two projects being discussed be pushed away anyway?
20:36:32 <amrith> ttx that is a hard quesiton. 'yes or no to go' is very specific but 'dataplany things' is many things to many people.
20:36:40 <dims_> dtroyer : i hope sincerely we don't do that
20:36:45 <notmorgan> ttx: "no to go and yes to dataplane-y things" is not something i'd support
20:36:45 <ttx> mugsie: I guess the question is.. can we really be in the business of smart things without a language for native optimized pieces
20:36:49 <flaper87> amrith: ++
20:36:56 <mestery> ttx: I don't think "no to go and yes to dataplane things" makes sense.
20:37:04 <edleafe> dougwig: the point is that the language chosen doesn't make it more or less innovative
20:37:06 <mugsie> ttx: ah. so a different question to "dataplaney things"
20:37:07 <russellb> mestery: that's status quo right?
20:37:11 <dhellmann> dtroyer : that's the question. I don't want to offer a knee-jerk answer, but "if one of these things is not like the others..."
20:37:20 <mestery> russellb: It appears to be yes
20:37:21 <bswartz> dougwig: "if you want to innovate it a language other than python, go elsewhere" -- openstack can't and shouldn't do literally everything
20:37:22 <notmorgan> russellb: pretty much.
20:37:23 <thingee> ttx: notmyname has said in the ML it can still be done, it's just about having the best tool to avoid investing so much time.
20:37:33 <dtroyer> dhellmann: we have a lot of housecleaning to do if that is the case
20:37:38 <ttx> thingee: what can be done ?
20:37:39 <dhellmann> dtroyer : indeed
20:37:44 <dims_> we are not even investing enough in moving to py34/pypy either...
20:37:47 * thingee looks to notmyname
20:37:49 <dougwig> edleafe, bswartz: there's not much innovation in rest wrappers, and that's all we'd be left with.
20:38:16 <dhellmann> dougwig : is nova a "rest wrapper"?
20:38:26 <mestery> So, again: If we decline to accept Go waht does that mean for Swift and Designate here?
20:38:28 <notmyname> thingee: don't get me wrong. I think it's a bad idea for the swift community to try to reinvent the golang runtime in python. is it possible? probably would be to some extent (hey, python is turing complete). but it wouldn't help any end user
20:38:29 <dougwig> around libvirt, absolutely.
20:38:40 <mestery> I understand the precedent it sets, but I guess we're telling them to move their Golang stuff somewhere else
20:38:46 <sdague> dougwig: you are right, there is definitely no inovation in that million lines of code :)
20:38:49 <russellb> certainly not that simple ... nova doesn't implement a hypervisor, but ti implements a significant control plane for many hypervisors
20:38:52 <dhellmann> dougwig : I see some useful innovation there
20:38:54 <greghaynes> Just to be clear - not accepting go as a generally OK solution does not imply not accepting the swift hummingbird code
20:38:55 <mestery> Sorry, not accept Golang
20:39:02 <mestery> *sigh*, mind slower than fingers
20:39:06 <dougwig> sdague, dhellmann: don't rain on my hyperbolic parade.
20:39:07 <russellb> similar to neutron not implementing a virtual switch, but it implements an extensive control plane implementation to orchestrate many virtual switches
20:39:15 <ttx> greghaynes: how ?
20:39:16 <russellb> "dataplany things" isn't easy to define
20:39:22 <mestery> russellb: Agreed
20:39:31 <ttx> russellb: especially if you say smart/dataplaney
20:39:39 <greghaynes> that was a lot of false negatives, but we can still say that hummingbird is a special case and we can consider other special cases as they arise
20:39:42 <flaper87> russellb: one could even consider glance a dataplane thing, tbh
20:39:46 <amrith> this conversation reminds me of long discussions I've seen when people first started using NoSQL databases. It was always 'one-size-fits-all' RDBMS (from one vendor) till someone brought up NoSQL. There was all of these same kinds of objections but today we are much better off in the world with the 'best database for the job'. I realize that there is a cost involved in accepting a new language but maybe we should
20:39:47 <amrith> seriously consider whether this is an issue of being the right tool for the job, or just another tool for the job.
20:39:50 <ttx> Although "anything that would require go" is I think a good starting point
20:39:53 <dtroyer> flaper87: it is
20:39:57 <dhellmann> russellb : if the purpose is to move data, and not to tell other services how to move data?
20:40:04 <notmyname> if the TC says "no" to golang or says swift can't land golang code, then that will lead to the situation of "here's the openstack code, but don't run it, use that other one over there instead"
20:40:14 <ttx> notmyname: yeah, that would be silly
20:40:28 <hogepodge> Like ceph
20:40:28 <mestery> ttx notmyname: Yes, that would be silly
20:40:28 <edleafe> amrith: agreed on the DB argument, but we don't have to test/maintain those projects
20:40:29 <notmyname> ttx: that assumes you're not kicking swift out of openstack ;-)
20:40:34 <ttx> which is why I don't think that's an option
20:40:50 <notmorgan> notmyname: not going to happen if i can have any say at all.
20:41:00 <dtroyer> ttx: so what options are left then?  (remind us)
20:41:08 <notmorgan> notmyname: sorry to clarify, no kicking swift out is not a good/correct option
20:41:18 <notmorgan> notmyname: s/no//
20:41:19 <sdague> ok, so this sounds like there is a set of people that would like to open this other issue around data plane services being part of OpenStack scope
20:41:20 <johnthetubaguy> so I think we should talk about the API a second here, is that re-written in Go, for the swift thingy?
20:41:31 <ttx> dtroyer: option 1: accept go, consider smart/dataplany things are totally fine as openstack projects
20:41:34 <sdague> which needs to be resolved prior to the go resolution
20:41:39 <notmyname> also, I'd like to be clear that the swift community (and myself personally) is not looking for a special dispensation for swift to do something. that's why we've been going through this: so that as a community we can find the right path forward
20:41:52 <russellb> notmyname: ++
20:41:53 <amrith> edleafe, fair point. but the incremental effort was there (it was different). it was really the shift from 'this tool' to 'the right tool'.
20:41:57 <notmorgan> notmyname: i personally appreciate it  a lot
20:42:02 <dims_> notmyname : thanks for saying that
20:42:03 <dhellmann> johnthetubaguy : not yet, aiui, but we do already have folks talking about rewriting other parts of other services in go, just because they could
20:42:03 <ttx> option 2: consider OpenSTack is just an integration engine, spin out the smart/dataplaney components as external projects, integrate them in openstack projects
20:42:11 <flaper87> ttx: are you planning to write a resolution for the dataplane issue?
20:42:25 <ttx> I'm not even sure that's a good idea
20:42:28 <flaper87> ok
20:42:28 <mestery> heh
20:42:29 <dtroyer> sdague: are the two options ttx just listed what you are referring to?
20:42:32 <johnthetubaguy> dhellmann: its just if we say openstack is the API implementation, then that makes things trickier
20:42:36 <ttx> I think that's a discussion we NEED to have
20:42:37 <annegentle> help me understand why golang isn't pluggable into these projects? If the underlying implementation doesn't affect the user view API, is the concern leaky abstraction? Or contributor concerns?
20:42:46 <ttx> because continue to hide it below the carpet won't do us any good
20:42:55 <sdague> annegentle: because the python version is going to rot
20:42:56 <flaper87> ttx: I guess a topic for next week.
20:43:10 <ttx> It's probably a topic for the next cycle
20:43:17 <ttx> It's a hard question
20:43:20 <notmyname> johnthetubaguy: FWIW, the end-user-facing parts of swift are not currently being considered to be rewritten in golang. there's way too much ecosystem plugins that we can't support apart from python (hello wsgi middleware)
20:43:26 <notmorgan> unfortunately, we need to address it sooner rather than later.
20:43:28 <dhellmann> johnthetubaguy : I think in this scenario, zarqar might be "dataplaney" but cue wouldn't be
20:43:29 <edleafe> ttx: it's more than one question
20:43:42 <dims_> we just ran out of time.. ttx (43 mins)
20:43:42 <flaper87> ttx: if it's for next cycle, how are we going to answer the go/no-go question?
20:43:49 <annegentle> sdague ok
20:43:51 <ttx> MagnetoDB would be dataplany and Trove not
20:44:05 <flaper87> Zaqar and Glance are dataplane services, fwiw
20:44:06 <johnthetubaguy> notmyname: OK, thanks, thats a good data point (and makes sense)
20:44:11 <ttx> yes, we need to move on
20:44:16 <annegentle> notmyname super helpful, yes
20:44:19 <flaper87> So, we need to define very well what we mena
20:44:21 <sdague> flaper87: glance is only about 1/2 dataplane, given how most people configure it
20:44:22 <flaper87> mena, even
20:44:33 <annegentle> flaper87 heh
20:44:33 * mestery hands flaper87 coffee
20:44:33 <amrith> flaper87, not sure about glance but you know glance better than I do.
20:44:38 <notmyname> sdague: as we do golang implementation, I'm not wanting to have both python and golang stuff long-term that do the same thing in swift. one implementation, one codebase
20:44:43 <johnthetubaguy> sdague: +1 its tricker with glance
20:44:51 <flaper87> mestery: <3
20:44:54 <sdague> notmyname: right, and I 100% agree with that approach
20:44:55 <ttx> I would like to check again if anyone thinks saying "no to Golang but we want smart/dataplany things in OpenStack" makes any sense. So far haven't seen anyone considering that would be a sane outcome
20:44:57 <notmorgan> so i think this comes down to even more defined: Golang is "OK" but should only be used in the dataplane?
20:45:11 <johnthetubaguy> notmyname: sdague: +1
20:45:13 <sdague> dueling backends when the team only is focused on one isn't a good situation for anyone
20:45:13 <notmorgan> s/think this/is this?
20:45:19 <dhellmann> ttx: no, that doesn't make a lot of sense
20:45:21 <ttx> notmorgan: that would be an interesting way of phrasing "yes to golang"
20:45:26 <flaper87> amrith: sdague I'd honestly classify it as dataplane but it also depends on the backend. The API is certainly a data API. *shrugs*
20:45:34 * flaper87 stfu and lets ttx switch topics
20:45:39 <notmorgan> ttx: i think that makes me feel a lot better about this and resolves my internal conflicts
20:45:43 <ttx> notmorgan: but I doubt we'll be able to police the use of golang once it's approved
20:45:54 <notmorgan> ttx: guidelines are just that
20:45:54 <amrith> flaper87 ++
20:45:59 <dims_> ttx : don't know if we have to end up vetting every use of golang in projects..
20:46:10 <dims_> right
20:46:13 <ttx> ok, we need to move on -- I'll probably follow up with a thread (or someone else will)
20:46:19 <johnthetubaguy> flaper87: I was thinking about ceph users, and folks where you upload/dowload straight to/from swift, etc
20:46:20 <notmorgan> ttx: best effort, but recommendation is this and we can mandate a couple things to help push towards that.
20:46:30 <johnthetubaguy> flaper87: but basically agreeing with both of you
20:46:48 <dims_> notmorgan ++
20:46:50 <ttx> I'll also summarize that "no to golang but yes we still very much want smart/dataplany things in openstack" is actually not a very viable option
20:46:51 <notmorgan> ttx: in short, i am for golang and officially recommending it is only used in dataplanes - and adding the "dataplane is ok"
20:46:58 <dims_> ttx agree
20:47:03 <flaper87> johnthetubaguy: prolly "dataplane" is not the right way to describe these set of services
20:47:08 <dims_> notmorgan : +1
20:47:11 <edleafe> flaper87: +1
20:47:12 <ttx> I think that simplifies the whole cost/benefit discussion
20:47:45 <ttx> we need Go if we want to keep all projects we have today in openstack, as much as we needed JS if we wane
20:47:46 <notmorgan> it strikes as much balance as we can, while remaining inclusive
20:47:52 <ttx> wanted Horizon in*
20:47:56 <notmorgan> it doesn't mean we have to include every dataplane
20:47:57 <thingee> ttx: move on :)
20:48:01 <ttx> ok ok
20:48:04 <dims_> haha
20:48:05 <ttx> #topic Add new project openstack-salt
20:48:06 <johnthetubaguy> flaper87: ack
20:48:10 <ttx> #link https://review.openstack.org/314531
20:48:20 <ttx> That is another downstream packaging/deployment team, like the Ansible, Puppet, Chef ones...
20:48:32 <ttx> I feel like those were successful in having people collaborate on the same set of recipes/formulas rather than dozens of forks of varying quality
20:48:36 <flaper87> this topic feels like a breeze after the golang topic
20:48:42 <ttx> So it feels like we should have one team for Salt as well
20:48:58 <ttx> flaper87: we can't just have easy questions, sometimes the hard questions hit
20:49:07 <dims_> looks like 8 +1 Rollcall-Vote already :)
20:49:19 <dhellmann> I'm a little disappointed in the choice of release model here, but welcome the team anyway
20:49:37 * thingee was waiting for dhellmann to sign off on that
20:49:43 <anteaya> this is the second round of salt repos
20:49:43 <mtreinish> dhellmann: well, that can change at any point
20:49:44 <ttx> The team pushing that is the tcpcloud guys, who did the fun IoT demo at the summit
20:49:47 <notmorgan> i am ok with including salt, but i would much rather them be trailing
20:49:47 <dims_> dhellmann : we embrace them and then change their mind :)
20:49:51 <anteaya> the first set got put in the attic
20:49:52 <notmorgan> instead of "independant"
20:49:58 <dhellmann> mtreinish : no, it can only change prior to the first milestone of a cycle
20:50:03 <notmorgan> but i can't force a release model on people.
20:50:07 <ttx> notmorgan, dhellmann: they could evolve over time
20:50:15 <notmorgan> ttx: i would hope they do.
20:50:22 <dhellmann> yeah, they can change it next cycle if they end up not liking the outcome this time
20:50:33 <thingee> mtreinish: yeah they have until R-18
20:50:37 <dhellmann> it's definitely not a blocker, I just wanted to make sure they were clear about the implications
20:50:38 <ttx> you still have a couple of weeks to convince them to change it before n1
20:50:43 <johnthetubaguy> yeah, I hope the move to trailing too, but yeah, it should be their choice
20:50:48 <dims_> dhellmann : agree
20:50:51 <ttx> we could have that discussion again with them
20:51:33 <dhellmann> if you like. I've explained it, they've signed off. I'm ok with leaving it for this cycle. I just wanted to state it for the record, lest they come back surprised at the end when we don't say the salt formulas are "part of newton"
20:51:48 <fungi> yeah, i'm curious what becomes of the old stackforge/nova-salt-formula et al
20:51:54 <sdague> dhellmann: ++
20:51:59 <fungi> we still have them all in git, only retired
20:52:08 <johnthetubaguy> do they have a "single" version of salt that supports many versions of openstack, it wasn't clear if thats why they wanted independent?
20:52:21 <johnthetubaguy> anyways, I should go ask them really
20:52:42 <fungi> not a fan of slash-and-burn adding new repos to replace old repos rather than reactivating and continuing them
20:53:25 <ttx> fungi: is that something that could be fixed ? Or did they recreate new repos already ?
20:53:37 <anteaya> fungi: agreed
20:53:42 <fungi> they already have new repos, looks like
20:53:50 <anteaya> which was my argument when I first found out new repos had been created
20:53:56 <fungi> water under teh bridge now, but not a precedent i like to set
20:54:02 <dhellmann> johnthetubaguy : that was my impression
20:54:08 <ttx> ok, no more objections ?
20:54:29 <fungi> their new replacement repos are, e.g., openstack/salt-formula-nova
20:54:55 <notmorgan> no objections as long as they understand that what independant really means.
20:55:05 <ttx> we'll make sure of that.
20:55:10 <ttx> ok, approving
20:55:17 <dhellmann> notmorgan: all will be made clear in time
20:55:27 <ttx> #topic Open discussion
20:55:33 <ttx> Anything else, anyone ?
20:55:47 <dhellmann> where are people planning to stay in ann arbor?
20:55:56 <annegentle> downtown dhellmann for me
20:56:13 <annegentle> dhellmann can't recall the name of the hotel but it was the only one in the corp. system I could get :)
20:56:13 <russellb> i booked the courtyard in ann arbor
20:56:18 <ttx> dhellmann: downtown... Might try one of those B&B that gothicmindfood suggested
20:56:21 <mestery> I was thinking the Sheraton
20:56:22 * flaper87 takes note as he hasn't booked anything yet
20:56:32 <notmorgan> ttx: trust gothicmindfood's suggestions for sure.
20:56:34 <dhellmann> mestery : I'm in the sheraton
20:56:35 <russellb> mestery: mine is next door to the sheraton
20:56:46 <dims_> is having a tag named "co-installable" useful information? (projects that have been tested together... list of projects subject to requirements process)
20:56:47 <mestery> dhellmann russellb: Ack :)
20:56:55 <johnthetubaguy> I was going to ask about the OSIC bug bash/smash event thing
20:56:59 <mtreinish> dims_: I like that idea
20:57:10 * gothicmindfood recommends things downtown ann-arbory
20:57:10 <johnthetubaguy> OSIC is thinking of doing another one, as wondering about the best date
20:57:19 <johnthetubaguy> I am promised an ML thread about it
20:57:21 <dims_> mtreinish : ok i'll ping you later when i have some initial draft
20:57:27 <dhellmann> johnthetubaguy : earlier in the cycle, and not on a milestone date
20:57:32 <dhellmann> or week even
20:57:33 <johnthetubaguy> just after n-2 is the current suggestion
20:57:40 <mtreinish> dims_: ok cool
20:57:41 <anteaya> johnthetubaguy: didn't flanders start one on the usercomittee ml?
20:57:45 <johnthetubaguy> ideally not clashing with midcycles
20:57:53 <johnthetubaguy> anteaya: oh, possibly
20:57:55 <dhellmann> johnthetubaguy : that seems ok-ish from a release perspective
20:57:56 <annegentle> dims_ I think it would be useful
20:58:08 <johnthetubaguy> dhellmann: yeah, that seems less terrible to me at least
20:58:11 <amrith> dhellmann, did you have a place in mind?
20:58:15 <anteaya> johnthetubaguy: I thought I saw one, I think they call it hackfest
20:58:16 <dims_> thanks annegentle. will ping you too
20:58:26 <dhellmann> amrith : for ann arbor? I'm going to be at the sheraton
20:58:33 <amrith> dhellmann, yes. thx
20:58:36 <johnthetubaguy> anteaya: yeah, that sounds right, the name seems to change each year
20:58:39 <amrith> seems like that's where the majority are.
20:58:45 <rockyg> anteaya, that's a hackathon in Guadalehara
20:58:48 <anteaya> johnthetubaguy: it does indeed
20:58:49 <dhellmann> anteaya : oh, I thought that was something else
20:58:55 <rockyg> Sorry bout the speelling
20:58:56 <ttx> in other news, some people have complained about the TC meeting being just too noisy. Feel free to shout suggestions on how to fix that. I still would prefer not to have to use voicing to reduce parallel discussions, but maybe that's a solution to slow down the discussion
20:59:18 <anteaya> johnthetubaguy: I have OpenStack Hackathon: start to planning and recruiting as a subject line
20:59:25 <anteaya> dhellmann: oh is that some other thing?
20:59:33 <annegentle> I'm working on idea for docs tags, to show which project have certain types of docs. Also need to determine which projects need REST API docs.
20:59:35 <johnthetubaguy> that could be different, I will take a peak
20:59:45 <johnthetubaguy> annegentle: nice
20:59:46 <rockyg> anteaya, yup, something else
20:59:46 <dhellmann> anteaya : I thought so, but could be wrong
20:59:46 <sdague> johnthetubaguy: the bug smash was pretty ineffective last time though. It would be better to post mortem and figure out a better approach I think
20:59:53 <anteaya> johnthetubaguy dhellmann if I'm wrong do say so
21:00:06 <flaper87> ttx: to be honest, when topics get too heated, it gets harder for me to follow all discussions. I try to just follow one but then I get distracted AND it feels bad to ignore the rest. Also, you never know when someone might actually say something on topic
21:00:14 <dhellmann> sdague : I had word that other sites had better outcomes, but I agree in general
21:00:16 <flaper87> maybe it's just me
21:00:18 * flaper87 shrugs
21:00:28 <dhellmann> flaper87 : ++
21:00:32 <johnthetubaguy> sdague: yeah, it was hit and miss, where I went there were very few folks to start with
21:00:35 <dtroyer> flaper87: not just you
21:00:39 <ttx> I usually read scrollback and thenrepsond to an old question, further killing the discussion
21:00:51 <christx2> hello from London
21:00:58 <johnthetubaguy> sdague: I will ask about some discussion on the format
21:01:12 <anteaya> christx2: stand by for the scientific meeting
21:01:20 <anteaya> christx2: the tc meeting is in progress still
21:01:20 <dhellmann> ah, we're over
21:01:25 <ttx> flaper87: one alternative is to take turns to speak. It will slow down things dramatically, but maybe would be more productive
21:01:28 <edleafe> flaper87: we should keep all those non-TC folks from posting :)
21:01:33 <ttx> alright, let's clear the room
21:01:40 <ttx> #endmeeting