20:03:45 <ttx> #startmeeting tc
20:03:46 <openstack> Meeting started Tue Apr  1 20:03:45 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:47 <markmcclain> o/
20:03:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:50 <openstack> The meeting name has been set to 'tc'
20:03:51 <ttx> Our agenda for today:
20:03:56 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:04:05 <ttx> #topic Integrated projects and new requirements: Gap analysis for Keystone
20:04:16 <ttx> Our guest for this week is... dolphm!
20:04:21 <ttx> dolphm: o/
20:04:25 <ttx> Did you prepare an etherpad for the analysis ?
20:04:34 <dolphm> yep! https://etherpad.openstack.org/p/keystone-incubation-integration-requirements
20:04:50 <dolphm> i crossed out a few things that are fairly given
20:04:57 <markmc> dolphm, thanks
20:05:03 <lifeless> ttx: specifically, please ping me for input, as I'll miss things - sorry
20:05:06 <dolphm> and/or not relevant for an already-integrated project
20:05:07 <markmc> dolphm, you couldn't change your colour to something lighter?
20:05:14 * markmc colour-blind :)
20:05:15 <russellb> markmc: thanks
20:05:15 <ttx> lifeless: understood
20:05:19 <russellb> was burning my eyes
20:05:24 <markmc> cool
20:05:38 <dolphm> markmc: how's that? i actually just turn off all colors in etherpad completely
20:05:45 <ttx> #link https://etherpad.openstack.org/p/keystone-incubation-integration-requirements
20:05:47 <markmc> dolphm, great, thanks
20:05:50 <dolphm> gear icon -> authorship colors
20:06:20 <markmc> random question to start with
20:06:34 <mikal> dolphm: so reading through, what's your plan to deprecate the v2 API (if at all)?
20:06:38 <mordred> dolphm: on the api stability - I've heard folks talking about v2 deprecation but also that v3 isn't supported everywhere yet  - is that a thing that shoudl be poked at?
20:06:38 <markmc> if the mission is clear, why was there debate as to whether barbican functionality or KDS belongs in keystone
20:06:44 <mordred> mikal: jinx
20:06:51 <vishy> o/
20:07:04 <russellb> we had a thread on that recently on -dev
20:07:07 <dolphm> mikal: working to formalize that very soon as part of https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition
20:07:18 <mordred> oh good
20:07:33 <dolphm> mikal: we also discussed a bit today in our keystone meeting, but the gist is that our next step is to start integrating our latest client work into other projects
20:07:45 <russellb> re keystone v2: http://lists.openstack.org/pipermail/openstack-dev/2014-March/031016.html
20:07:50 <dolphm> mordred: does that answer your question? ^
20:07:52 <mordred> russellb: thanks
20:07:54 <markmc> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/031016.html
20:07:55 <dolphm> russellb: ++
20:07:55 <mikal> dolphm: cool. What sort of timeline do you have in mind?
20:07:58 <mordred> dolphm: yup
20:08:00 <markmc> #link https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition
20:08:44 <russellb> ttx did a nice job summarizing the ideal workflow for moving toward deprecating v3: http://lists.openstack.org/pipermail/openstack-dev/2014-March/031040.html
20:08:48 <dolphm> mikal: we'll do our best to help as many projects as we can move to v3 during juno, but my goal is to have all the integrated projects on v3 in 6 months
20:09:28 <mikal> dolphm: ok, sounds like a good start to me
20:09:38 <mordred> I think that's an excellent plan
20:09:54 <ttx> that plan is valid for all API deprecations btw
20:09:57 <markmc> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/031040.html
20:10:04 <russellb> ttx: +1
20:10:19 <ttx> maybe I should turn that into a wikipage
20:10:35 <markmc> ttx, could be good to add to openstack/governance
20:10:43 <markmc> as guidelines
20:10:45 <russellb> yeah, i like that
20:10:53 <ttx> indeed
20:10:58 <mikal> agreed
20:10:58 <sdague> one of the questions I had regarding the stable interface, is there seems to be a large amount of work done in keystone client relative to the other clients (which are mostly thin access layers on the API). How does that impact the definition of a stable API?
20:11:11 <ttx> #action ttx to propose Api deprecation workflow guidance to openstack/governance
20:11:19 <russellb> this v2 / v3 situation is really the only concern i had for keystone, and it's an issue that applies more broadly, they just happened to get it brought up very recently
20:11:45 <markmc> sdague, got an example?
20:12:04 <dolphm> sdague: referring to session or auth_token or something specifically?
20:12:29 <sdague> dolphm: mostly I think on the session and auto_token front
20:12:31 <russellb> does the client do a lot more than "thinly" wrap the API?
20:12:45 <ttx> dolphm: I have one question, about the middleware and it being shipped with the client library
20:12:48 <sdague> it has a pretty substantial caching layer
20:12:53 <dolphm> ttx: your deprecation outline could be a revision to this https://wiki.openstack.org/wiki/APIChangeGuidelines
20:12:57 <sdague> which was the cause of the last CVE
20:13:03 <ttx> dolphm: i think that's an artifact from the time where you only had the main project and client library allowed
20:13:15 <russellb> the API change guidelines could be modified to be TC curated, as well
20:13:22 <ttx> Now that we live in a program world, I wonder if the middleware shoudln't just be shipped separately
20:13:23 <russellb> something worth standardizing on
20:13:28 <dolphm> russellb: session is intended to manage authentication state for other clients (and dogfooded by keystone)
20:13:40 <markmc> sdague, when we say "stable API" I assume we mostly mean REST API
20:13:50 <sdague> markmc: yes, agreed
20:14:00 <markmc> sdague, python API stability good too, but applies to all libraries we publish
20:14:12 <dolphm> auth_token shouldn't be seen as much more than a slightly privileged identity client with a unique interface
20:14:14 <sdague> but when we did our keystone & heat & tempest session in HK there was definitely a bunch of disconnect
20:14:21 <ttx> (my question is slightly off-topic since we talk abot keystone, not keystoneclient, but meh)
20:14:23 <sdague> at the time there was almost no keystone direct tested
20:14:31 <sdague> it was all through the library
20:14:35 <sdague> it's much better now
20:15:15 <annegentle> ttx: russellb: I have a question related to the v2/v3 deprecation messaging -- drawing parallel to the XML deprecation. I can put it in a mailing list post, but generally wanting to define the discussion channels and how do we know we have properly discussed
20:15:19 <markmc> ttx, middleware is API client code, makes conceptual sense to live in keystoneclient IMHO
20:15:22 <annegentle> not trying to be off topic but I see parallels
20:15:33 <markmc> ttx, not that I care much either way - just don't see an issue
20:15:36 <russellb> annegentle: fair
20:15:49 <dolphm> markmc: the only issue is packaging -- auth_token may have additional dependencies that a thin client library should not
20:16:13 <ttx> markmc: ok -- it just is an infinite source of vulnerabilities while we don't issue that many on other "clients". I guess we can live with that if it makes conceptual sense
20:16:22 <mordred> dolphm: so by splitting, you could potentially make having the other client libs consume keystoneclient easier?
20:16:28 <annegentle> russellb: it means DocImpact is working, so that's good... just not sure how/when to document the impact
20:16:31 <sdague> right, like the fact that there have been a lot of race conditions in the cache layer corrupting tokens
20:16:34 <ttx> we could also update the middleware more easily
20:16:39 <sdague> I think we fixed 3 of those this cycle
20:16:45 <dolphm> mordred: it'd make the dependency graph cleaner - i don't know about easier
20:16:52 <mordred> dolphm: :)
20:16:55 <russellb> annegentle: talking about nova XML?  yes, a lot more discussion is needed before any real action is taken IMO
20:17:04 <mordred> dolphm: easier socially - less extra deps pulled in
20:17:09 <ttx> otherwise when we bump the middleware for security reasons, we have to collect the new client stuff in the same "release"
20:17:09 <dolphm> mordred: then sure
20:17:18 <annegentle> russellb: okay, I saw a patch with the word deprecation in a message, so I'll follow up on list
20:17:36 <markmc> all sounds like reasonable reasons to split out
20:18:11 <markmc> dolphm, repeating mission/scope question - if the mission is clear, why do you think there was debate as to whether barbican functionality or KDS belongs in keystone ?
20:18:25 <russellb> annegentle: yes it's marked deprecated, but discussion needed before we can totally pull the plug.  been trying to get usage data from deployers and such.
20:18:31 <dolphm> we also do crypto work in keystoneclient, which is consumed by both auth_token and the keystone service -- we'll likely see more of that moving forward
20:18:41 <ttx> dolphm: if we did that (separate middleware from lib), let's aim for the beginning of a cycle to do it
20:19:16 <dolphm> ttx: ack, i think we have a relevant summit session proposed already
20:19:23 <ttx> markmc: I think it was more of a timing issue originally. Then the debate came from that original suggestion
20:19:50 <ttx> markmc: i.e. we said "in keystone" because we needed it somewhere and keystone was the first consumer
20:20:04 <dolphm> markmc: both deal with secrets/credentials to an extent - i think it's a valid conversation to have
20:20:08 <ttx> and then when barbican came along I asked "so.. would the KDS still live in keystone ?
20:20:20 <dolphm> ttx: ++
20:20:37 <ttx> but wityh barbican positioning as the main purveyor of secrets, I think the KDS makes sense in barbican
20:20:40 <sdague> honestly, on the QA side the keystone team stepped up a lot this cycle. I think we end up hitting v2 API about 2k times (including indirects through keystone client) and v3 API about 500 times over the course of a full tempest run
20:20:43 <markmc> dolphm, ok, cool - and consensus has been reached now
20:20:52 <dolphm> ttx: ++ KDS is definitely more closely related to barbican than to keystone
20:21:36 <dolphm> sdague: wow, and we're working to reduce API chatter lol
20:21:53 <sdague> we create and tear down a lot of users for tenant isolation
20:22:00 <dolphm> we also have a substantial number of functional API tests within keystone.tests
20:22:02 <sdague> so keystone gets a nice extra work out from that
20:22:15 <sdague> every tempest class runs under a different user & tenant
20:22:19 <ttx> Last tricky question... performance. keystone has been ignored in te past due to poor performance. Would you say that today those concerns are no longer valid ?
20:22:40 <mordred> dolphm: may be out of scope for this meeting - but should we do a keystone-functional test aginst the devstack cloud like we do for swift-functional?
20:22:48 <ttx> i.e. we don't hit it that much in regular operation so its no longer a performance bnottleneck ?
20:22:50 <dolphm> still valid -- but we have two MAJOR changes in the pipeline that will radically improve performance
20:23:02 <russellb> dolphm: what are they?  tl;dr version :)
20:23:09 <ttx> now I'm curious
20:23:23 <dolphm> in short: ephemeral, compressed PKI tokens w/ revocation events
20:23:50 <russellb> ah, event based revocation instead of polling keystone 1/second from everywhere to check the latest CRL?
20:23:54 <jogo> will those contain the catalog in them like current PKI tokens?
20:24:06 <dolphm> no more token backend in sql/memcached/whatever, no more issues with 8k tokens, and faster distribution of revocation events to services needing to validate (and invalidate) tokens quickly
20:24:10 <dolphm> russellb: yes
20:24:14 <russellb> awesome
20:24:22 <markmcclain> cool
20:24:23 <sdague> nice
20:24:25 <russellb> oslo.messaging notification based or what?
20:24:27 <ttx> are those changes Juno material ?
20:24:33 <dolphm> we landed revocation events in icehouse, but haven't taken advantage
20:24:41 <russellb> how do you get the events?
20:24:48 <dolphm> russellb: all HTTP right now, but it could be moved to HTTP + messaging
20:24:54 <dolphm> russellb: we needed HTTP either way
20:25:00 <russellb> long polling i guess?
20:25:04 <sdague> dolphm: long poll on http?
20:25:24 * markmc thinks we're in the weeds :)
20:25:25 <dolphm> russellb: we're just doing GET /v3/OS-REVOKE/revocations_events and then polling for updates with something like GET /v3/OS-REVOKE/revocations_events?since=<timestamp>
20:25:26 <markmc> interesting, but ...
20:25:30 <dolphm> markmc: yeah lol
20:25:32 <ttx> markmc: nice weeds
20:25:34 <sdague> markmc: fair :)
20:25:37 <dolphm> anyway, i'd like to move to messaging :)
20:25:40 <russellb> dolphm: that sounds like polling, heh
20:25:43 <ttx> OK, let's wrap it up
20:25:49 <russellb> anyway, later is fine :)
20:25:53 <ttx> I think we didn't find any gap
20:26:05 <ttx> or I missed them in the flow
20:26:07 <dolphm> ttx: and yes, they should all land in juno
20:26:36 <ttx> agree ?
20:26:45 <russellb> ttx: agree
20:26:46 <mordred> ++
20:26:47 <sdague> ttx: yes, I think so
20:26:50 <markmc> yep
20:27:09 <russellb> dolphm: nice work to the whole keystone team
20:27:10 <markmcclain> ttx : yep
20:27:10 <ttx> #info No gap found between Keystone current state and integration requirements
20:27:16 <dolphm> cool, thanks everyone
20:27:18 <dolphm> russellb: /salute
20:27:22 <ttx> dolphm: congrats!
20:27:46 <ttx> fwiw keystone has been hitting releasemanagement deadlines like a swiss clock lately
20:27:56 <ttx> no feature freeze exception, first out of RC1
20:28:16 <ttx> so it looks very sane
20:28:29 <ttx> Moving to next topic.
20:28:36 <ttx> #topic Status update on Defcore progress
20:28:44 <ttx> mikal, annegentle, zehicle_at_dell: o/
20:28:56 <mikal> Hi
20:28:57 <ttx> I read the summary, looks like you made good progress at the last meeting
20:29:03 <mikal> So I missed the most recent meeting
20:29:04 <ttx> #link https://etherpad.openstack.org/p/openstack-designated-sections
20:30:15 <zehicle_at_dell> o/
20:30:32 <zehicle_at_dell> +1
20:30:36 <ttx> I think annegentle mordred dhellmann russellb markmcclain and jeblair were there for the TC
20:30:45 <zehicle_at_dell> #link https://etherpad.openstack.org/p/openstack-designated-sections
20:30:53 * jgriffith missed it sadly
20:30:56 <zehicle_at_dell> I uploaded the recording and it's on the link
20:30:59 <dhellmann> I thought that meeting went well. I know I have a much clearer picture of what sort of answer we need to put together.
20:31:03 <mordred> ++
20:31:12 <russellb> so i think next step is we need to finish filling out and vetting proposed designated/replaceable sections, yes?
20:31:39 <dhellmann> russellb: yes, that todo is to be completed "at or by the juno summit"
20:31:40 <zehicle_at_dell> we also have a request to have an official TC approval of the principles
20:31:57 <ttx> zehicle_at_dell: are there specific PTLs which you need input from which haven't made contact yet ? Which we could track down for you ?
20:32:06 <jeblair> yes, the most useful things out of that meeting related to scope and direction; we did not get into the details too much; so i think what's in the etherpad is still very much 'strawman'
20:32:09 <ttx> zehicle_at_dell: The selection principles make sense to me
20:32:09 <russellb> generated by PTLs, collected/blessed by this group?
20:32:36 <ttx> zehicle_at_dell: the selection principles ?
20:32:42 <dhellmann> russellb: yes, some combination of that
20:32:48 <russellb> selection principles seem sane to me
20:32:49 <ttx> (official approval of the selection principles ?)
20:32:51 <dhellmann> ttx: there is a list in the etherpad
20:32:52 <sdague> zehicle_at_dell: consumers ther seems to be defined mostly as operators & packagers?
20:32:53 <zehicle_at_dell> ttx, I think that we'll know which projects are critical soon because they are likely to have  must-pass candidates
20:33:32 <zehicle_at_dell> ttx, that's the title on the wiki page
20:33:37 <ttx> zehicle_at_dell: OK I'll prepare a proper resolution for approval of the selection principles
20:33:54 <ttx> zehicle_at_dell: probably for next week meeting given the usual delay
20:34:29 <markmc> where are the selection principles?
20:34:29 <ttx> TC members: if the ones on the etherpad are completely unreasonable for you, speak now
20:34:35 <ttx> on the etherpad
20:34:40 <markmc> oh, zehicle_at_dell said wiki
20:34:49 <sdague> yeh L27 in the etherpad
20:34:53 <zehicle_at_dell> not focused enough, etherpad :/
20:35:01 <jeblair> i think they are reasonable
20:35:13 <ttx> I like the "cross-platform" one
20:35:17 <markmc> cool, there are other defcore principles on the wiki :)
20:35:28 <ttx> we are people of principles
20:35:42 <zehicle_at_dell> markmc, yes
20:35:51 <markmc> "balance between the commercial ecosystem and the community ecosystem."
20:35:58 <ttx> #action ttx to draft TC resolution on selection principles
20:36:02 <markmc> given that this is exclusively about "the commercial use of the brand"
20:36:07 <dhellmann> we may need to refine the one on line 40 about developer intent -- ceilometer has some plugin APIs for which we don't expect the pieces to be replaced but they can be supplemented
20:36:08 <markmc> why the reference to the community ecosystem ?
20:36:29 <sdague> dhellmann: that's not covered by API extension?
20:36:44 <zehicle_at_dell> markmc, because the intent of designated sections is to encourage upstreaming
20:36:48 <dhellmann> sdague: those plugins are not part of the rest api
20:36:53 <mordred> markmc: we want to incentivize the commercial ecosystem to continue to participate in teh community
20:37:02 <dhellmann> sdague: IIRC, every use of "API" in that doc means "REST API"
20:37:10 <markmc> ok, thanks
20:37:15 <sdague> ok, maybe worth clarifying
20:37:16 <russellb> by explicitly letting them replace stuff, cool :)
20:37:46 <sdague> because on something like HEAT, the rest API is really minimal, and the payload is what's important
20:38:35 <sdague> like heat without hot, seems no good to me, but hot isn't strictly the rest api
20:38:49 <dhellmann> sdague: similar for ceilometer -- we wouldn't want a sample collection plugin to be replaced with one that has different behavior, but adding new ones is allowed
20:38:54 <markmc> REST starts with Representation
20:38:59 <markmc> pretty clear payload is part of it
20:39:10 <russellb> agree
20:39:41 <sdague> sure, fair, I guess I don't understand how API extension doesn't cover ceilo then :)
20:39:56 <sdague> but we can go off in the weeds elsewhere
20:40:01 <dhellmann> sdague: adding a new sample doesn't require any change to the API of ceilometer
20:40:01 <zehicle_at_dell> good clarification - we expected that this would be extended in discussion
20:40:02 <dhellmann> sure :-)
20:40:15 <ttx> timeboxing this to 5 more minutes
20:41:25 <ttx> well, unless nobody has anything to add, obviously
20:41:28 <jeblair> ttx: that was too effective
20:41:42 <ttx> jeblair: weird
20:41:52 <ttx> well then
20:41:54 <ttx> next topic ?
20:42:01 <sdague> go for it
20:42:06 <ttx> #topic More post-graduation expectations
20:42:11 <ttx> * Add API graduation/post-graduation requirements (https://review.openstack.org/68258)
20:42:15 <ttx> * Add Heat integration post-graduation expectation (https://review.openstack.org/81773)
20:42:20 <ttx> * Add Horizon integration post-graduation expectation (https://review.openstack.org/81774)
20:42:33 <ttx> Since the requirements doc reflects consensual requirements, I waited for majority of approvals on it
20:42:41 <ttx> One of them still misses majority vote (https://review.openstack.org/#/c/68258/)
20:42:54 <ttx> yep, only 6
20:43:03 <ttx> But it's been on the table for a few meetings now, so I think we need to make the final vote on it.
20:43:11 <markmc> weird, that was the least controversial one I thought :)
20:43:14 <ttx> Final vote means it should be accepted if it gathers 5 +1s (and less than 5 -1s). So if you don't like it, make sure to cast your vote asap
20:43:25 <ttx> #info Final vote called on https://review.openstack.org/#/c/68258/
20:43:41 <markmc> bah, had a draft reply to dhellmann saved there
20:43:52 <ttx> Will collect the result of the "final vote" tomorrow morning, to give absent members a chance to -1 it :)
20:44:18 <ttx> (with the current votes it will get accepted tomorrow morning)
20:44:26 <ttx> comments on that ?
20:44:33 <ttx> anyone wants to push the 7th +1 ?
20:44:49 <dhellmann> I think jgriffith just did?
20:45:02 <ttx> magic
20:45:17 <markmc> thanks
20:45:18 <ttx> ok thx!
20:45:24 <ttx> #topic Minor governance changes
20:45:29 <ttx> * Fix post-graduation expectation typo (https://review.openstack.org/83765)
20:45:35 <ttx> Will just approve that one as typo fix now
20:46:54 <ttx> I .. just can't see the typo
20:47:06 <dhellmann> missing letter
20:47:12 <ttx> cyle
20:47:14 <ttx> hah
20:47:20 <russellb> sometimes i need unified view to see that stuff, heh
20:47:36 <ttx> #topic Open discussion
20:47:49 <ttx> Got one quick question for you all
20:47:50 <russellb> looks like there's a couple other changes up now
20:47:59 <markmcclain> low hanging fruit change: https://review.openstack.org/#/c/84489/
20:48:03 <markmc> do we have plans for a TC pow-wow at the summit yet?
20:48:05 <ttx> How do you want us to select the cross-project workshops ?
20:48:12 <markmc> aside from the joint meeting with the board
20:48:20 <ttx> should the newly-elected TC members do it ?
20:48:33 <ttx> Shoud the PTL group do it ?
20:48:35 <dhellmann> markmc: didn't we appoint mordred as our meat-space event coordinator?
20:48:46 <mordred> dhellmann: I book dinners
20:48:51 <ttx> dhellmann: as long as the event is not held in Paris
20:48:53 <mikal> mordred: good dinners
20:48:56 <dhellmann> mordred: they serve meat at dinner
20:48:58 <markmc> heh
20:49:02 <mordred> dhellmann: mmm. meat
20:49:05 * markmc does like a good mordred dinner
20:49:09 <sdague> ++
20:49:12 <russellb> fogo de chao!
20:49:17 <markmc> was thinking whether a non-social pow-wow would be good ?
20:49:22 <mordred> ++
20:49:23 <markmc> maybe before it?
20:49:27 * mordred was going to suggest the same thing
20:49:30 <jeblair> ttx: ptls?
20:49:31 <sdague> markmc: +1 on non social pow wow
20:49:43 <dhellmann> markmc: I like it
20:49:45 <russellb> sorry i was still thinking about meat
20:49:46 <markmcclain> bacchanalia
20:49:51 <russellb> but +1 on a working session
20:50:02 <mordred> getting some space to dive in to deeper tech questions
20:50:02 <ttx> jeblair: I have no strong opinion on it. The PTLs group already schedule the rest of the summit, so asking them makes sense
20:50:03 <mordred> etc
20:50:03 <dhellmann> before or after the summit?
20:50:10 <dhellmann> or during, even?
20:50:17 <mordred> dhellmann: I vote for before
20:50:29 <mikal> We need to decide soon because of travel bookings
20:50:33 <ttx> I'll be in on the Saturday afternoon
20:50:40 <dhellmann> mordred: sunday is the board meeting, do you mean before sunday?
20:50:44 <russellb> ttx: PTLs are also very busy with their scheduling, maybe it makes sense for the TC to lead the cross project stuff?
20:50:46 <ttx> Sunday afternoon is the TC/BoD joint thing
20:50:55 <mordred> oh right
20:51:01 <sdague> ttx: I think it would be good for at least you to be in on the picking of cross platform talks as release manager
20:51:02 <dhellmann> russellb: +1
20:51:05 <mikal> I think Tom wanted a meet the TC thing for the ops thing on Monday too
20:51:10 <mikal> Just as a heads up
20:51:17 <russellb> I think it makes sense for the TC to continue to step up as the cross-project leadership group
20:51:30 <sdague> russellb: +1
20:51:34 <ttx> sdague: at the very least I would facilitate that choice (as Foundation crew in charge of design summit org)
20:51:37 <markmcclain> russellb: +1
20:51:47 <russellb> fwiw, i'd be happy to help coorindate, as i won't be leading the nova scheduling this time
20:51:53 <jgriffith> russellb: I agree as long as I'm on TC :)
20:51:54 * ttx can wear all sorts of hats and be there anyway
20:51:57 <sdague> +1 for russellb
20:52:17 <russellb> and i'll rope sdague in, and anyone else that wants to help :)
20:52:18 <sdague> I can help on that as well, as I get to punt on qa scheduling
20:52:22 <russellb> sdague: ha
20:52:29 <ttx> I like the idea of the TC making the final call on those
20:52:46 <ttx> also a smaller group so easier to come to consensus
20:52:51 <russellb> maybe even use openstack/governance to get approval on the final set of sessions :)
20:53:02 * ttx slaps russellb
20:53:06 <sdague> heh
20:53:26 * russellb frowns
20:53:30 <mikal> I guess it depends how many sessions are proposed
20:53:39 <mikal> Lots of sessions == harder to get a concensus
20:53:40 <jeblair> ttx: can we see them?
20:53:46 <ttx> jeblair: sure
20:54:01 <russellb> proposals are all public
20:54:03 <ttx> http://summit.openstack.org/, click on Topic to sort by topic
20:54:41 <russellb> 19 cross-project submissions so far
20:54:43 <russellb> how many slots?
20:54:50 <ttx> 21 slots, 19 proposals
20:54:52 <ttx> BUT
20:54:54 <sdague> ttx: was it decided yet about single vs. double slots?
20:55:02 <ttx> some are probably worth double slots
20:55:13 <ttx> sdague: annegentle suggested we keep 40-min ones
20:55:14 <russellb> ultra-cross-project??
20:55:16 <vishy> oh i have a cross-project proposal i need to make
20:55:26 <vishy> regarding hierarchical multitenancy
20:55:28 <sdague> I'd really like the test matrix one to be double slot, because I think it's going to take a while
20:55:51 <ttx> rigth. i don't want us to just start on a topic and not really close it
20:55:55 <markmc> remind me how the scheduling is going to work again ?
20:56:02 <ttx> a design summit session is a good conversatoin opener
20:56:09 <russellb> oh i see what you mean by double ...
20:56:17 <ttx> but in these workshos you'll have a hard time getting the same people around the table again
20:56:18 <devananda> sdague: ++
20:56:39 <ttx> so we should definitely consider accepting less and granting a few double slots
20:56:41 <sdague> markmc: 3 tracks on Tuesday for cross project
20:56:49 <sdague> no other integrated project tracks that day
20:56:50 <jeblair> ttx: i see at least one that i think should be in infra (openstackid)
20:56:58 <markmc> sdague, cool, thanks
20:57:05 <ttx> jeblair: we might want to redirect some, yes
20:57:10 <russellb> yep
20:57:16 <russellb> and the gantt thing should be nova for now ...
20:57:35 <ttx> russellb: well.. I wanted the climate guys around THAt table
20:57:35 <sdague> yeh, as always, there are folks that propose to a suboptimal track, we can move some of that around
20:57:53 <jeblair> since we're reviewing as a group (or our successors)...
20:58:02 <ttx> if you need anything moved FROM cross-project workshops track, I can do that
20:58:04 <sdague> ttx: but climate won't be conflicting right?
20:58:09 <jeblair> we might need to put a little effort into trying to get things redirected early
20:58:10 <ttx> sdague: no they won't
20:58:17 <sdague> it's actually better for climate + nova to be in the nova track
20:58:26 <russellb> ttx: this sesesion is separate from the climate stuff IMO
20:58:39 <ttx> oh, looking
20:58:44 <sdague> 2 minutes
20:58:55 <ttx> oh right. Gantt APi interfaces
20:58:58 <russellb> sdague: i don't think the climate folks really took the "do it in nova" feedback, according to the ML thread that followed the TC meeting.  :-(
20:59:01 <ttx> that one shoud be Nova's for sure
20:59:06 <russellb> ttx: k :)
20:59:17 <sdague> russellb: well we can nudge them again :)
20:59:20 <russellb> yep
20:59:21 <jeblair> ttx: consider this an official request to move openstackid http://summit.openstack.org/cfp/details/159 to infra :)
20:59:22 <ttx> russellb: want me to move it now ?
20:59:26 <russellb> ttx: yes
20:59:54 <russellb> there's 2 copies of http://summit.openstack.org/cfp/details/184
20:59:57 <russellb> and both should be Nova IMO
20:59:58 <ttx> done and done
21:00:09 <ttx> and we are past time
21:00:12 <ttx> #endmeeting