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