21:03:47 <ttx> #startmeeting crossproject
21:03:48 <openstack> Meeting started Tue Jan 27 21:03:47 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:51 <openstack> The meeting name has been set to 'crossproject'
21:03:53 <morganfainberg> make people submit ideas at the summit, tally things up at the end.
21:03:55 <morganfainberg> :P
21:03:56 <ttx> Our agenda for today:
21:04:00 <ttx> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting
21:04:11 <ttx> sigmavirus24: around?
21:04:30 <ttx> oh I see you above
21:04:37 <sigmavirus24> I am
21:04:39 <ttx> #topic Cross-project DevRef akin to Nova's (@sigmavirus24)
21:04:48 <ttx> #link http://docs.openstack.org/developer/nova/devref/development.environment.html
21:04:54 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054837.html
21:05:01 <sigmavirus24> So we discussed this on the mailing list a bit already (thank you ttx)
21:05:02 <ttx> sigmavirus24: I'll let you introduce the topic
21:05:24 <sigmavirus24> The basic idea is to have a cross-project reference of the basic requirements to begin developing with/on any of the projects
21:05:37 <sigmavirus24> Then have a way for each project to list additional dependencies and system setup
21:05:43 <lifeless> sdague: haypo was working on it
21:06:15 <sigmavirus24> At this point, what we could use are people willing to help with each project's (sub?)reference and to get the base document started. Also guidance as to where this should live
21:07:26 <asalkeld> sigmavirus24, openstack-manual ?
21:07:40 <mestery> asalkeld: ++, that's a good spot.
21:07:43 <eglynn> so is the idea that we list out the super-set of all setup required to develop on *any* project?
21:07:56 <sigmavirus24> eglynn: right. Most projects have common system dependencies
21:08:11 <eglynn> sigmavirus24: sounds reasonable
21:08:12 <asalkeld> and i'd assume we would have some hooks so we could have some differences in-tree?
21:08:24 <annegent_> I think it could live in openstack-manuals but the audience is contrib devs so openstack-manuals isn't for that group. I'd say start a new repo
21:08:32 <sigmavirus24> annegent_: that's what I thought
21:08:42 <dhellmann> anteaya: where is the infra-manual being published?
21:08:46 <annegent_> like the infra-manual is a separate repo
21:08:53 <sigmavirus24> asalkeld: I think the idea would be to have some sub-sections or separate pages for each individual project
21:08:54 <annegent_> dhellmann: docs.openstack.org/infra-manual
21:09:01 <anteaya> docs.openstack.org/infra/manual
21:09:05 <dhellmann> annegent_: thanks
21:09:06 <annegent_> sorry http://docs.openstack.org/infra/manual/
21:09:07 <dhellmann> anteaya: thanks :-)
21:09:07 <annegent_> heh
21:09:12 <anteaya> :)
21:09:22 <asalkeld> sigmavirus24, i'd rather you link to project pages
21:09:29 <dhellmann> there is a developer guide in the infra manual: http://docs.openstack.org/infra/manual/developers.html
21:09:32 <dhellmann> let's add to that
21:09:34 <annegent_> sigmavirus24: figure out how to include content from separate repos while you're at it :)
21:09:41 <asalkeld> central docs are more work to add to
21:09:53 <dhellmann> and let's not put project-specific stuff in the projects because as a new dev OMG that's a pain to flip back and forth
21:09:55 <sigmavirus24> annegent_: hm. I have an instinct on how to do that but have never tested it =P
21:10:06 <dhellmann> and really, if our instructions aren't "run devstack once" then meh
21:10:06 <annegent_> sigmavirus24: try it, you'll like it, then show me how
21:10:09 <asalkeld> we already have docs: http://docs.openstack.org/developer/heat/getting_started/index.html
21:10:10 <sigmavirus24> dhellmann: yeah that was a worry of mine
21:10:22 <asalkeld> just link to those (and we remove common stuff)
21:10:27 <annegent_> dhellmann: it's really about concepts and then troubleshooting
21:10:46 <eglynn> would we need a volunteer per-project-per-distro to validate the setup?
21:10:48 <eglynn> (e.g. one who normally develops ceilo on fedora20, another for ceilo/trusty etc.)
21:11:10 <sigmavirus24> eglynn: yeah that's the part that Nova's DevRef doesn't handle
21:11:18 <eglynn> k
21:11:22 <sigmavirus24> And that may be harder to maintain
21:11:36 <dhellmann> annegent_: ok, but if we have instructions for doing something and a tool that does it, they're going to diverge pretty quickly
21:12:06 <annegent_> dhellmann: I think we agree :)
21:12:14 <dhellmann> annegent_: huzzah! :-)
21:12:35 <annegent_> per distro is not easy, take it from the install guide experience
21:13:12 <sigmavirus24> I've heard stories of the per-distro problems in the install guide
21:13:32 <annegent_> sigmavirus24: it ain't easy
21:13:48 <sigmavirus24> dhellmann: but there's also the difference of: "install these dependencies system wide and then get going" and "run devstack for 40 minutes then get started"
21:14:18 <sigmavirus24> If we're going to tell people to use devstack to set up their systems for development, we should probably make it easier to install the system deps without running ./stack.sh
21:14:24 <dhellmann> sigmavirus24: I suppose.
21:14:33 <morganfainberg> maybe the right answer is to keep the basic starter docs in devstack purview.
21:14:37 <ttx> I fail to feel disturbance in the Force. Does that mean there is mostly consensus on this topic and we should spend our time on more conflictual issues ?
21:14:45 <fungi> maybe that's where the docker-oriented dev/devstack environments have a leg up. start this in a container, then hack
21:14:50 <morganfainberg> since devstack needs to know how to do all of that anyway
21:14:50 <dhellmann> sigmavirus24: that's a good idea, maybe a separate script in the devstack repo?
21:14:55 <sigmavirus24> dhellmann: yeah
21:14:56 <morganfainberg> dhellmann, ++
21:14:57 <sigmavirus24> I'm all for that
21:14:59 <notmyname> what if, instead of one (base) document that describes how to set up a dev environment, we instead had one template for how these look and then leave them to the individual projects?
21:15:38 * dhellmann pictures only slightly less confusion than we have now
21:15:55 <eglynn> if not explicitly per-distro, then at least e.g. "yum install libffi-devel (or the equivalent package for your distro)"?
21:16:00 <asalkeld> imho if this is docs on how to run devstack, the docs should just be in devstack
21:16:02 <annegent_> I wish reed were around to weigh in. He fields all kinds of questions about devstack
21:16:33 <fungi> not long ago i looked at the degree to which contributing.md et cetera diverged across our projects. basically they mostly fork from whatever the satte is in the cookiecutter repo and then head off in their own individual directions
21:16:37 <dhellmann> most of these instructions shouldn't be different between the projects, right? "Here's how to find the list of packages to install" or "Here's the tool to install the packages"
21:16:42 <dhellmann> "here's how to run tests"
21:16:47 <annegent_> but it's not just devstack, it's a dev environment, building docs, and running tests.
21:16:47 <dhellmann> "here's how to run the debugger"
21:16:50 <eglynn> this is not just devstack, amiright? ... also folks who want to just run "tox -epy27" to run units
21:16:55 <dhellmann> that should all work the same, with only the service names changing
21:17:00 <morganfainberg> devstack feels like the right place for something like this instead of trying to keep data in now (how many projects?) in sync or even adding just 1 more place, devstack and wherever it is now and then this new place
21:17:02 <annegent_> heh. you type faster
21:17:04 <sigmavirus24> eglynn: right
21:17:07 <morganfainberg> it seems like the data will never be in sync.
21:17:20 <sigmavirus24> == morganfainberg
21:17:21 <dhellmann> eglynn: on most projects, you need system packages for the python requirements to install
21:17:33 <sigmavirus24> libmysql++, libssl, etc. are all necesary
21:17:33 <eglynn> dhellmann: yep, exactly
21:17:44 <fungi> and the names of those packages differ across distro families and releases
21:17:45 <sigmavirus24> or required to different degrees
21:18:00 <eglynn> fungi: precisely my thought above
21:18:01 <fungi> name and count of packages in some cases
21:18:08 <dhellmann> eglynn, fungi : and so it is simpler to tell people to use a tool to install them than to write directions for doing it all differently
21:18:24 <fungi> (e.g. some distros split out packages which others keep more monolithic)
21:18:37 <dhellmann> currently, the best tool is devstack, but I do like the idea of splitting that feature out
21:18:43 <fungi> dhellmann: i have no idea which is easier honestly. neither is trivial
21:18:44 <eglynn> dhellmann: yep, great if someone is willing to maintain such a tool
21:18:52 <eglynn> (standing alone from devstack)
21:18:59 <morganfainberg> if devstack used that tool to install
21:19:07 <dhellmann> morganfainberg: right
21:19:10 <morganfainberg> i think it would make it required to keep up to date
21:19:17 <asalkeld> https://github.com/openstack-dev/devstack/tree/master/files ?
21:19:20 <morganfainberg> rather than "we hope it stays in sync"
21:19:24 <dhellmann> asalkeld: right
21:19:30 <sigmavirus24> morganfainberg: I think that was that was what I imagined for the tool
21:19:40 <fungi> lifeless started on his bindep project a couple years back now, to try to provide a structured mechanism for declaring these sorts of dependencies across distros
21:19:44 <sigmavirus24> I should have verbalized that though :)
21:19:56 <fungi> might be a good place to try to incorporate that sort of logic
21:20:29 <asalkeld> so doesn't devstack automatically installing this stuff?
21:20:53 <dhellmann> asalkeld: it does, but the request was for a tool that doesn't do all of the other things devstack does
21:20:53 <asalkeld> why are we documenting it as a manual step?
21:20:55 <ttx> the anvil stuff from harlowja had a few ways to encode deps in a distro-agnostic way too
21:20:55 <fungi> #link http://git.openstack.org/cgit/stackforge/bindep
21:20:55 <sigmavirus24> yes. splitting that part out of devstack so you don't have to run ./stack.sh is what I imagine will be the best way of moving this forward
21:21:01 <dhellmann> asalkeld: my point exactly :-)
21:21:32 <asalkeld> really? odd
21:21:38 <ttx> Hmm, obviously this requires more discussion, but we can't dedicate all the meeting to that
21:21:39 <sigmavirus24> mriedem was the one to suggest this first in glance so this is why it's come up
21:21:43 <sigmavirus24> right.
21:21:49 <harlowja> https://github.com/stackforge/anvil/blob/master/conf/distros/redhat.yaml if people care :-P
21:21:54 <sigmavirus24> ttx:  feel free to move on. Maybe we'll get more responses on the ML now =P
21:21:55 <ttx> How about someone picks up the thread and continues the discussion there
21:21:55 <dtroyer_zz> fwiw. tools/install_prereqs.sh exists in devstack to do a lot of the system deps
21:22:12 <ttx> sigmavirus24: triggering interest in ML thread is one of the goals of this meeting indeed
21:22:26 <ttx> OK, let's move on
21:22:32 <dhellmann> dtroyer_zz: cool
21:22:39 <ttx> Please followup on the thread if you care
21:22:44 <ttx> #topic Avoiding private symbols in Oslo libraries (dhellmann)
21:22:48 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054810.html
21:22:51 <ttx> dhellmann: around?
21:22:59 <dhellmann> #link https://review.openstack.org/#/c/150118/
21:23:00 <ttx> This feels more and more like Lightning Talks
21:23:08 <dhellmann> I wanted to raise this mostly to make sure you had all seen the thread.
21:23:11 <bknudson> we've all done it -- used private symbols
21:23:38 <dhellmann> After we're done with the namespace package moves, we're not going to hold up releases of oslo libs because of unit test breakages in other projects.
21:23:42 <bknudson> sometimes because they were that way from oslo-incubator days
21:24:21 <asalkeld> dhellmann, that sounds fine
21:24:22 <dhellmann> We'll work with everyone to add fixtures and other APIs as needed as we continue graduations, but for existing stuff we're going to keep moving ahead with cleanups and fixes.
21:24:37 <ttx> dhellmann:  that sounds fair
21:25:24 <dhellmann> That's all I had, unless anyone has questions about it.
21:25:59 <eglynn> dhellmann: not going to hold up releases of oslo libs because of unit test breakages in other projects, where those breakages are caused by usage of oslo private symbols?
21:26:08 <dhellmann> eglynn: yes, that's right
21:26:17 <eglynn> (i.e. as opposed to being caused by say an API contract change)
21:26:21 <eglynn> coolness :)
21:26:23 <ttx> other questions on that ?
21:26:38 <notmyname> any migration plan?
21:26:43 <dhellmann> notmyname: migration?
21:27:15 <notmyname> just tell projects to stop and make them change? or is there a plan for supporting stuff currently in use by published libraries?
21:27:42 <dhellmann> notmyname: symbols already clearly marked as private are off-limits. New symbols will be clearly marked.
21:27:47 <notmyname> ok
21:27:59 <ttx> ok, moving on
21:28:09 <ttx> #topic Discuss the importance of getting cross-project reviews of guidelines and how to best go about getting those reviews for the API Working Group (etoews)
21:28:10 <bknudson> it's usually pretty easy to change the test to use public symbols instead.
21:28:15 <ttx> etoews: o/
21:28:19 <etoews> hi
21:28:35 <etoews> in case anyone isn't familiar with our working group yet...
21:28:38 <etoews> #link https://wiki.openstack.org/wiki/API_Working_Group
21:28:40 <ttx> Example guidelines @ https://review.openstack.org/#/c/145579/
21:29:13 <etoews> ya. so that one turned out reasonably well so far.
21:29:27 <asalkeld> etoews, is this what our cross project liaison should be doing?
21:29:32 <etoews> right
21:29:52 <bknudson> looks like that one has a lot of reviews and from the right people.
21:29:55 <etoews> the wg also needs to do a better job of reaching out to the CPLs
21:30:08 <etoews> bknudson: for that one yes.
21:30:18 <eglynn> is this voting scheme in force? https://review.openstack.org/#/c/131358/6/doc/source/process.rst
21:30:23 <etoews> but then look at https://review.openstack.org/#/c/141229/
21:30:38 <eglynn> "Once the matter has been discussed there should be no more than 20% (of votes cast) -1 votes."
21:30:50 <ttx> One question that comes to mind is should that type of guidelines be retrofitted into an openstack-specs, or do we need two repositories ?
21:30:52 <etoews> eglynn: yep. that merged. http://specs.openstack.org/openstack/api-wg/process.html
21:31:21 <etoews> ttx: i think one repo for the time being
21:31:41 <dhellmann> ttx: using the specs repo feels fine
21:32:06 <morganfainberg> i like the spec repo as a place for this
21:32:07 <dhellmann> we're doing something similar with oslo policies: https://review.openstack.org/#/q/status:open+project:openstack/oslo-specs+branch:master+topic:policy,n,z
21:32:11 <ttx> dhellmann: it's using the  openstack/api-wg repo for now
21:32:51 <ttx> basically, this repo serves both to help draft the guidelines and get it out to be implemented
21:33:01 <dhellmann> ttx: hmm, I hadn't noticed that
21:33:11 <ttx> while we do some of the latter already in openstack-specs
21:33:11 * dhellmann doesn't like the new gerrit UI :-/
21:33:19 <ttx> hence my question on the potential duplication
21:33:24 <fungi> i lobbied to just use the openstack/specs repo for it originally, but was in the minority
21:33:44 <eglynn> can we clarify where these guidelines lie on the spectrum ranging from "friendly advice" to "hard mandate"?
21:33:53 <ttx> fungi: I still think the workgroup needs a place to hack and draft their docs
21:33:57 * eglynn fears that "friendly advice" tends to be respectfully ignored
21:34:07 <fungi> ttx: yep, that was a fair counterargument
21:34:13 <dhellmann> I thought the api-wg repo was going to be for them to draft proposals, but they wouldn't be applied until they were approved in the specs repo. That feels like we're adding extra overhead, now that we have used the specs repo a bit
21:34:19 <ttx> I'm just wondering if making them stay forever in api-wg doesn't limit the reach/audience needed for the second step
21:34:37 <ttx> dhellmann: agreed, just checking if that's still the plan
21:34:41 <etoews> eglynn: at this point they are guidelines, not hard mandate.
21:34:55 <ttx> basically I saw the CLI sort thing and ignored the API sort thing
21:35:32 <etoews> hmmmm...sounds like the specs repo would give us more viz
21:35:39 <ttx> etoews: do you plan to push them more as mandates ? In which case you would use the specs repo ?
21:36:13 <ttx> I guess if they stay "recommendations" or "guidelines" they could still live in a specific repo
21:36:34 <etoews> so far the way most reviews have worked out is that everytime we use the word "must" in a guideline, someone comments to change it to "should"
21:36:44 <ttx> heh
21:36:54 <ttx> rings a bell
21:37:04 <etoews> even if they were mandated, that "should" give people the wiggle room they want/need.
21:37:13 <notmyname> s/should/may/
21:37:14 <etoews> it's basically the language of rfcs
21:37:56 <etoews> i'm all for more visibility though. that's why i'm here.
21:38:15 <eglynn> at one point there was a suggestion that the TC would add some weight to these "recommendations" by explicitly adding their imprimatur
21:38:15 <ttx> OK, so we have two options for more viz
21:38:23 <eglynn> ... is that still the plan?
21:38:40 <ttx> one is just to rpeach that CPLs and PTLs and everyone else should weigh in on api-wgh proposed changes
21:38:47 <ttx> preach*
21:38:47 <etoews> eglynn: see #5 of http://specs.openstack.org/openstack/api-wg/process.html
21:39:09 <ttx> two is to turn those at some point into API recommendations that would be proposed as openstack-specs
21:39:16 <eglynn> etoews: a-ha, cool, thanks
21:39:20 <ttx> (and use api-wg to draft the doc)
21:39:42 <notmyname> how in the world is that reasonable or scalable with a bit-tent openstack project?
21:39:49 <notmyname> *big
21:39:58 <etoews> ttx: those are the option i see
21:40:07 <ttx> notmyname: api recommendations ? or openstack-specs ?
21:40:39 <ttx> etoews: any preference ?
21:40:52 <notmyname> ttx: the api recommendations along the should to must range. basically finding a One True API that works across all of these projects
21:40:53 <etoews> i don't want to speak for the whole wg.
21:41:13 <etoews> let me take this back to them. we have a meeting on thursday.
21:41:18 <ttx> etoews: maybe bring back the two options to them ?
21:41:20 <ttx> ok
21:41:39 <etoews> i'll update the cross-project meeting next week.
21:42:05 <ttx> etoews: sounds good
21:42:39 <ttx> notmyname: I don't think they are up to defining a "One True API", mostly about suggesting that the details like sorting are implemented in a coherent way
21:42:58 <etoews> ttx: +1 and consistent too
21:43:04 <ttx> which sounds valuable, especially as we add more projects
21:43:24 <ttx> ok, one or two more topics to cover
21:43:57 <ttx> moving on -- if more complaints about the APi WG goals, that should be raised as a specific thread I think
21:44:02 <ttx> #topic Progress (or lack thereof) on providing default config files
21:44:10 <ttx> in our Dec 16 meeting we discussed the best way to provide "default" config files for projects
21:44:23 <ttx> There were lots of solutions proposed, but not real clear single roblem we were trying to solve
21:44:29 <ttx> The outcome was to push the discussion to the operators ML to get a clearer sense of the problem we need to solve
21:44:33 <fungi> yep, and i summarized the discussion on the ops ml
21:44:33 <ttx> and/or start a cross-project spec
21:44:39 <ttx> We also scheduled a status update before end of January, so here we are...
21:44:39 <fungi> #link http://lists.openstack.org/pipermail/openstack-operators/2014-December/005742.html
21:44:50 <ttx> fungi: do you have some summary to share ?
21:44:56 <fungi> that thread sort of petered out without any solid direction
21:45:29 <fungi> i also talked with fifieldt a little and his take was that from the operators he talks to, they wanted config files in git repos
21:45:38 <fungi> full stop
21:45:49 <ttx> would you say it failed to reach the required level of interest on that list ?
21:45:55 <fifieldt> not at all :)
21:46:03 <fungi> which someone in the ops community just started doing
21:46:03 <ttx> or that the Christmas break made it drown ?
21:46:08 <fifieldt> it's that the options as presented were ill formatted for the audience, ttx
21:46:11 <fungi> #link http://lists.openstack.org/pipermail/openstack-operators/2015-January/005981.html
21:46:26 <asalkeld> well we could go back to generating the config's - just not gating on the results?
21:46:39 <ttx> fifieldt: the effort is stalled again -- what's the best way to make progress there ?
21:46:41 <fungi> right, i can grasp that we presented technical options to operators and the implication i guess is that they're non-technical creatures?
21:47:01 <dhellmann> asalkeld: the options available to a deployment depend on the versions of libraries installed *at that deployment* and not just on the application
21:47:07 <fifieldt> not technical vs non technical - just "don't care about implementation details" :)
21:47:32 <asalkeld> dhellmann, we provide the global requriements
21:47:36 <fungi> okay, so they don't care enough about how we solve it to tell us what specifically they need, but care enough to complain when we don't provide what they need?
21:47:42 <dhellmann> asalkeld: with ranges of versions
21:47:44 <asalkeld> doubt they really vary that much
21:47:46 <morganfainberg> but the view was they want sample configs in git [regardless of how it gets there]?
21:47:55 <asalkeld> seems like a slim arguemnent
21:47:58 <fifieldt> * A git repository that has raw, sample configs in it for each project
21:47:58 <fifieldt> that will be automagically updated
21:47:59 <fifieldt> * Raw configs distributed in the tar files we make as part of the release
21:48:06 <fifieldt> that's basically it
21:48:20 <ttx> fifieldt: that's an OR or an AND ?
21:48:25 <fifieldt> and
21:48:29 <ttx> (non technical question)
21:48:34 <ttx> :)
21:49:03 <ttx> fungi: I haven't followed the thread, but is fifieldt's description something they clearly voiced ?
21:49:16 <dhellmann> fifieldt: why do they want these things in git?
21:49:21 <morganfainberg> ttx, i think i see that is the general view.
21:49:28 <morganfainberg> ttx, i'm skimming the thread archive now
21:49:50 <fungi> ttx: the git repository idea wasn't really championed in that thread, but i get the impression that not all operators who have a vested interest are on that ml
21:49:51 <ttx> fungi: is that a description of needs we can act on and propose a strawman solution for ?
21:50:02 <fifieldt> dhellmann, its raw, easy to use from the filesystem, diffable, changes can be tracked
21:50:03 <bknudson> I use the sample config file in git every few days.
21:50:17 <fifieldt> so this is just my interpretation from talking with a ton of ops
21:50:26 <dhellmann> fifieldt: ok, tracking changes at least makes sense
21:50:37 <fungi> ttx: i pointed out on the ml that the git repo solution is one that anyone could provide without necessarily needing us to solve that, and it seems that's happened already
21:51:24 <fifieldt> indeed, and it seems to indicate that that method is an acceptable solution
21:51:33 <fifieldt> so p[ulling that up so its visible could be a next step
21:51:35 <ttx> fifieldt: would you mind reheating the thread by summarizing the needs like you just did ?
21:51:44 <ttx> Then we can discuss implementation on the other side
21:51:49 <fifieldt> it's been on my todo list, ttx :)
21:51:59 <ttx> ok, potential progress again!
21:52:08 <fungi> so straw man proposal would be to let the operator community continue to scratch its itch with the git repo, and possibly still include sample configs in tarballs (though as jeblair pointed out that does complicate sdist creation)
21:52:35 <ttx> fungi: we can discuss the feasibility of that part if we know that's what they want
21:52:41 <fungi> agreed
21:52:45 <fifieldt> I think there'd be a preference for the git repo thing to be produced by upstream
21:52:50 <fifieldt> rather than in some random personal repo
21:53:02 <fungi> it's a solution they can contribute though
21:53:02 <ttx> so let's wait for fifieldt to come back to us with a clear need like he just outlined
21:53:10 <fungi> since they've worked out the specifics
21:53:10 <fifieldt> what do you need, ttx ?
21:53:18 <fifieldt> just post those two bullet points to the list?
21:53:19 <fungi> and we can just run it
21:53:29 <dhellmann> fungi: ++
21:53:30 <ttx> fifieldt: and ask if that would be a consensual solution
21:53:41 <ttx> if we could provide a technical solution for that
21:53:58 * fifieldt isn;'t sure why it has to be me writing this email, but ok :)
21:54:12 <ttx> fifieldt: well, you authored this brilliant summary
21:54:42 <ttx> so we blame you now
21:55:12 <ttx> time for one more quick thing
21:55:14 <fifieldt> the things I get up to at 5am :)
21:55:19 <ttx> #topic openstack-specs discussion
21:55:20 <fungi> we've been trying to get some leadership from the operator community to push this to a conclusion so it doesn't fester
21:55:32 <ttx> * CLI Sorting Argument Guidelines (https://review.openstack.org/#/c/145544/)
21:55:37 <ttx> This one has no clear opposition so far
21:55:41 <ttx> Affected projects are Glance, Cinder, Ironic and Neutron. We have Cinder PTL +1 so far
21:55:46 <ttx> Missing mestery approval, (nikhil_k and devananda +1ed an earlier version)
21:55:55 <ttx> Once we have that (hopefully this week) I think we'll move to TC rubberstamping, unless there is a new objection raised
21:56:02 <mestery> ttx: I'll re-examine that right now.
21:56:10 <ttx> So if you care and haven't expressed your opinion yet, now is the time to do so
21:56:25 <ttx> We'll discuss TRACE next meeting
21:56:31 <ttx> #topic Open discussion & announcements
21:56:39 <ttx> We had 1:1 syncs today, one week before kilo-2 deadline
21:56:43 <ttx> Logs at:
21:56:48 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2015/ptl_sync.2015-01-27-07.58.html
21:57:02 <ttx> We also expect a Swift release (2.2.2) next week
21:57:19 <ttx> Last meeting in the middle of the netspit I asked if anyone would be interested in chairing a future cross-project meeting. I'm fine rotating on that job :)
21:57:35 <ttx> Ping me if interested
21:57:36 <fungi> i'll be pushing this week to switch projects which are successfully gating on python 3.3 to switch en-masse to 3.4 where possible, so keep an eye out for that (i'll announce on the dev ml too)
21:57:48 <ttx> Anything else, anyone ?
21:57:49 <adam_g> Just a friendly reminder, the stable/juno branches will freeze this thursday jan 29th in preparation for the 2014.2.2 next week.  Please get any new backports up for review soon and ping zul if you have any post-freeze exceptions.
21:57:52 <bknudson> naming suggestion: Lougheed
21:58:18 <ttx> bknudson: a bit late, come back for M :)
21:58:35 <bknudson> what's the name?
21:58:54 <ttx> poll to open next week
21:59:00 <ttx> but trademark checks were run
21:59:42 <ttx> still hoping we can add Lilwat to the mix (first nation name)
22:00:01 <ttx> but probably won't get the approval we need from the tribe
22:00:07 <ttx> in time for the poll
22:00:13 <ttx> and that closes this meeting
22:00:17 <mestery> thanks ttx!
22:00:21 <ttx> #endmeeting