20:01:08 <ttx> #startmeeting tc
20:01:09 <openstack> Meeting started Tue Jun 30 20:01:08 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:13 <openstack> The meeting name has been set to 'tc'
20:01:17 <ttx> Our agenda today:
20:01:17 <jeblair> jaypipes looks like he is swimming
20:01:24 <ttx> or drowning
20:01:27 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:34 <dtroyer> o/
20:01:37 * zehicle lurking too
20:01:37 <edleafe> o/
20:01:46 <ttx> #topic Cross-project specs final approval
20:02:01 <ttx> We have a number of specs which I think have reached consensus stage and need our final approval to get through
20:02:09 <ttx> * Enabling Python 3 for Application Integration Tests
20:02:13 <ttx> #link https://review.openstack.org/#/c/177375/
20:02:36 <ttx> This one was discussed at the cross-project meeting on June 9.
20:02:42 <ttx> No objection recorded, I think it's more than time to final-approve it
20:02:56 <flaper87> no objections here
20:03:01 <ttx> any objection, last-minute comment?
20:03:06 <jaypipes> nope, lgtm.
20:03:28 <markmcclain> glad it's finally getting approved
20:03:37 <ttx> alright, it's in the pipe
20:03:45 <ttx> * Add requirements management specification
20:03:50 <ttx> #link https://review.openstack.org/#/c/186635/
20:04:01 <ttx> This one was discussed at the cross-project meeting twice, on June 9 and June 23
20:04:11 <ttx> It's already being worked on as far as I know, no objection on the spec itself
20:04:26 <flaper87> no objections here
20:04:27 <ttx> Looks ready to me. Objections ?
20:04:39 * flaper87 reads ttx's mind
20:05:12 <ttx> I'll take silence as consent
20:05:14 <ttx> and approve
20:05:24 <ttx> done
20:05:33 <ttx> * Update to CORS specification
20:05:37 <ttx> #link https://review.openstack.org/#/c/189924/
20:05:41 <jgriffith> +1
20:05:48 <ttx> This one is just small changes requested on the original CORS spec, that were pushed as a subsequent change rather than a new patchset
20:05:54 <lifeless> ttx: o/
20:05:57 <lifeless> sorry I'm late
20:05:58 <ttx> I think we can fast-track it
20:06:03 <lifeless> EFAMILY
20:06:10 <flaper87> ttx: sounds good
20:06:39 <ttx> already has TC majority anyway
20:06:47 <ttx> objections?
20:07:18 <ttx> no objections, approved!
20:07:27 <ttx> #topic Add release:managed to libraries and previously-incubated projects
20:07:43 <ttx> Those are mostly technical adjustments to reflect what the release team directly manages those days, thanks to a lot of fresh blood
20:07:47 <ttx> #link https://review.openstack.org/191893
20:07:51 <ttx> #link https://review.openstack.org/192193
20:08:06 <ttx> That kind of horizontal changes to the file generates a lot of merge conflicts, so I'd like to get them in ASAP before they generate more of those
20:08:26 <jaypipes> ++
20:08:39 <jgriffith> they have the votes
20:08:45 <flaper87> APPROVE ALL THE THINGS
20:08:53 <jgriffith> flaper87: +1
20:08:54 <ttx> first one is short of one
20:09:04 <ttx> jgriffith: could you apply rollcall+1 ?
20:09:05 <jgriffith> bahh
20:09:15 <jgriffith> ttx: done
20:09:31 <lifeless> ttx: I did too
20:10:10 <ttx> I guess an additional question would be, are you fine with adjustments to release:* tags being merged as long as two release team members agree with the change ?
20:10:20 <ttx> because those will be back
20:10:26 <russellb> yes that's fine with me
20:10:31 * flaper87 is good with that
20:10:41 <jeblair> ++
20:10:46 <markmcclain> make sense
20:10:49 <jgriffith> seems fine to me
20:10:49 <flaper87> happy to do a quick vote to keep it logged
20:10:52 <russellb> it's all changeable if something comes up worth discussing
20:11:21 <flaper87> as in, meetbot vote, logged, stamped, we told you so
20:11:35 <flaper87> anyway, I'm good with that
20:11:35 <ttx> yeah, and can revert / fix if weird
20:12:10 <lifeless> I don't think its a tc thing
20:12:10 <ttx> I'm working on a revision of the tags, and wil include that tag application rule in it for reference
20:12:23 <lifeless> we shouldn't need to spend time thinking about stuff owned by other people
20:12:24 <russellb> sounds good
20:12:37 <ttx> #agreed future release:* tag changes can be fasttracked as long as the release team approves them
20:12:48 <ttx> Thanks
20:13:01 <ttx> #topic Be specific about geography in release names
20:13:10 <ttx> #link https://review.openstack.org/191974
20:13:14 <ttx> That one looks pretty straightforward
20:13:21 <ttx> any objection to it merging here and now ?
20:13:29 <mordred> merge it
20:13:29 <ttx> we are on a ROLL today
20:13:31 <flaper87> nope
20:13:40 <russellb> merge away
20:13:52 <ttx> #topic RPM distribution packaging of OpenStack
20:14:00 <ttx> #link https://review.openstack.org/191587
20:14:08 <ttx> So.... This one was proposed as a split from the original "all packaging" team
20:14:17 <ttx> That said, that team doesn't seem to be really formed yet, and I haven't seen any recent discussion about it
20:14:26 <ttx> Which probably explains the absence of comment, the merge conflict status, and the ptl:TBD line
20:14:45 <ttx> My take is that while we don't require teams to be mature, they should still exist in reality, have a clear scope and leadership, have some meeting point...
20:14:56 <ttx> So I'd keep this one as WIP, same as the Debian packaging one
20:15:04 <jeblair> i think this is in the same situation as the deb version -- if the author comes forward and updates the proposal, i would +1 it
20:15:37 <russellb> ttx: +1
20:15:50 <jgriffith> would be good to have those coordinated IMO, maybe even in the same proposal somehow?
20:15:51 <agentle> agreed ttx
20:16:03 <lifeless> jgriffith: I think thats asking too much :)
20:16:04 <ttx> jgriffith: well they WERE in the same proposal
20:16:06 <flaper87> I went through that spec and I agree with russellb and ttx comments
20:16:13 <ttx> then realized they could probably not work that well together
20:16:29 <ttx> and would have been really two teams
20:16:53 <jgriffith> ttx: well, I was thinking more in terms of the spec
20:16:59 <russellb> i'm happy with this in concept, i just want some very basic level of a baked proposal
20:17:04 <jgriffith> ttx: still two projects, but one consistent spec but that's ok
20:17:07 <russellb> i feel like this is nothing but a incredibly high level idea
20:17:08 <ttx> OK, I'll move it to backlog until it gets updated / refreshed / progress is made / meetings happened / PTL is chosen / scope is defined
20:17:19 <russellb> +1
20:17:20 <jeblair> ttx: ++
20:17:28 <ttx> #topic Add Stackforge Retirement resolution
20:17:34 <ttx> Alright! Enough consensus
20:17:39 <ttx> #link https://review.openstack.org/192016
20:17:45 <ttx> There are a few objections to this one.
20:17:48 <jeblair> consensus this one too! :)
20:17:54 <flaper87> jeblair: lol
20:17:56 <ttx> My reading is that everyone agrees that we should encourage things that ultimately want to be an openstack project to directly file for the openstack namespace (category (a))
20:18:05 <jeblair> i think the objections are perhaps lack of clarity that could be addressed in a subsequent resolution
20:18:07 <ttx> And I think that's the main goal of this proposal: encourage "incubating" projects to directly file for big-tent inclusion
20:18:09 <jeblair> er revision
20:18:15 <ttx> I call that the "stackforge is not an incubator" effort
20:18:23 <flaper87> jeblair: agreed, for instance my last comment
20:18:28 <jeblair> ttx: indeed.  the main goal is not to reduce service, but instead to stop moving projects from org to org
20:18:29 <ttx> Not everyone agrees that we should discontinue support for the other categories -- especially for projects that don't ever want to become an openstack project but still want to benefit from our infrastructure
20:18:47 <ttx> For those (categories (b) and (c)), I think it was nice of us to provide resources to educate and encourage random open source projects to use nice tooling
20:18:58 <ttx> but if it's too costly to support those projects, I support the Infra team decision of dropping them
20:19:04 <russellb> i think it's totally fair for infra to not stay in the business of free infrastructure for things that don't want to be an openstack project
20:19:05 <dhellmann> we do have some projects on stackforge that I wouldn't expect to want to become official, like pecan and WSME. I spoke to the pecan lead today and he's ok with moving back to github, but we would lose some of the gating they are doing for us. I would expect the WSME maintainers to move to github, too.
20:19:11 <jeblair> i'm pleasantly surprised by that; i'd like more feedback there
20:19:19 <agentle> jeblair: is the bigger concern the org-to-org moves or the upkeep of stackforge
20:19:20 <flaper87> russellb: ++
20:19:28 <jeblair> agentle: mostly the org-org moves
20:19:41 <ttx> jeblair: Ultimately those could be two separate decisions. We could decide to communicate about "stackforge not being an incubator"
20:19:45 <jeblair> actual drain for supporting projects staying in stackforge is small
20:19:50 <ttx> And separately we can decide to stop supporting other categories in stackforge (or to stop accepting new projects there)
20:19:55 <jeblair> ttx: i agree, that's an option
20:20:32 <flaper87> dhellmann: tbh, I think that's fine. We should find a way to help them gating for us or just deal with the lack ofit
20:20:38 <dtroyer> I like the idea of having stackforge around for things (like Pecan et al) that we benefit from having similar ci
20:20:42 <dhellmann> flaper87: right
20:20:45 <fungi> i have a personal dream of just not having git namespaces at all so this silliness wouldn't be an issue, but that's not been feasible for technical reasons so far, so we're stuck with a cosmetic prefix on repository names to which people ascribe too much meaning
20:20:57 <dtroyer> maybe at that point there be some higher criteria for adding new projects to it
20:21:06 <jeblair> i think we would need to characterize when we think it's reasonable for a project that deos not want to join openstack to use the service
20:21:07 <dhellmann> fungi: we could rename stackforge to notnotopenstack
20:21:08 <lifeless> fungi: should we rename the world. To z/nova, z/cinder,
20:21:16 <lifeless> fungi: and f/pecan, etc. ?
20:21:31 <fungi> not so keep on renaming 700 repos either, so... meh :/
20:21:36 <fungi> s/keep/keen/
20:21:59 <dhellmann> in the case of pecan, we're limiting their ability to test under versions of python that they care about but we don't, so the authors are ok with moving if that's the consensus
20:22:22 <dhellmann> there are other CI systems out there that folks are pretty happy with, after all
20:22:23 <jeblair> fungi: i'm much more interested in performing the big-tent moves from stackforge -> openstack if we know there's a light at the end of the tunnel :)
20:22:37 <flaper87> dhellmann: I wonder if these are the only 2 cases but I doubt it
20:22:52 <dhellmann> flaper87: no, just the 2 I'm familiar enough with
20:22:55 <jeblair> dhellmann, flaper87: we even have a couple in infra
20:22:57 <flaper87> it'd be cool to send an email out mentioning this and see who screams
20:23:00 <lifeless> so a conservative though would be to limit this to just not-an-incubator
20:23:05 <flaper87> jeblair: aha
20:23:08 <lifeless> and wait a year
20:23:24 <flaper87> jeblair: any reply to my last comment w.r.t requirements and possible instability?
20:23:27 <flaper87> am I just being paranoid ?
20:23:34 <ttx> jeblair: I think it's fair to reject things-that-clearly-want-to-be-openstack when they apply to stackforge and tell them to apply for big tent instead
20:23:34 <jeblair> flaper87: good question!  quick answer: you're being too paranoid! :)
20:23:38 <zaneb> lifeless++
20:23:45 <dhellmann> ttx: ++
20:23:58 <flaper87> jeblair: I can live with that as long as there are people like you that will bring me back to earth
20:24:00 <flaper87> :D
20:24:01 <ttx> jeblair: but that means an application process
20:24:01 <jeblair> flaper87: i think we can keep those concerns separate -- what projects use global reqs is a separate question from git namespace, etc.
20:24:10 <lifeless> flaper87: once constraints are live
20:24:11 <ttx> jeblair: which you would have to handle
20:24:16 <flaper87> jeblair: fair enough
20:24:16 <lifeless> flaper87: the risk there goes WAY down
20:24:22 <lifeless> flaper87: and we're only waiting on pip 7.1 now
20:24:28 <jeblair> lifeless: ++
20:24:30 <flaper87> lifeless: roger, that's good to here :)
20:24:31 <lifeless> flaper87: then there are two patches to merge, and we're live.
20:24:47 <fungi> for reference, not including -attic repos we have 368 in openstack.* and 313 in stackforge at present
20:24:51 <jeblair> ttx: yeah, so i think i have what i need to sythesize a new rev
20:25:01 <lifeless> [there'll be rough edges for a while of course, and we need to expand the inverse test matrix, but the core will locked down straight up]
20:25:04 <jeblair> this has been really helpful
20:25:35 <krotscheck> o/
20:27:01 <ttx> jeblair: ok, that discussion will be back
20:27:15 <jeblair> yep, look for a new rev by next week
20:28:12 <ttx> #topic Be less proscriptive about new team size/maturity
20:28:20 <ttx> #link https://review.openstack.org/193550
20:28:29 <ttx> Looks like this one already has all the votes it will ever need
20:28:38 <ttx> Objection to me merging it now ?
20:28:44 <flaper87> nope
20:28:49 <russellb> yes!
20:28:52 <russellb> ... no.
20:28:59 <russellb> just wanted to argue about something.
20:29:08 <flaper87> LOL
20:29:12 <ttx> I have the right topic for you to do that
20:29:16 <russellb> oh cool
20:29:17 <ttx> #topic Fix typo to 'Bare metal service'
20:29:21 <russellb> lolol
20:29:21 <flaper87> hahahaha
20:29:22 <ttx> #link https://review.openstack.org/194230
20:29:32 <ttx> This one sounds like it should have been fast-tracked as a typo fix, but it triggered a lively discussion
20:29:51 <russellb> this one set a new record for amount of discussion to (apparent) triviality of the patch
20:29:53 <agentle> ttx: I have a legal question in to the Foundation now
20:29:54 <ttx> agentle: around?
20:29:56 <agentle> yes
20:29:59 <dhellmann> I'm inclined to trust annegentle and the docs team on this one
20:30:01 <ttx> I'm happy to defer to Anne and/or the docs team on that one
20:30:03 <russellb> dhellmann: +1
20:30:11 <russellb> ttx: +1
20:30:15 <agentle> it's non-trivial for all the existing docs
20:30:19 <ttx> If it's a typo, it's a typo and we can merge it. If it's not a typo, they know
20:30:21 <jeblair> wow
20:30:26 <russellb> agentle: yeah, makes sense
20:30:27 <agentle> it's not a typo
20:30:29 <agentle> :)
20:30:39 <ttx> in any case there is no point in us voting or discussing it ?
20:30:40 <russellb> there's some inconsistency in the file then
20:30:53 <agentle> russellb: yeah my hope is to clear that up with set guidelines
20:30:59 <agentle> ttx: not yet
20:31:00 <russellb> yeah, appreciate that, you cleared it up in comments
20:31:30 <agentle> one point of discussion - generally speaking I do want the TC to be in the business of naming reviews, is that okay generally? Reasons not to?
20:31:45 <agentle> thinking of it for the service catalog service type discussion and microversions for example
20:32:10 <ttx> agentle: if we reuse the name in that file for service catalog, I think you're right
20:32:32 <jaypipes> agentle: ++
20:32:37 <russellb> service catalog sounds like cross project spec kind of thing
20:32:44 <agentle> I think it was either russellb or sdague who pointed out we'll have more than one service once competing solutions enter
20:32:48 <agentle> russellb: it is
20:33:04 <dhellmann> agentle: are you proposing that we register service catalog names in the governance repo?
20:33:07 <agentle> russellb: and in that spec I want to assert that "TC names" with the idea that projects.yaml is the naming source of truth
20:33:12 * dhellmann hasn't been following that discussion
20:33:25 <agentle> dhellmann: proposing that projects.yaml is the naming source of truth
20:33:34 <agentle> yeah, want to hear from you all on that ^^
20:33:40 <dtroyer> +1
20:33:52 <dhellmann> +1
20:34:02 <markmcclain> +1
20:34:07 <agentle> The caveat is the legal implications of course, but I'm seeking clarity.
20:34:11 <ttx> +1
20:34:12 <dhellmann> although I think we probably want another field other than this descriptive name for the service catalog names </bikeshed>
20:34:16 <agentle> queue indigo girls
20:34:25 <agentle> dhellmann: HEH
20:34:34 <ttx> dhellmann: I tend to agree that every time we've used the same field for two things, we regretted it
20:34:45 <jbryce> agentle: i don’t think i saw your legal question yet. what’s the high level?
20:35:08 <agentle> jbryce: sure, it's this: does capitalization of the second (or third) word in the service name have any legal implication?
20:35:13 <dhellmann> and I'm yet to be convinced that new projects shouldn't just be using their name, but I'll hold off on a final opinion until there's a formal spec put together for that
20:35:25 <agentle> jbryce: we have Block Storage and Object Storage but also Bare metal and Application catalog
20:35:34 <dhellmann> jbryce: i.e., "Bare metal" vs. "Bare Metal"
20:35:38 <jbryce> agentle: just found the ticket. i’m pretty confident the answer is no as long as you don’t pre-pend OpenStack
20:35:40 <dhellmann> heh
20:35:47 <agentle> Previously we've avoided "cognitive burden" of knowing whether to capitalize say the V in Key-Value by saying only the first letter should be capitalized.
20:36:24 * dhellmann imagines a world of project names in ALL CAPS for the same reason
20:36:25 <agentle> jbryce: so then I'll just have to decide whether Storage set us up for a lifetime of capitalization rules :)
20:36:45 <agentle> I still don't know whether it's Key-value Store or Key-Value Store even with capitalization rules
20:36:54 <ttx> dhellmann: but then people think it's an acronym. Like OSLO
20:37:01 * ttx trolls
20:37:05 <agentle> SNORT
20:37:09 <flaper87> lol
20:37:14 <dhellmann> agentle: which project is that?
20:37:20 * zaneb is thoroughly sick of people shouting HEAT at him
20:37:23 <ttx> dhellmann: MagnetoDB
20:37:24 <dims> LOL
20:37:28 <agentle> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1129
20:37:38 <agentle> HEAT OSLO NOVA SWIFT LOL
20:37:47 <ttx> zaneb: I never knew what it stood for.
20:37:59 <ttx> ...
20:38:04 <zaneb> ttx: don't you start
20:38:05 <jgriffith> agentle: you mean lOl I think
20:38:19 <agentle> Sadly, my technical editor at work wants Application Catalog and Bare Metal :)
20:38:38 <ttx> agentle: anything else on that one ? Sounds like you have it under control
20:38:40 <dhellmann> can we "fix" them all in one patch?
20:38:45 <agentle> dhellmann: yeah
20:38:50 <agentle> dhellmann: then go to the docs, sigh :)
20:38:53 <agentle> ttx: I think so
20:38:59 <agentle> thanks for bringing it up :)
20:39:15 <ttx> OK, the next topic on the agenda was the Akanda proposal, but it was very recently WIPped
20:39:23 <ttx> while they address the trademark / use company name as project name question
20:39:23 <sarob> yup
20:39:32 <ttx> So I propose we skip it and reconsider it when it's final and un-WIPped
20:39:39 <sarob> good for me
20:39:43 <lifeless> 101 clearly.
20:39:48 <dhellmann> agentle: let's talk offline about ways to make substitutions like that simpler in rst
20:39:50 <lifeless> Then we don't need to worry about capitalisation
20:39:58 <ttx> Let me see if we can get another patch to replace it on the agenda
20:40:08 <maishsk> I just hope that we do not turn into the little v vs. the big V debate (from the vSphere world)
20:40:17 <russellb> adding neutron to compute starter kit?
20:40:18 * maishsk ducks and runs for cover… ;)
20:40:21 <ttx> https://review.openstack.org/#/c/195771/ sounds like a good candidate
20:40:34 <russellb> ah yes, that one first
20:40:41 <jeblair> Topic       lastday
20:40:42 <jeblair> :(
20:40:44 <ttx> since it was proposed in time --  any objection to discussing it now ?
20:40:59 <jeblair> if we don't approve it, does jogo have to stay around?
20:41:15 <russellb> props for doing real work until the end :)
20:41:24 <ttx> changing the world until the last day
20:41:31 <jeblair> okay, actually, i think that it was intentional
20:41:42 <ttx> I'll take that as a yes
20:41:43 <ttx> #topic Fix up the compute starter kit tag
20:41:52 <ttx> #link https://review.openstack.org/#/c/195771/
20:42:08 <jeblair> i thought that the intent was to have real discussion on the application?
20:42:08 <ttx> So this patch basically applies the tag to the initial set of projects
20:42:11 <russellb> yeah, i think we knew it hadn't been applied yet, because there was potential follow-up discussion yet, especially neutron
20:42:18 <russellb> but i think the initial set of projects here has consensus in any case
20:42:20 <russellb> so +1 from me
20:42:27 <ttx> It is also use as a base for mordred's patch proposing neutron addition
20:42:33 <mordred> yup
20:42:34 <russellb> and the tag name seems fine
20:42:37 <jeblair> at least, i think that some questions were deferred with "that can be dealt with in tag application"
20:42:39 <flaper87> yeah, I'm good with that too
20:42:40 <ttx> which should make for an interesting discussion, but next week
20:42:49 <ttx> jeblair: right
20:42:55 <russellb> for some definition of interesting
20:43:10 <ttx> jeblair: we said that the tag definition still needed to be applied
20:43:46 <ttx> and that we could rediscuss where it applies at that point. But I like the idea to iterate from the initial set proposed in the definition
20:43:56 <jeblair> k, just mostly wanted to make the point that i don't think this was an oversight, and that we are expected to apply discretion to this :)
20:44:02 <zaneb> I thought we had explicitly endorsed a tag starting with compute: during the previous discussion
20:44:17 <russellb> if anyone would like to talk some more about current neutron state, i'm happy to chat out-of-meeting, if that'd help develop opinions on this neutron thing, i've been trying to follow much more closely lately
20:44:50 <ttx> zaneb: I don't remember that... the prefix is a category thing, so compute: wouldn't make that much sense there ?
20:45:13 <russellb> yeah, starter-kit makes sense as the category
20:45:15 <zaneb> maybe it should just be compute-starter-kit?
20:45:16 <ttx> We have majority at this point
20:45:29 <russellb> or i guess it could be even more general, "group:compute-starter-kit"
20:45:30 <russellb> but meh
20:45:46 <russellb> this wfm
20:45:53 <ttx> zaneb: that is an option, but that can be proposed/discussed as a separate patch
20:46:18 <ttx> Alright, I'll approve this in 30sec, get tyour last votes in
20:47:09 <ttx> ok done
20:47:16 <ttx> #topic Workgroup reports
20:47:22 <ttx> * Project Team guide workgroup
20:47:30 <ttx> No progress since last week. Was focused on liberty-1, should make more progress this week
20:47:37 <ttx> Any suggestion on where we should publish it ?
20:47:46 <flaper87> I have a WIP patch that I'd be happy to start getting feedback on
20:47:49 <flaper87> (if no one has)
20:47:54 <lifeless> russellb: I'd like to do that.
20:47:55 <flaper87> and I'm sorry for being late there
20:47:58 <lifeless> russellb: (chat)
20:48:25 <ttx> jeblair: IIRC you had an idea on where we should publish it
20:48:27 <agentle> docs.openstack.org/project-team-guide? (that's original)
20:49:01 <jeblair> ttx: i can't remember :)  i like agentle's idea
20:49:18 <ttx> The infra guide is at docs.openstack.org/infra rather than docs.openstack.org/infra-guide
20:49:30 <agentle> ttx: they should rename it :)
20:49:31 <ttx> blue pain t on my bikesheds
20:49:33 <agentle> I kid!
20:49:38 <agentle> red
20:49:46 <jeblair> yeah, we grabbed a subdir to hold all kinds of infra stuff
20:50:04 <jeblair> and by grabbed, i believe i mean, politely asked agentle for permission :)
20:50:12 <agentle> jeblair: heh
20:50:17 <ttx> jeblair: do you plan to work on the publication jobs ?
20:50:41 <jeblair> ttx: can do; let's just #info the location when we finish bikeshedding
20:50:46 <ttx> I'll do a complete review of the current chapters to check we have enough to start talking about it
20:51:34 <ttx> Any objection to docs.openstack.org/project-team-guide ?
20:51:49 <flaper87> none from me
20:51:57 <dhellmann> wfm
20:51:57 <agentle> ttx: as long as you promise never to rename to program-team-guide
20:52:00 <agentle> pinky swear?
20:52:05 <ttx> #agreed Project team guide to be published to docs.openstack.org/project-team-guide
20:52:10 <ttx> promise!
20:52:15 <ttx> * Communications workgroup
20:52:24 <ttx> agentle, flaper87: your turn
20:52:29 <agentle> any movement on M name?
20:52:38 <agentle> and really that doesn't come from "us" per se
20:52:46 <agentle> do we need a blog post this week?
20:52:47 <mordred> I got feedback from lsell
20:53:02 <ttx> agentle: lots of things approved, but not exactly exciting stuff
20:53:02 <agentle> oh and I keep forgetting to tweet
20:53:15 <mordred> they are still working on it
20:53:20 <agentle> mordred: okay
20:53:31 <agentle> I think we could wait another week for compiled excitement
20:53:36 <flaper87> not sure if it's worth working on one this week
20:53:38 <jbryce> agentle: summary is the top 2 choices were quickly tm-ed out of contention. 3rd looks promising, waiting for detailed search
20:53:46 <agentle> jbryce: ok thanks for that
20:53:51 <flaper87> agentle: ++
20:53:59 <agentle> flaper87: mind meld
20:54:00 <lifeless> agentle: surely we can't 'go' that long without compilation ? :) <boom-tish>
20:54:15 <ttx> * Other workgroups
20:54:23 <agentle> lifeless: lol
20:54:31 <ttx> Any progress in other workgroups ?
20:54:38 <lifeless> architecture still hasn't gotten off the group
20:54:40 <lifeless> ground
20:55:05 <lifeless> thats on me and markmcclain to make a timeslice and get things really rolling. I've been focusing on getting the constraints cross-project omgosh stuff off my plate
20:55:06 <ttx> Once the peak of excitement is reached on project-team-guide is reached and I enter the valley of desillusion, I might help out there
20:55:12 <agentle> heh
20:55:25 <ttx> #topic Open discussion
20:55:28 <russellb> agentle: which docs rae you referring to on https://review.openstack.org/#/c/196438/ ?
20:55:34 <ttx> There was a post asking for volunteers for Travel support program
20:55:38 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2015-June/000998.html
20:55:42 <ttx> Anyone interested ?
20:56:02 <agentle> russellb: I haven't seen a coherent "this is how you do port assignment in neutron to make it like nova-net" nor a "how to migrate upgrade"
20:56:02 <russellb> ttx: i replied off list that i'm willing to do it
20:56:04 <dhellmann> I replied off list
20:56:23 <jbryce> all you have to do is agree to house a few summit attendees in your room! = )
20:56:23 <russellb> agentle: migration/upgrade isn't relevant for a starting point tohugh
20:56:26 <agentle> russellb: but it's possible it's there and I've missed it so need links
20:56:39 <dhellmann> jbryce: as long as they aren't in my carry-on
20:56:41 <russellb> agentle: and the first part, i'm not sure i get, that's probably the most fundamental part of the neutron API
20:56:42 <agentle> russellb: mm
20:56:54 <russellb> creating a port on a network?
20:57:03 <ttx> jbryce: I learned that in Japan you pay hotel rooms by occupancy and not per room, which if true menas you wouldn't win a lot
20:57:17 <russellb> there has been discussion about provider networks, but that seems covered pretty nicely on http://docs.openstack.org/networking-guide/ scenarios 4a and 4b
20:57:37 <mordred> 4a and 4b are great
20:58:06 <russellb> i'd encourage anyone who hasn't seen that guide to check it out
20:58:15 <mordred> agentle: also, fwiw, shade makes nova-net look like neutron where possible
20:58:16 <ttx> On the travel support program I'll reach out to Shari and check she has enough, and if not do another round of volunteer fishing
20:58:31 <mordred> agentle: in the instances where we're forced to interact with nova-net
20:58:57 <russellb> shade?
20:59:01 <mordred> agentle: might or might not be a useful collection of data for someone in terms of what dicts look like
20:59:13 <agentle> russellb: yeah networking guide is great so where does it say "if you just want a network do this for your users"
20:59:14 <ttx> clouds make shade, shade makes cloud
20:59:24 <mordred> russellb: library that wraps python-*client with business logic to hide all the cloud differences
20:59:29 <russellb> mordred: nice
20:59:34 <mordred> russellb: being used in upstream ansible openstack modules as well as nodepool
20:59:39 <russellb> agentle: depends on the networking model you want to use
20:59:40 <agentle> I remember a note in the etherpad, mordred you may have pointed it out, that people didn't know "oh don't worry about running out of IP addresses, you just do this thing"
20:59:43 <ttx> One minute warning. Anything else, anyone ?
20:59:52 <russellb> the nova-network equivalent is documented nicely in the provider networks part
20:59:54 <agentle> russellb: so we need to say "use this scenario for a match with nova-net"
20:59:57 <russellb> the "give me a network" stuff is about tenant networks
21:00:02 <russellb> which is something nova-network doesn't have
21:00:08 <russellb> well, not like neutron has it anyway
21:00:10 <agentle> russellb: ok, put a link in that review and I'm good to go once I look
21:00:16 <russellb> it's different / more than nova-net
21:00:22 <ttx> Alright, time is up
21:00:34 <agentle> oh yeah I'm up next!
21:00:37 <ttx> Thanks everyone, I think we resorbed our backlog in one meeting.
21:00:41 <flaper87> o/
21:00:42 <ttx> #endmeeting