20:02:45 <ttx> #startmeeting tc
20:02:46 <openstack> Meeting started Tue May 10 20:02:45 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:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:49 * rockyg lurking under the bushes
20:02:49 <openstack> The meeting name has been set to 'tc'
20:02:50 <morgan> ooh do we have enough?
20:02:55 <ttx> Hi everyone!
20:02:56 <mtreinish> ttx: oh, sry I guess I didn't raise my hand
20:02:57 <ttx> morgan: we do
20:02:58 <sdague> o/
20:03:01 <morgan> ttx: okie
20:03:06 <ttx> Our agenda for today:
20:03:09 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:19 <ttx> #topic Update management expectations for release tags
20:03:31 <ttx> #link https://review.openstack.org/308045
20:03:33 * stevemar lurks in the background
20:03:40 <ttx> This is about adding a few warnings about release models, to help people pick the right ones
20:03:51 <ttx> We have 7+ votes on this one so I'll approve it now, unless someone wants to discuss those further
20:03:53 <flaper87> o/
20:04:19 <mtreinish> ttx: I was just wondering there are a bunch of projects with tags today that don't meet the new requirements
20:04:32 <flaper87> wait, I don't want to discuss these further. I'm just saying hi :P
20:04:32 <ttx> like ?
20:04:53 <mtreinish> tempest
20:05:16 <mtreinish> it doesn't go through the relmgt but it's tagged as one of the cycles ones
20:05:29 <dhellmann> there are 2 ways to fix that
20:05:45 <mtreinish> yeah, remove the tag or go through relmgt
20:05:49 <dhellmann> right
20:06:23 <dhellmann> we'll do an audit of the other deliverables and talk to their owners
20:06:30 <mtreinish> I just was saying the tags were previously just a cadence thing and now it's more than that. Is it just tempest in this case
20:06:30 <ttx> should that block the tag change ?
20:06:37 <flaper87> I don't think it should
20:06:37 <mtreinish> ok, that's what I was wondering
20:06:40 <mtreinish> ttx: nah
20:06:55 <ttx> release models have always been a catch-up game
20:07:01 <dhellmann> I believe I've removed tagging permission for most of these projects already
20:07:09 <ttx> trying to align the model with project reality
20:07:46 <ttx> ok, so if it's not an objection but just a side question, I propose we approve it and I #action dhellmann to look into the oddities
20:07:57 <mordred> dhellmann: you're gonna get actioned
20:07:59 <flaper87> ++
20:08:06 <flaper87> All for actioning dhellmann
20:08:31 <ttx> #action dhellmann to look into (or delegate looking into) release model oddities as a result of https://review.openstack.org/308045
20:08:48 <ttx> and approved
20:08:49 * dhellmann notes that "delegate" and that ttx is also on the release team
20:09:03 <ttx> yeah, that was my way of half-actioning me
20:09:11 <ttx> #topic Naming for P & Q
20:09:18 <annegentle> action fractions
20:09:29 <ttx> Those are 4 reviews clarifying the language in the naming rules so that they continue to work in the future
20:09:37 <ttx> ...and narrowing the geographic locations for P and Q
20:09:43 <ttx> * Remove sentence about version numbers (https://review.openstack.org/312127)
20:09:53 <ttx> * Clarify language around summit to name mapping (https://review.openstack.org/312128)
20:10:01 * mordred wrote patches
20:10:01 <ttx> * Add naming poll info for P release (https://review.openstack.org/310425)
20:10:09 <ttx> * Add naming poll info for Q release (https://review.openstack.org/310426)
20:10:16 <ttx> mordred: want to talk about those ?
20:10:19 <mordred> sure!
20:10:35 <ttx> mordred: do you like to talk ?
20:10:35 <dhellmann> so when we say "the summit" we're talking about the thing we have now, and not the new gathering thing, correct?
20:10:38 <mordred> so - 312127 is cleanup. it references an old method of numbering things
20:10:41 <mordred> dhellmann: yes
20:10:43 <ttx> dhellmann: yes
20:11:02 <dhellmann> k
20:11:37 <mordred> 312128 is an attempt to capture the actual reality as it is now, but also in such a way that the p and q patches don't get caught into a sea of loosely defined words
20:11:38 <ttx> dhellmann: basically this is picking option 3, as described in my comment on https://review.openstack.org/#/c/310425/
20:12:23 <mordred> before we talk about p and q - any concerns/questions/hotdogs on the first two?
20:12:24 <ttx> the benefit is that it's a single rule which works for the past and the future
20:12:34 <mordred> ttx: ++
20:12:36 <sdague> slight diversion, on the numbering / naming. If the name for the summit and the release are not actually going to quite be the same thing. Have we considered synchronizing the numbers for components. Because which nova, cinder, keystone, barbican are all released together and were potentially tested together is becoming more confusing
20:12:44 <ttx> whatever the future holds
20:13:05 <mordred> sdague: I'm confused by your confusion
20:13:10 <mordred> sdague: can you restate that?
20:13:28 * flaper87 confused by mordred's confusion on sdague's confusion
20:13:36 <sdague> mordred: tell me what versions of cinder, nova, keystone, neutron, glance were tested together in "mitaka" cycle
20:13:40 <dhellmann> ISTM that we'll call it the $name PTG and the $name summit, so I'm not sure they would be different
20:13:42 <ttx> the name for the release will be the name for the summit happening during its development.
20:13:54 <mordred> yah. what ttx said
20:13:58 <mordred> this should not change that
20:14:01 <dhellmann> sdague : http://releases.openstack.org/mitaka/index.html
20:14:18 <sdague> dhellmann: sure, but I bet know one can tell off the top of their head
20:14:41 <sdague> anyway, it's a diversion, we can move on
20:14:46 * mordred would just grab the stable/mitaka branch of openstack/openstack ...
20:14:48 <ttx> sdague: that's not really a new issue introduced by this patch though
20:14:49 <dhellmann> sdague : probably not. and that will only get worse over time as more projects are added. Does it make sense to add something in Ocata and start numbering it somewhere other than 1?
20:15:02 <ttx> http://ttx.re/new-versioning.html
20:15:10 <ttx> June 26, 2015
20:15:19 <dhellmann> yeah, this has been an issue since we changed versions in liberty
20:15:21 <sdague> dhellmann: yeh, I was thinking max(version)
20:15:23 * rockyg agrees with sdague and thinks maybe an inventory of stuff released to gether should be in every project?
20:15:43 <dhellmann> maybe we should talk about this separately from the naming?
20:15:43 <ttx> the releases.o.o website is tracking the version numbers
20:15:45 <sdague> because, especially log messages in components tend to indicate version numbers which are all unsycned
20:15:45 <annegentle> I think the releases.openstack does have the inventory
20:15:50 <flaper87> Having an inventory is fine, I'm not sure about aligning projects versions
20:16:11 <sdague> anyway, lets table to a future meeting
20:16:15 <flaper87> ++
20:16:17 <sdague> it's a bit orthoginal
20:16:19 <dims> ++ table
20:16:29 <cdent> everything keeps going back to if openstack is a unitary thing, or a collection of disparate parts
20:16:36 <mordred> cdent: it is a unitary thing
20:16:39 <mordred> always has been
20:16:43 <mordred> and that has not changed
20:16:48 <ttx> alright let me see how many votes we have now
20:17:03 <mordred> it was decided I think 4 or 5 years ago in a vote of what I think was actually teh TC but might have been the PPB
20:17:07 <mordred> and to my knowledge nothing has changed that
20:17:20 <dtroyer> mordred: except it (individual projects) doesn't seem to act like it a lot of the time…
20:17:23 <ttx> Looks like we have enough to pass them all now. Objections ?
20:17:26 <mordred> dtroyer: yes. that is correct
20:17:34 <mordred> individual projects like to buck the One Project decision
20:18:07 <mordred> but lacking a decision to the contrary, the existing decision stands and part of our work is working with those projects to remove the disparity
20:18:14 <annegentle> who makes sure projects do release notes?
20:18:27 <sdague> maybe we should reopen in open discussion?
20:18:29 <annegentle> (also can be tabled, heh)
20:18:31 <annegentle> yeah
20:18:32 <ttx> I'll take that as a "go ahead, approve"
20:18:39 <dims> ++ttx
20:18:45 <flaper87> ttx: go
20:18:47 <annegentle> let's name us some releases
20:18:51 <ttx> done
20:19:03 <ttx> #topic Update Magnum Description and Mission
20:19:09 <ttx> #link https://review.openstack.org/311476
20:19:19 <ttx> This one is the result of a discussion at the Summit around Magnum's scope
20:19:27 <ttx> The commit message summarizes the discussion better than I can
20:19:32 <mordred> ttx: did you approve the P and Q things too? I guess that means I get to go do some work :)
20:19:37 <ttx> mordred: yes
20:19:46 <ttx> This will result in a new project team being created to focus on the abstraction API side of things
20:20:00 <ttx> mordred: looks like they took our suggestion for the name afaict
20:20:16 <ttx> IMHO the split will really help since those are two different use cases with two different user bases
20:20:32 <ttx> And confusing the two really hurt the messaging around Magnum in the past
20:20:33 <dhellmann> ttx: this *may* result in that -- I don't remember anyone actually volunteering to do that work in the summit session
20:20:43 <thingee> Aside from the usage of scaling which I guess is addressed, that was my only thought.
20:20:47 <flaper87> I believe the split will help clarifying the goal, which was confusing to many (including me)
20:20:47 <ttx> dhellmann: I've seen launchpad groups being created
20:20:54 <dhellmann> ah, ok
20:21:06 <annegentle> split good in this case.
20:21:22 <dims> flaper87 : indeed
20:21:31 <ttx> hmm, although the name is already taken
20:21:35 <ttx> anyway
20:21:41 <flaper87> thingee: I honestly think the use of scaling there is fine. It's really about spreading out COEs.
20:21:41 <mordred> \o/
20:21:43 <annegentle> ttx what was the name?
20:21:45 <ttx> Since Hongbin (PTL) pushed the most recent patchset I consider he is OK with the current wording
20:21:48 * mordred has named yet another openstack project
20:21:54 <ttx> annegentle: Higgins, the butler in Magnum
20:21:59 <annegentle> hee
20:22:10 <thingee> flaper87: my thought was whether it's COE's themselves, not magnum scaling.
20:22:20 <hongbin> Confirm. I am fine with that
20:22:25 <ttx> thingee: COEs don't autoscale
20:22:35 <ttx> they need a lot of help, which Magnum provides
20:22:41 <dims> thingee : operators can scale up COE's with COE's cooperation :)
20:22:46 <ttx> apps deployed on COEs autoscale
20:23:01 <ttx> (as long as there is enough space on the COE)
20:23:18 <dims> ttx : y that too
20:23:29 <ttx> was still missing a couple of TC members votes last I looked
20:23:31 <ttx> Questions ?
20:24:01 <ttx> Looks like we have 9+votes now
20:24:03 <flaper87> dims: I like the "with COE's cooperation" part
20:24:07 <mordred> ++
20:24:15 * morgan is waiting for the page to load.
20:24:20 <dims> :)
20:24:25 <morgan> #coffeeshopwifi
20:24:43 * thingee is on the same wifi - it's no good.
20:24:45 <ttx> ok, approving now
20:25:00 <ttx> #topic Add golang as an approved language
20:25:06 <ttx> #link https://review.openstack.org/312267
20:25:19 <ttx> This one is likely to take a few meetings before we come to a conclusion, especially with the ML thread being in full swing
20:25:20 <dims> the thread is *still* active
20:25:23 <mordred> morgan: I read that as "coffees hop"
20:25:33 <ttx> The programming language resolution from last year opens the door to supporting new languages in OpenStack official projects
20:25:35 * thingee waits for termie to appear
20:25:37 <morgan> mordred: that too
20:25:41 <ttx> #link http://governance.openstack.org/resolutions/20150901-programming-languages.html
20:26:01 <ttx> It explains that we should weigh the technical benefits for OpenStack (using the best tool for the job) against the community costs (community fragmentation, infra overhead...)
20:26:23 <ttx> The proposal is that we add Go as a supported language for official OpenStack projects, so that performance-sensitive data-plane pieces of Swift, rewritten in Go, could be merged in mainline code
20:26:35 <ttx> Designate has similar needs for a DNS server proxy, and would use Go for that if we added it
20:26:49 <ttx> Before this goes in every direction, I'd like to try to structure the discussion
20:26:49 <mordred> thingee: perhaps the openstack version of godwin's law sohuld be called "Thingee's Law" and should be "As an online discussion grows longer, the probability of a comparison involving termie approaches 1"
20:27:09 <ttx> First discuss the perceived community costs, then the technical benefits for OpenStack, and then weigh one against the other
20:27:10 <mugsie> ttx: well, we were going to propose something simlar if swift hadn't
20:27:25 <mordred> ttx++
20:27:26 <flaper87> mugsie: I assume we == designate
20:27:31 <ttx> So... community costs first
20:27:38 <mugsie> flaper87: yeah
20:27:43 <ttx> Adding any language is a bit costly in community terms, but we should try to estimate and quantify how costly Go is likely to be
20:27:57 <ttx> First cost is community fragmentation, which was raised by bswartz on the ML
20:28:26 <ttx> "strongly believe that mixing 2 languages within a project is always the wrong decision, and doubly so if one of those languages is a niche language. The reason is simple: it's hard enough to find programmers who are competent in one language -- finding programmers who know both languages well will be nearly impossible. You'll end up with core reviewers who can't review half of the code and
20:28:28 <ttx> developers who can only fix bugs in half the code."
20:28:29 <thingee> mordred: very good - but mostly because he would've wanted us to go this path eventually :)
20:28:33 * bswartz1 lurks
20:28:51 <flaper87> ttx: yeah, I pointed that out on the review as well. I admit this bit worries me.
20:28:59 <ttx> flaper87: bswartz1: that's definitely a valid concern
20:29:02 <mordred> we've seen this pain to a degree with python and javascript
20:29:10 <ttx> I think of all languages we could add Go is not the worse
20:29:12 <mordred> it's not just theoretical
20:29:16 * amrith mumbles something inaudible about .NET
20:29:25 <ttx> since there is some decent overlap in communities
20:29:33 * edleafe smacks amrith
20:29:35 * notmyname sees IRC client light up
20:29:36 <clarkb> mordred: and java
20:29:38 <ttx> (more than between Python and Java or Python and C)
20:29:48 <annegentle> how do we get operators input? packagers?
20:30:04 <morgan> ttx: ++ on go not being the worst
20:30:06 <flaper87> Eventually, I believe we'll end up with a split community. Not every Go developer is a pthon developer and the other way around.
20:30:07 <thingee> there have been some people in thread speaking on it's maturity. seems like most of the pain pointsthere were captured in the last infra meeting
20:30:20 <mordred> well, I mean we've seen the issues in active openstack projects where the project is in two languages - python and javascript being the combo that we have currently
20:30:22 <mtreinish> mordred: yeah, I see that issue in openstack-health (granted it's a big example)
20:30:25 <thingee> wrt to dependnecy management
20:30:29 <ttx> For JavaScript we basically considered that the fragmentation was a necessary evil -- you can't program a client side web interface in Python
20:30:37 <mtreinish> s/it's/it isn't/
20:30:38 <ttx> but the fragmentation exists
20:30:41 <mordred> exactly
20:30:45 <flaper87> ++
20:30:52 <mordred> it's not a show-stopper
20:30:55 <mordred> it's just a thing
20:30:59 <mordred> and is a real cost
20:31:08 <ttx> A project like StoryBoard definitely suffered from being coded in Python + Javascript, requires dual expertise to be a core there
20:31:23 <dims> we have had projects cope already - "We already had that, for example in Horizon, moving from a mostly Python
20:31:23 <dims> oriented community to a mostly JavaScript community." from Matthias
20:31:53 <Kiall> While I understand the difficultly for contributers, was this not raised when allowing other languages was first approved? Once more than 1 language is allowed, especially "server side" projects, the fragmentation is inevitable - is this then a separate discussion around allowing dual languages in a single project vs allowing Go (or <insert language here>) into OpenStack?
20:32:02 <annegentle> ttx: our community is more than devs, naturally. So I want to hear more technical info on the downstream effects, can you run multiple sourced services when coded in both Go and Python? or is it one or the other?
20:32:08 <dims> should be upto the project and cores to take the plunge i think
20:32:13 <mugsie> dims: ++
20:32:14 <mordred> Kiall: it's purely a discussion of the community costs currently
20:32:19 <flaper87> dims: That's one of the reason I don't contribute to Horizon. I just don't do JS.
20:32:22 <ttx> Kiall: I think if the language is really needed, then this outweighs the cost. It's a trade-off
20:32:37 <ttx> but we should just not underestimate the community fragmentation cost
20:32:38 <Kiall> mordred: Right, but those costs must have been weighed when http://governance.openstack.org/resolutions/20150901-programming-languages.html was approved, no?
20:32:49 <flaper87> annegentle: ++ on packagers and ops feedback needed
20:32:53 <annegentle> does it need a separate gate? or is supporting Go a similar sized effort to the javascript efforts?
20:32:56 <thingee> mordred: my only show-stopper has been support in gate and understanding that. Happy to see the last infra meeting touch on this. Without gate testing, we don't really have much to show.
20:32:57 <amrith> dims, I disagree. I think the projects and the cores should have an input but the decision should not be delegated down (if that is what you implied)
20:32:58 <ttx> Kiall: no, we decided that we would exmaine each language case-by-case
20:33:10 <mordred> Kiall: no - that was more about asserting that there was no specific python requirement
20:33:12 <dtroyer> annegentle: Go doesn't have the co-installability issues that Python does… static-linking effectively makes every binary like a packaged venv
20:33:28 <notmyname> annegentle: flaper87: from the swift side, we've got that. we've already seen swift+golang deployed together in prod
20:33:30 <mordred> Kiall: and that we'd address specific suggestions as they arose using our best judgement
20:33:32 <Kiall> ttx+mordred: noted.
20:33:32 <dims> amrith : here we can choose that golang is a valid option. then projects can choose where to add that to their arsenal
20:33:36 <flaper87> Everyone, please, let's focus on the community cost for now.
20:33:40 <annegentle> dtroyer I've seen that for clients, okay.
20:33:47 <morgan> if infra has the tools they need and the questions are resolved around it for reproducible installs/builds/testing it is less of a concern to me.
20:33:52 <ttx> Second type of community cost is infra / QA / release management support
20:33:53 <flaper87> notmyname: that's actually great news
20:33:54 <devananda> I agree that the fragmentation concern, within a project, is a worthwhile concern. We've seen it within Ironic
20:33:57 <morgan> but it is a serious concern if we don't have that answered.
20:34:03 <mugsie> is there a bigger community cost from allow just some projects, or allowing a free for all?
20:34:10 <mugsie> allowing*
20:34:11 <ttx> do we have any idea what we are getting into there ?
20:34:21 <mordred> morgan, thingee: we had the beginnings of the discussion with notmyname in the previous infra meeting about infra needs
20:34:21 <jeblair> dtroyer: it may or may not have similar issues when it comes to distro packaging (coinstallability isn't just about virtualenvs, it's also about dependency management and packaging/distribution)
20:34:43 <amrith> dims, that brings me to my concern on this which is how the intended governance model would work. Is what is being discussed here "Go for Swift" or "Go for All"
20:34:49 <dhellmann> ttx: I haven't really started looking at what it would take to release go code using our current systems for releasing other things
20:34:54 <ttx> mordred, jeblair: any chance you could summarize the early discussion on infra cost ?
20:34:55 <morgan> mordred: ++ i was watching. but seeing that move in a positive direction would be a requirement for me to sign off on this move.
20:35:00 <mordred> ttx: it's very early
20:35:06 <dtroyer> jeblair: right, but that is now a build-time/package-time issue, not a deployment issue
20:35:07 <morgan> and additions.
20:35:09 <mordred> so - the main thing is that we've got some design thinking to do
20:35:11 <Kiall> ttx: IMO, not really. We'll not have a reasonable idea until we try it.
20:35:20 <mordred> go has a very different set of assumptions
20:35:20 <thingee> mugsie: gate testing is a community cost - if you consider free for all
20:35:32 <david-lyle> Horizon has a lot of issues with fragmentation, and JS is a reasonable knowledge expectation for UI developers, but it also inhibits outside contribution
20:35:32 <morgan> because i don't want to see us say "Lang X is GREAT! AND WE USE IT" with out a path on the infra front.
20:35:35 <mordred> which means that we have to learn things about what tooling go has now
20:35:44 <mordred> and figure out how it fits in with the rest of things
20:35:48 <flaper87> I certainly don't feel comfortable letting this in until we have a better understanding of what the pla is CI/Infra wise
20:35:52 <mordred> we're in the phase right now of collecting reuqirements
20:35:55 <mugsie> yeap. but less fragemtation is a potential plus (as there might be more people familair with go)
20:36:00 <thingee> flaper87: +1
20:36:25 <devananda> will there be an expectation that a go-project publish its docs in the same format as python projects?
20:36:27 <bswartz> It seems to me that teams which wish to implement parts of their projects in Go (or any other language) could do so outside the tent and integrate with projects inside the tent in exactly the same manner that all 3rd party vendors integrate
20:36:29 <mordred> mugsie: just to be clear - one of openstack's problems (and it has many) is not ability to find contributors
20:36:32 <sdague> mugsie: but will they be familiar with our very python way of doing it? Like imposing python concepts around docs?
20:36:37 <devananda> or that a go-sub-project's docs be written into the docs of the parent-project?
20:36:37 <morgan> mordred: so i think this is where we can continue to explore the CI story and infra story before we need to sign off on this choice (and it sound slike we might need to think about this for more than just golang)
20:36:43 <thingee> so as said in the review, let designate and swift begin showing collaboration on this effort by figuring out the ci/infra pieces together.
20:36:44 <annegentle> and, what definition of complete for infra/test/doc/release would allow a Go project to start?
20:36:56 <morgan> thingee: ++
20:36:57 <flaper87> bswartz: right
20:36:59 <flaper87> thingee: ++
20:37:05 <mordred> annegentle: I think we need to have an idea of what the issues are, that they are solvable, and who is going to work on them
20:37:12 <flaper87> ok, my IRC exploded and it's getting hard to follow.
20:37:12 <annegentle> devananda I'd like discussion on that docs Q as well
20:37:13 <mordred> annegentle: I don't personally think we need them all solved at the outset
20:37:13 <ttx> I think all cross-project team need to do their homework and tell us what a world with Go would look like from their perspectrive
20:37:21 * amrith tries to parse mordred's last comment
20:37:25 <annegentle> mordred nor do I, but a list would help.
20:37:26 <thingee> mordred: +1
20:37:36 <amrith> ... " one of openstack's problems (and it has many) is not ability to find contributors"
20:37:37 <morgan> bswartz: i am not willing to prevent non-python inclusion if we have the other bits lined up.
20:37:43 <mordred> amrith: I think we need to have at least identified the issues and who is going to work on solving them
20:37:47 <mordred> oh. that
20:38:05 <amrith> I think 'not' in the wrong place, maybe. ok
20:38:05 <bswartz> morgan: it's another option which should be considered
20:38:07 <mordred> amrith: mugsie made a comment about possibly opening the door to the potential hordes of go devs
20:38:09 <devananda> ttx: ++
20:38:14 <annegentle> heh, off the top of my head, no special treatment for Go docs. That makes things easier.
20:38:16 <morgan> bswartz: i think it is unreasonable to say "no languages but python/js (at this point)" out of hand. but coming up with the story/way to handle it is important before we specifically include it
20:38:20 <mordred> amrith: I was merely pointing out that finding developers is not a probelm we have currently
20:38:27 <mordred> in fact, if we could have a few less it would be nice
20:38:29 <annegentle> notmyname if you can think of a Go-based doc system we should look into, let me know.
20:38:46 <mugsie> mordred: I doubt there will be hoards, but there might be more people in the community with familiarity of both languages
20:38:47 <morgan> bswartz: am willing to say this will come up again even if we ask it to be 3rd party for now.
20:38:48 <mordred> annegentle: last we chatted, I think "godoc" was tossed out as the thing that did dev-level docs
20:38:57 <annegentle> mordred yeah that's sort of the point here, should we prioritize and focus?
20:38:57 <ttx> the release management team will look into that too, and I suspect the discussion with infra will continue this week as well
20:38:58 <amrith> mordred, I think there are different problems in different projects but let's stay on the 'go-train' for now.
20:39:01 <mugsie> instead of just a small group of people in swift + designate
20:39:07 <timsim> annegentle: Go has a certain level of documentation built in https://godoc.org/golang.org/x/tools/cmd/godoc
20:39:09 <morgan> it might be the ultimate solution, but... we'll see as the convo progresses
20:39:16 <notmyname> annegentle: it's on the list of stuff to answer. currently the full extent for the answer is "godoc + sphinx". (which isn't a full answer, obviously)
20:39:17 <flaper87> I think we should move gradually with this inclusion. If anything, we should start just with specific cases rather than opening the gate to every project.
20:39:26 <devananda> ttx: it seems there are two threads to the discussion. a) social fragmentation of project teams b) technical challenges to meeting existing expectations around shared infrastructure
20:39:31 <annegentle> notmyname timsim check.
20:39:48 <clarkb> one of the things that I am noticing is that a large part of the language change choice seems to be based on the performance of a specific implementation detail in how we use python: eventlet
20:39:48 <mordred> devananda: ++
20:39:55 <mordred> clarkb: ++
20:40:00 * mordred stabs eventlet
20:40:02 <amrith> clarkb +++++
20:40:02 <annegentle> devananda I think a) should include fragmentation of all community teams.
20:40:03 <cdent> clarkb++
20:40:08 <clarkb> it is probably also worth considering that maybe we have made poor lib choices and that langs are not necessarily the thing to get stabbed here
20:40:09 <dims> clarkb : true
20:40:17 <flaper87> clarkb: +1
20:40:20 <devananda> clarkb: ++
20:40:27 <dhellmann> clarkb : yeah, I'd love to see a comparison with asyncio or twisted or some other similar framework
20:40:28 <mestery> clarkb: ++
20:40:41 <ttx> clarkb: that's part of the technical benefits discussion
20:40:46 <morgan> so lets be fair, if the social fragmentation is a real concern, isn't it fair to let a couple projects lead into it?
20:40:47 <dtroyer> yay! back to twisted!
20:40:52 <morgan> and see how it goes (beyond horizon)
20:40:54 <dims> clarkb : i still think having one more choice is not bad. projects can choose to take adopt it or not
20:41:00 <notmyname> for swift, it's not eventlet that's the problem. it's the way threads are handled
20:41:02 <morgan> espe. with the overlap within python and golang communities?
20:41:15 <clarkb> dims: sure there may be a valid reason to switch it just seems odd to say "eventlet is bad so we used Go"
20:41:17 <clarkb> wat
20:41:19 <ttx> so, to stay on the community costs side of the discussion...
20:41:25 <flaper87> morgan: mentioned that above. Letting 1 or 2 projects experiment should be fine as long as the concerns on Ifra/CI are clarified
20:41:26 <morgan> ttx: ++
20:41:30 <annegentle> morgan but that's part of the problem of defining community costs ONLY with dev cost.
20:41:31 <clarkb> its definitely a way to address that issue, but its a very high cost one compared to potential alternatives
20:41:31 <mordred> yah ... SO
20:41:37 <mordred> I'd like to disagree with morgan
20:41:48 <mordred> the costs on the infra side to support go are not going to be small
20:41:50 <dims> flaper87 : swift and designate have already done PoC's
20:41:52 <ttx> devananda listed two aspects of community costs, are there others ?
20:41:52 <mordred> it's going to be a LOT of work
20:42:05 <thingee> dtroyer: NO https://wiki.openstack.org/wiki/UnifiedServiceArchitecture
20:42:09 <mordred> so doing that work to allow one or two projects to 'experiment' is a bad approach
20:42:11 <thingee> :)
20:42:17 <annegentle> there's way more than dev cost here. infra, test, doc, packaging, deploying
20:42:25 <flaper87> dims: I know but POC is out of the TC governance and they've done that on specific environments and different communities circunstances
20:42:31 <mordred> the work on all of the things may well be completely worthwhile
20:42:33 <devananda> morgan: we already have fragmentation between python and JS community, as was pointed out earlier
20:42:38 <flaper87> I'm worried about the community not the technical implications in the specific projects
20:42:42 <morgan> mordred: is it true we have to do someo of this work *anyway* though for any new language?
20:42:57 <mordred> morgan: there is a cost for every new language, yes
20:43:00 <morgan> is it worth generalizing the approach mostly at this time, and then move into "language" specifics?
20:43:05 <mordred> this is the reason that we don't want people just doing new languages all the time
20:43:07 <morgan> or are we already past the generalization part
20:43:12 <mordred> and why we're talking about it now
20:43:23 <dims> mordred : this resolution does not do that...just go
20:43:26 <mordred> I'm just saying that I think we can sort out the pros/cons before asking someone to go figure out deps and mirroring for infra
20:43:33 <mordred> dims: yes. exactly
20:43:45 <mordred> oh. wait. I was disagreeing with flaper87 not morgan
20:43:50 <dims> lol
20:43:51 <devananda> morgan: I believe adding another language will create another "group" of folks that, while part of the big tent, feel disadvantaged and perhaps struggle to work with the Python community
20:43:51 <morgan> mordred: hehe.
20:43:51 <mordred> I think
20:43:53 <flaper87> mordred: what did I do now?
20:43:54 <mordred> no idea
20:43:57 <mordred> I was disagreeing with SOMEONE
20:44:01 <mordred> who may or may not even be here
20:44:07 <ttx> OK, we need to move on
20:44:11 <dims> devananda : now we are telling them to go away, which is not good either
20:44:15 <mordred> ttx: but we're having so much fun!
20:44:17 <devananda> mordred: +1 to figuring out the _technical_ costs of to sharing infrastructure across languages
20:44:28 <devananda> mordred: before folks go off and do a bunch of work
20:44:30 <mordred> devananda: yes
20:44:37 <mordred> although I think it's not just technical
20:44:40 <mordred> there is a social cost here
20:44:42 <ttx> So I think we managed to narrow down the community costs to two broad categories, one of them needing investigation by various teams
20:44:43 <mordred> which sounds techincal
20:44:46 <mordred> but I tink is a community thing
20:44:46 <devananda> and i believe that can be done by a collaboration between some TC / CPL folks, and some golang folks
20:44:56 <flaper87> mordred: social cost, that's the biggest of my worries here
20:45:01 <mordred> that is - there are a different set of underlying assumptions as to goals/desires baked in to various languages
20:45:03 <ttx> I'd like to have time for a quick summit postmortem in open discussion while we still remember what happened there
20:45:04 <dims> mordred : we are heavily weighted towards what we know...python
20:45:06 <devananda> I'm not assuming that those are the same people -- but if there are golang experts on the TC / CPL team, great :)
20:45:11 <mordred> go makes a different set of tradeoffs
20:45:13 <mordred> which si great
20:45:16 <mordred> it should
20:45:24 <dhellmann> ttx: I would also like time to discuss the leadership training trip
20:45:28 <mordred> but mapping those social expectation tradeoffs into our world
20:45:31 <ttx> so I propose we defer the discussion on the technical benefits of Go to next week -- that will let the ML thread continue to grow
20:45:37 <mordred> is a community issue in addition to a techincal issue
20:45:41 <devananda> dhellmann: as would I
20:45:51 <flaper87> perhaps we should discuss this again next week and summarize today's discussion in the review
20:45:58 <mordred> a case in point - go has an amazing ability to reference depends directly via git
20:46:01 <mordred> which is neat and tehcnical
20:46:16 <mordred> but it places a very different value on 'releases' than we traditionally have
20:46:26 * dhellmann would find all of this easier to digest in a document instead of irc
20:46:28 <mordred> and the broader go community operates in that way
20:46:28 <amrith> morded .. it is a nightmare for packagers ...
20:46:29 <dims> mordred : y we peeled that onion the other day on -dev
20:46:38 <mordred> dims: awesome
20:46:43 <dims> amrith : y zigo already mentioned that
20:46:55 <ttx> OK - let's continue on the thread, I'll summarize the discussion on community costs on the review, and talk technical benefits next week
20:46:57 <dtroyer> mordred: that is one thing we will nedd to have specific guidance about… just because tooling allows bad practice doen't make it right… so yeah…
20:47:12 <mordred> dtroyer: and not just allows - but actively promotes
20:47:13 <dims> dtroyer : ++
20:47:19 <ttx> #action ttx to summarize community costs start-of-discussion on the review
20:47:24 <mordred> dtroyer: vendoring code is considered "the right thing" in the go community
20:47:30 <dims> yay ttx :)
20:47:37 <ttx> #topic Open discussion
20:47:38 <mordred> dtroyer: and there are several sets of tools to make it easier for people to do
20:47:44 <ttx> * Summit postmortem
20:47:53 <ttx> So... how did Austin work for you ?
20:48:02 <ttx> I'd like us to discuss this today while it's still fresh
20:48:15 <thingee> good bbq
20:48:17 <ttx> I was pretty happy with the Upstream development track, I think we should try to have that in Barcelona again
20:48:19 <mordred> the keynotes are still a wasted chunk of my day, but are a great time for me to get to sleep in a little
20:48:32 <sdague> mordred: you should have come to the dev lounge
20:48:33 <mordred> i'd rather be working with people during that time
20:48:39 <annegentle> nice to have vids to point to also for Upstream dev track
20:48:42 <mestery> thingee: Gus's Fried Chicken was great too :)
20:48:46 <dtroyer> cost me more productive time than I would have guessed
20:48:46 <annegentle> fast video posts, dang.
20:48:47 <sdague> dev lounge needs a size increase
20:48:48 <mtreinish> thingee: yes, but at the same time also not enough bbq :)
20:48:50 <mordred> sdague: maybe next time let's schedule things
20:48:57 <dhellmann> I liked the upstream track, too.
20:49:03 <dims> ++ dhellmann
20:49:09 <ttx> mordred: we managed to get the DS area doors open during keynotes this time
20:49:10 <flaper87> mordred: +1 on the keynotes feedback. I normally don't show up
20:49:14 <mestery> The location was nice, the dev area worked well!
20:49:16 <sdague> I only popped over the the upstream track once, because it was on the other side of the universe
20:49:26 <dhellmann> yeah, the walking on monday killed my feet
20:49:29 <mordred> upstream track was good - it was a shame it was on the same day as cross-project and ops - and yes, it was very far away
20:49:29 <ttx> I was pretty disappointed by the productivity of the cross-project workshops day
20:49:34 <sdague> I think that distance was sub optimal
20:49:35 <annegentle> I think I had 14k steps Mon. and Tues.
20:49:36 <devananda> I never made it into the expo hall
20:49:41 <sdague> devananda: me either
20:49:43 <mordred> ttx: yah. there were too many things co-scheduled
20:49:44 <ttx> Feels like we have the same discussions every 6 months, we spend 20 min reexplaining the issue to the attendees, we don't have the people we need in the room and then the 40-min clock hits
20:49:48 <Kiall> mordred: didn't you give a few of those keynotes? ;)
20:49:55 <sdague> ttx: I feel like the ones I were in were pretty good
20:50:02 <mordred> Kiall: heh. I gave very few of them
20:50:04 <sdague> but, again, it's about being at an actionable middle
20:50:05 <dhellmann> we had some schedule conflicts that I think could have been avoided in some of the project tracks (oslo & nova in one case)
20:50:10 <devananda> ttx: I felt that they were hit-and-miss. a couple x-project sessions I was in went well
20:50:11 <ttx> sdague: that's because you avoided the ones that were repeats :)
20:50:13 <dhellmann> we need to do a better job with PTLs of planning
20:50:17 <sdague> ttx: yes, I did
20:50:18 <dougwig> random observation, going to this summit with the idea of a split summit in mind, made me very much wish the summit was split already.
20:50:20 <sdague> intentionally
20:50:21 <mordred> sdague: we had a session we wanted you in
20:50:23 <devananda> but there were some decidedly difficult conflicts on Tuesday for me
20:50:24 <mordred> sdague: but you were in another session
20:50:34 <anteaya> dougwig: me too
20:50:35 <mordred> sdague: so the one you weren't in didn't get as far as it could have
20:50:35 <ttx> dougwig: yes, same here
20:50:37 <dims> dougwig : +1
20:50:38 <mordred> sdague: but you're juist special
20:50:41 <devananda> I also didn't go to *any* of the main conference tracks this time
20:50:45 <sdague> \o/
20:50:49 <mordred> devananda: me either
20:50:52 <devananda> since I wasn't speaking / on any panels, I completely avoided that building (aside from check in)
20:50:57 <mordred> devananda: well, I went to the ones I was giving
20:50:58 <edleafe> devananda: me neither
20:51:00 <ttx> devananda: did you wish you could ?
20:51:06 <mordred> no! I did go to one - I went to gothicmindfood's talk
20:51:14 <devananda> mordred: oh! right! I went to that one
20:51:20 <devananda> ttx: yep. that's actually an event I would like to attend
20:51:24 <mestery> I went to mordred and ttx's talk :)
20:51:24 <mordred> devananda: ++
20:51:28 <annegentle> I went between buildings for the appdev track every day
20:51:35 * gothicmindfood enjoyed all the hecklers from the TC
20:51:42 <devananda> a lot of folks on the Ironic team skipped out of the design summit to attend vendor talks, or operator talks about ironic
20:51:43 <mordred> I would love to spend time in the conference
20:51:51 <devananda> some folks are doing really cool things with the project, it turns out :)
20:51:51 <mordred> but as usual, that is not an option
20:51:57 <ttx> Another takeaway I got was that the workroom trick (trying to lure people away from work rooms to get things done) is no longer 100% working
20:52:12 <ttx> some of those rooms were completely overcrowded
20:52:15 <mordred> ttx: I do not think the workroom distinction worked at all this time
20:52:21 <mestery> ttx: That has NEVER worked for neutron
20:52:22 <mordred> at leat not for me
20:52:36 <ttx> mordred: it was only a matter of time before they saw through the trick
20:52:38 <devananda> ttx: the distinction did not make any difference for ironic this time
20:52:52 <morgan> gothicmindfood: LOL glad you enjoyed our presence ;)
20:52:53 <ttx> ok, any other feedback ?
20:53:09 <ttx> dhellmann wanted to discuss leadership training
20:53:12 <devananda> lunch options on the dev side were the worst I've seen in a while
20:53:12 <Kiall> Workshops being 2 blocks away kinda sucked :)
20:53:21 <rockyg> yeah.  don't confuse glutenfree with gluten containing stuff in the same lunch box
20:53:25 <Kiall> (Designate gave one, I nearly got lost..)
20:53:25 <gothicmindfood> ttx: I can give a quick update
20:53:31 <devananda> rockyg: yea.... :(
20:53:32 <dims> devananda : i had to go out for all lunches :)
20:53:38 <dhellmann> yes, I've noticed that about 1/2 of the TC has signed up to go to training. I've been waiting to see if there was a critical mass before committing. How many others who haven't signed up are doing the same?
20:53:38 <ttx> ok, let's parallelize this
20:53:46 <amrith> rockyg, you didn't like the vegan food with mayo eh?
20:53:47 <gothicmindfood> we've got 10 ppl + me signed up over at https://etherpad.openstack.org/p/Leadershiptraining
20:53:58 <ttx> feel free to shout summit feedback while gothicmindfood explains training
20:53:59 <dhellmann> gothicmindfood : only about 7 of those are TC
20:54:06 <rockyg> amrith, it was the pasta salad in the GF sandwich box
20:54:07 <dhellmann> gothicmindfood : which is about 1/2 of the TC
20:54:08 * dims is on vacation that week
20:54:09 * claudiub looks at the time, panics, and just throws in the networking-hyperv governance patch for review: https://review.openstack.org/#/c/311566/
20:54:15 <gothicmindfood> I'm waiting to hear from dhellmann mestery johnthetubaguy and markmcclain about attendance
20:54:31 <gothicmindfood> I've also got 3 ppl who are not current or recent-former TC members who are interested
20:54:33 <mordred> mestery: it's close-ish to where you live
20:54:48 <jroll> oh, mestery lives around here too eh? :)
20:54:50 <ttx> claudiub: will approve that one tomorrow morning unless someone complains
20:54:51 <amrith> gothicmindfood, are you taking names of people who'd liek to attend?
20:54:52 <gothicmindfood> dhellmann: some of those are recent-former TC
20:54:54 <mordred> jroll: minnesota
20:54:58 <jroll> aha
20:55:00 <jroll> not that close :P
20:55:02 <dhellmann> gothicmindfood : true
20:55:03 <amrith> non-tc members, that is
20:55:05 <mordred> jroll: :)
20:55:06 <claudiub> ttx: gotcha, thanks. :)
20:55:13 <mtreinish> jroll: yeah it is, it's all relative :)
20:55:15 <ttx> gothicmindfood: I think it's time to open to anyone
20:55:16 <gothicmindfood> amrith: current plan is to keep it open to TC and recent-former TC for the next two days, then open the rest of the slots up to the community
20:55:24 <gothicmindfood> ttx: I can do that, happily :)
20:55:24 <ttx> ++
20:55:42 <gothicmindfood> amrith: so - I'll send an email out tomorrow AM, EST to let people know they can go ahead and sign up
20:55:48 <jroll> mtreinish: I think of close-ish as driveable but fair enough
20:55:49 <gothicmindfood> even if they're not TC :)
20:55:53 <amrith> gothicmindfood, thx. will keep eye open for that.
20:55:55 * tellesnobrega is away: I'm busy
20:56:09 <morgan> gothicmindfood: so how many slots will be open?
20:56:17 <gothicmindfood> morgan: right now there are 9 more slots.
20:56:19 <ttx> gothicmindfood: If we get cross-community attendance I have ideas of hard leadership problems to discuss there :)
20:56:21 <morgan> gothicmindfood: cool.
20:56:33 <annegentle> thanks claudiub
20:56:49 <gothicmindfood> I have also asked the Foundation if there are any staff there that might be interested, but that was an aside, and I didn't get the sense they wanted me to hold spots for them
20:56:55 <mordred> dhellmann: it doesn't seem you got much of an answer from anyone who isn't on the list who isn't dims
20:56:56 <annegentle> claudiub pretty sure it'll go on next week's agenda, never fear
20:57:02 <dhellmann> mordred : no, not really
20:57:07 <morgan> stevemar: ^ cc
20:57:12 <gothicmindfood> ttx: that sounds gnarly and awesome \o/
20:57:41 <ttx> gothicmindfood: I'll talk to you about them once we have the attendance settled
20:57:48 <mordred> dhellmann: I could imagine johnthetubaguy having travel issues. I will however look askance at mestery if he skips, given it's one delta hub to another
20:57:53 <ttx> dhellmann: does that answer your questions ?
20:58:06 <gothicmindfood> ttx: sounds good
20:58:14 <dhellmann> ttx: I'll touch bases with some folks tomorrow. I think not everyone is here.
20:58:49 <ttx> OK, any other topic for open discussion ?
20:58:56 <ttx> or random thoughts ?
20:58:59 <ttx> or summit feedback ?
20:59:19 <dims> ttx : 3 keynotes...i was shaking my head :(
20:59:40 <ttx> the ones on the next day were better though :)
20:59:46 <mordred> ttx: yah. reitterating the dismay at some of the keynote content
20:59:51 <mordred> ttx: would be nice
21:00:04 <edleafe> how about Intel re-writing Nova in Go? :(
21:00:06 <thingee> thanks to dhellmann for raising that in the feedback session
21:00:15 * dtroyer sees something shiny over there
21:00:16 <rockyg> app wasn't half bad.  Just need to tie it into the phone clock on the "my sched" portion
21:00:16 <ttx> ok, out of time
21:00:17 <amrith> edleafe, c#
21:00:19 <sdague> yeh, it would be nice if the keynotes were actually about openstack, and not random non openstack gorp
21:00:19 <dhellmann> yes, the foundation folks were really receptive to that but I wouldn't want to speak for them on any action they plan to take
21:00:27 <sdague> agree thanks dhellmann for bringing that up
21:00:33 <dims> edleafe : you should have posted that just before the summit :)
21:00:34 <ttx> We'll continue the discussion on Go next week, please chime on the thread if you have a strong opinion one way or another
21:00:55 <ttx> discussion next week will be focused on technical benefits
21:00:55 <edleafe> dims: I'll time it for the next one :)
21:01:00 <dims> lol edleafe
21:01:08 <dims> sounds good ttx
21:01:09 <ttx> giving time for Infra/RelMgt/Doc to do their homework on Go support
21:01:23 <ttx> Thanks everyone
21:01:27 <amrith> ouch; did edleafe just throw that pitcher at me?
21:01:27 <ttx> #endmeeting