18:02:42 #startmeeting keystone 18:02:43 Meeting started Tue Oct 22 18:02:42 2013 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:44 lol honorable attempt 18:02:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:47 The meeting name has been set to 'keystone' 18:02:49 we usually turn the meeting into a beer bash if the chair is not around 18:02:52 stevemar, haha i was typing that as you did it. 18:03:02 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:03:04 success 18:03:16 #topic Reserved migration numbers for havana 18:03:32 looks like it's continuing from last week 18:03:49 KEYSTONE! 18:03:52 p.s. everyone's homework was to read up on reserved migrations 18:04:16 whoops. 18:04:22 have we had any migrations merge since last week? 18:04:28 dolphm_, don't think so 18:04:32 dont think so 18:04:35 what would require a migration? 18:04:36 slash, since rc1 18:04:50 looking 18:05:10 I thought morganfainberg had some late fixes to migrations... 18:05:11 if we've had anything merge, this this topi is moot 18:05:16 topic* 18:05:28 since most new features start out as extensions, there should be very little migration if any 18:05:28 bknudson, that was logic to a migration that was already there 18:05:33 bknudson, for sqlite 18:05:44 no new migration(s) 18:06:01 gyee: interesting point- we'd need reserved migrations for extensions as well 18:06:16 dolphm_, wait, I thought extensions are different 18:06:32 gyee, if we're putting in reserves for one, we should for the other. 18:06:39 agreed 18:06:40 dolphm_, we could do them like BASIC programs, and number them 5, 10, 15... 18:06:58 ayoung, i.. i.. i have no words 18:07:00 k, I am fine with reservation 18:07:00 then if we need to instert a migration between 10 and 15 make it 12 18:07:00 ayoung: they need to be sequential 18:07:01 ayoung, brilliant! 18:07:13 poke 53280,1 18:07:14 unfortunately, what dolphm_ said 18:07:31 low hanging fruit 18:07:32 1, 2, 3 - then if we need to insert one; 1.1? 18:07:33 dolphm_, how many reserved numbers do you think we need? 18:07:34 ;) 18:07:44 joesavak, if only 18:07:49 looks like Nova had placeholders in grizzly and never wound up using them. 18:07:53 3 in extension repos, 5-10 in core? 18:07:57 dolphm_, what if we have a separate repo for back fixes? 18:08:08 ayoung, how would that work? 18:08:27 ayoung: that wouldn't be tranparent 18:08:52 I don't think it'll hurt anything to add the placeholders, and could potentially come in handy, so why not? 18:08:58 is anyone strongly opposed to reserved migrations? 18:09:04 dolphm_, not opposed. 18:09:07 not i 18:09:15 bkhudson: agree 18:09:19 i'd say 3 in extensions, 5 in main max though 18:09:19 sounds like they'll be handy 18:09:21 sounds good 18:09:23 or...beter yet, a separate repo for Icehouse fixes 18:09:57 so once we backport a fix to Havana, we adjust the fixes in the Icehouse repo to account for them....just a thought 18:09:58 nova _never_ used them. i don't really think we're going to, but they are mostly harmless if they exist. 18:09:58 I see *each* extension have their own migration_repo dir 18:10:07 so we are saying, 3 reservations per repo? 18:10:16 gyee, i would say at most. 18:10:23 3. 18:10:25 k 18:10:47 I think reservations is the wrong approach. I have a thought...let me collect it and write it up 18:10:48 that works 18:10:53 ayoung, ok. 18:11:02 ayoung, sure send it to ML 18:11:13 so that gets chalked up as an action item? 18:11:24 yeah 18:11:29 dolphm_, slightly related, we doing a collapse of the migrations this time around? or? 18:11:29 any volunteers? :) 18:11:46 #action ayoung write up approach to backporting migrations using separate repo 18:11:51 #action ayoung to turn on his light bulb on migration reservation? 18:11:52 I'll do the reservations 18:12:04 if someone wants to do the work of collapsing, go for it 18:12:06 #action dolphm to look at reservations 18:12:21 next topic, way more fun 18:12:23 dolphm_, i'll see if I can make that happen. 18:12:23 stevemar: what's next? 18:12:25 #topic Reviewing design summit schedule 18:12:31 #link http://summit.openstack.org/ 18:12:35 for my topic 18:12:41 #action morganfainberg look into collapsing migrations 18:12:41 err, sort* 18:12:47 sort by topic ... sigh 18:12:48 I left comments on a bunch of sessions 18:12:52 dolphm_, reservations are not going to work. When the repo says wee are at revsion X we need to know what that means.... 18:12:54 dolphm_, session on fixing service catalog? 18:13:07 dolphm_ how many session spots do we have? 18:13:21 9 18:13:34 the remaining 20 will be conducted in a pub 18:13:35 I'd like to split federation and the client session 18:13:45 gyee: ++ 18:13:58 gyee, ++++++++ 18:14:09 currently there are 11 proposed sessions, so lets try to find some that can be consolidated 18:14:26 federation and client should be separate. Very different topics 18:14:26 stevemar, we can also try unconference 18:15:03 gyee: yup, but that gets busy too; and there might be some sessions that are closely related 18:15:22 if we can set a goal for the extensions one it can be merged with Internal API stabilization topic 18:15:28 HTML is refused...that gets us down to 10 18:15:34 dolphm, i see you refused 2 sessions already 18:15:34 they are both code management / approach 18:15:45 Extension mechanisms can hang on something else 18:15:53 i think i refused domain scoped tokens 18:15:58 ayoung: yeah, V3 API Domain Scoped Tokens and HTML for Keystone have been refused 18:16:00 if not, it can be 18:16:28 morganfainberg, that was my thought as well 18:16:32 we've gotten bugs to simply doc that better 18:16:34 ayoung, 100% agree with it. 18:16:42 but lets leave it as is unless any more topics come in 18:16:49 right. 18:17:55 okay, if need be, we can merge those 2 sessions, Internal API Stabilization and Extension Mechanisms 18:18:05 only as a last resort :) 18:18:19 there are other session which will have Keystone impacts, i.e. killing pagination 18:18:28 Did Auditing AuthN, AuthZ and Policy Decisions get accepted? 18:18:38 topol, not yet 18:18:40 the client session description is way too big for a single session 18:19:23 dolphm_, perhaps we should expand the client one to 2 sessions and collapse the extensions and API stabilization ones to a single one? 18:19:29 dolphm_ suggest merging (internal API stabilitaion and extension) to get another client session? 18:19:35 morganfainberg +1 18:19:38 stevemar, ++ 18:19:41 dolphm_, that's because we have too many client issues to fix :) 18:19:44 sounds good 18:19:49 works for me 18:20:02 i'll update mine and incorporate the extension stuff ayoung, 18:20:14 the "ignoring the API, what should the client look like" is perfect for the summit 18:20:16 #action dolphm, refuse one of the sessions, update the comments and create a new session for client 18:20:20 that should be its own session 18:20:33 Sounds good. morganfainberg once you do, tag my session and I'll drop it 18:20:35 it should be async! 18:20:44 ayoung, will be done today. 18:20:49 awesome 18:21:00 bknudson, so keystone should respond to AMQP? 18:21:01 do we need 2 sessions for federation? 18:21:11 No, one session for federation 18:21:23 if it is going to take more than one, it is not going to be done in 2 either 18:21:29 dolphm_: i'm not sure how much of that client stuff we'll need to cover but i don't mind a seconds session 18:21:29 there's a LOT of material there 18:21:32 stevemar, i think one session should be enough. we can unconference anything else that comes up 18:21:37 i think if we can schedule it at the end of the day, we can take up any arguments at a pub later :) 18:22:04 yes sir 18:22:09 discovery is happening already, everyone hates auth_token, APIClient and Versioning are my two main ones 18:22:20 dolphm_, i think it'll be more about chopping things and slating for J if we're _that_ full of federation stuff. 18:22:23 \o/ desk! 18:22:28 dolphm, yay! 18:22:29 We have an approach, and we are, I think tracking. Federation session should be level setting so that we can continue any long term discussions after the conference. But I thik we are finally positioned to implement Federation in the context of the other parts of Keystone, something that was not true until Havana 18:22:54 ayoung +1 18:23:12 What about globally unique IDs, though 18:23:23 that is not really Federartion, but came up in the context of LDAP 18:23:35 do we need an LDAP session? Henrynash is not here, topol ? 18:23:42 sounds like federation. 18:23:49 bknudson, nope 18:24:11 federation handles it by user-passed-in-assertion@trusted-idp 18:24:14 LDAP seems pretty much under control now from my view 18:24:27 bknudson, similar, but this is for the case where we have a user store managed by Keysteon as well as a multiple LDAP stores. It ties in with henrynash's assignmnet API talk, though 18:24:30 ayoung, i don't think we will ever have a lack of LDAP stuff to talk about, but not sure if we need a session. 18:24:45 morganfainberg ++ 18:25:13 LDAP could be refactored into a read-only / read-write / ActiveDirectory implementations. 18:25:16 dolphm_ sorry, the people have spoke, 1 session for federation 18:25:25 dolphm, will get to talk about "The state of Keystone" as the PTL, and can level set on where LDAP is and is going to the community 18:25:30 multiple LDAP stores are really cool. but do we need enough steering ont hat to merit a session? 18:25:32 could also do connection pooling. 18:25:32 agreed, I think we have enough on LDAP already, let the consults make money off integration :) 18:25:35 bknudson, that actually would be a good approach. 18:25:41 consultants 18:25:47 #action everyone to read the sessions over and provide some comments :) 18:25:50 gyee, lol 18:25:53 topol, we need a way to figure out which backend to look at for a given user id 18:25:54 stevemar: i think 1 session is crazy for such a big topic 18:26:00 I would +1 gyee statement but then would need to go take a shower 18:26:03 its a generic problem, but driven home by LDAP 18:26:10 but Federation will have the same issue 18:26:14 it'll definitely be the single biggest change for icehouse 18:26:25 +1 topol's statement 18:26:26 We can try to cover it in Federation, but I'm afraid it would get lost 18:26:26 ;) 18:26:38 ayoung, leave some money on the table for the consultants 18:26:41 dolphm, i am not opposed to 2 sessions, but i think we will mostly be level setting for J if we have more than 1 18:27:02 dolphm, just unlikely that we'll see all the change by I2. 18:27:28 dolphm, there is likely to be value in level setting the federation direction though 18:27:53 morganfainberg: i'm thinking with two sessions to help get everyone on the same page concerning the work that's been done and what we want to accomplish, we're more likely to see it done by i2 18:28:35 dolphm, fair enough, so 2 client, 2 federation, and collapse 2 of the other sessions? 18:29:00 then we need another volunteer to combine a session 18:29:14 Extensions goes into API stabilization 18:29:26 yup 18:29:36 ayoung, right, if we expand to a 2nd federation session, we need to collapse another set 18:29:53 was centralized quota storage already talked about last summit? 18:30:02 Do wereally need a Quota talk? I thought that was a done deal? 18:30:09 ayoung, yap 18:30:16 We are doing quotas, it just is not done yet 18:30:32 design was signed off on, just the develpoer got stuck in the review process 18:30:37 yeah that seems redundant to do that in two subsequent sessions 18:30:38 ayoung: agree 18:30:40 erm summits 18:30:44 so, we can drop that one. 18:30:56 ayoung: we weren't quick enough to respond to their patchsets either 18:31:14 ayoung, we have https://review.openstack.org/#/c/37545/ also for quotas 18:31:28 ok so as long as we get quota stuff reviewed and accepted, we shouldn't need a session on it. 18:31:32 dolphm, ayoung, I think there were some unfinished business with quota, the usage aggregation part 18:31:40 not just domaint quota management 18:31:41 yeah, it seems generally accepted 18:31:44 but I am not sure if it really belong to keystone anyway 18:31:53 aguzikova_home, ah. 18:32:01 gyee, but it would be really cool if Keystone tokens had the quotas signed in them. 18:32:03 sounds like the axe is falling on this session topic 18:32:15 stevemar, sounds like 18:32:39 i'm pushing sessions around now, btw 18:32:54 are the sessions all on one day? 18:32:56 yeah, tell them to have a quota unconference and work out the last remaining issues. 18:33:04 wasn't there a security track last time? 18:33:05 ayoung, ++ 18:33:06 ayoung, sounds good 18:33:10 +1 18:33:20 #action dolphm to refuse quota session 18:33:22 bknudson, i think so… i don't remember 18:33:26 stevemar: done 18:33:42 sounds like we're doing 2 federation sessions then 18:33:57 is the Assignments session good as is? 18:34:12 there's three topics there -- i'm not sure the second one is worthy of summit time 18:34:23 is there any real argument about what needs to be done for assignments? 18:34:24 that's just a "yes, we need to clean up the sql impl" 18:34:34 bknudson, lots 18:34:35 I'll do an unconference on the HTML thing. I really just want a chance to demo it and don't currently have public hosting available. Need to set up one of those Rackspace developer accounts. 18:34:37 pretty much we need to cleanup interfaces controllers, etc 18:34:40 bknudson: henrynash wants a whole new HTTP API for assignments 18:34:44 like role-service 18:34:49 gyee: no 18:34:58 dolphm, wouldn't that be API version increment? 18:35:17 or is he saying as an extension? 18:35:25 dolphm, we still have use cases with role assignment need to solve 18:35:25 morganfainberg: if you're dropping support for something, yes 18:35:36 we also need to simplify assignment APIs 18:35:40 gyee: i'm more interested in the new use cases 18:35:45 assignments will have enough trickiness in it that it should have its own session, but maybe that can be combined with Federation. 18:35:51 we also need to simplify identity APIs 18:35:58 ayoung, nah. 18:35:59 if there's a use case for having metadata on an assignment, then a first class collection makes sense 18:36:02 It really is the ID/Assignment split that allows Federation to work 18:36:03 ayoung, don't combine it 18:36:12 i thought we're good, no need to continue trimming sessions 18:36:24 ayoung: -- for combining with federation 18:36:36 if we cut domain, then we have room for federation pt 2 18:36:37 Guys, I appreciate your focus on #link https://review.openstack.org/#/c/37141 again, as the solution proposed by ayoung is not addressing all use case. 18:36:40 dolphm, ayoung, yes, assignment will be heavily impacts with federation as well 18:36:49 especially on the mapping 18:36:50 ugh, i meant quota 18:37:23 gyee, dolphm, ayoung, the assignment one should just be scheduled around the federation ones… so we are in the same mindset if we can 18:37:40 morganfainberg, sure 18:37:43 atiwari, we're discussing session for the summit...we'll address that in a few... 18:37:45 created a placeholder 18:37:46 http://summit.openstack.org/cfp/details/346 18:37:48 morganfainberg +1 18:38:25 also, the auditing part will be very interesting, especially with mapping 18:38:40 ayoung, thanks 18:38:48 so back to the original question, dolphm, i think assignment one is good. 18:38:58 gyee, yeah, but auditing actually is tied with policy , which is not even a Keystone project, and if it were, would be part of the client 18:39:32 for audit what tokens a user requested is not nearly so important as figuring out what they did with them 18:39:41 ayoung, no, like given a user, tell me what he can do 18:39:54 morganfainberg, we can add atiwari ' 18:39:57 or given a resource, tell me who can do what to it 18:39:58 dolphm, ack, you pre-approved the API one, i can't edit it now 18:40:02 s concerns to the assignments session 18:40:18 ayoung, doesnt auditing need to be done on the server to make sure we catch everything? 18:40:21 atiwari, are you going to the summit 18:40:23 morganfainberg: crap 18:40:25 yes 18:40:29 topol, percisely 18:40:35 topol, auditing needs to be done on each machine, not just Keystone 18:40:45 dolphm, lol can you set it back to unreviewed, i'll get the exention stuff added to it and ping you shortly? 18:40:45 morganfainberg: fixed 18:40:48 k 18:40:56 ayoung, both Im thinking 18:41:01 i'll stop pre-approving stuff lol 18:41:11 dolphm: that is probably a good thing :) 18:41:30 so, there sounds like there is interest in auditing 18:41:47 dolphm: if you unset the client i'll remove some of those points - there's really just the two in there now i really want at summit the others can be later 18:41:57 client summit session 18:42:01 stevemar, the auditing aspect is generally missing :) 18:42:20 atiwari, we have a session for assignments http://summit.openstack.org/cfp/details/131 please add your topic to that. I think that it is the right place to discuss it 18:42:25 #link https://etherpad.openstack.org/p/keystone-sessions-icehouse something i quickly wrote up 18:42:44 ayoung, sure 18:43:01 we have 9 spots, and 9 currently proposed sessions... i think we're good assuming no one is against any session in particular 18:43:23 jamielennox: working on it 18:44:01 if anything else comes up, schedule unconference sessions for it. Everyone should sign up for a twitter account, as that was really useful for tracking who was where at the summit, and posting unofficial announcements 18:44:08 ayoung +1 18:44:11 k, everything is unreviewed or refused 18:44:14 Og..and everyone make sure your shots are up to date 18:44:18 ayoung +1 18:44:18 Hep A and Typhoid 18:44:27 ayoung, yes 18:44:28 ayoung and dolphm, this may also be a good topic for session? #link https://blueprints.launchpad.net/keystone/+spec/attribute-access-privilege-based-on-role 18:44:29 and flu 18:44:30 unreviewed for unconference 18:44:31 ayoung: twitter?.... :( 18:44:34 ayoung, really??? 18:44:47 atiwari, in the policy session, I think 18:44:49 that wasnt in my brochure 18:44:58 ok 18:44:58 jamielennox, welcome to the new internet 18:45:01 topol, according to the CDC 18:45:08 atiwari: has there been disagreement on the approach? 18:45:12 get an appointment at a travel clinic. 18:45:18 AND EVERYONE CHECK YOUR PASSPORTS! 18:45:23 not yet :) 18:45:50 atiwari: then i don't think we need a session 18:46:04 and bring enough cash to buy your way out if you wonder into the wrong hood :) 18:46:19 dolphm, I don't think someone has looked in to it yet :) 18:46:21 jamielennox: want to propose the second client session and break down the descriptions? 18:46:27 atiwari, that should be discussed here: http://summit.openstack.org/cfp/details/86 I think. It is not Audit specific, but all of that is based on the policy mechanism 18:46:50 gyee, do you know where I can get Louis Vutton knockoff wallets? My mom keeps asking :-) 18:46:53 atiwari: i've had several people mention it actually 18:46:58 topol, lol 18:47:00 i think everyone seems to be fine with the sessions topics .. next topic? 18:47:03 topol, I know a place 18:47:09 stevemar: ++ 18:47:10 o 18:47:12 atiwari, I have, and, while I like the concept, I think only LDAP really has the mechanism to enforce an attribute level approach. 18:47:14 ya know, before we get off-topic! 18:47:17 gyee++ hook me up 18:47:20 #topic Code reviews for icehouse blueprints 18:47:23 i'll follow up with people submitting sessions after the meeting 18:47:50 #link https://review.openstack.org/#/c/40692/ KDS service 18:48:17 Is this implementing a PKI server? Why wouldn't we use an existing one? If it's not PKI, why not use PKI? 18:48:19 dolphm, so different from the Grizzly Summit, when it was You, me and heckj doing all the sessions. I could get used to this level of participation 18:48:32 bknudson, long discussion on that 18:48:34 bknudson: no it's symettric 18:48:35 guys, can we please move forward with the shared-secret? 18:48:39 #link https://review.openstack.org/#/c/46771/ 18:48:39 not PKI, but symetric crypto 18:48:53 thanks fabiog, that is for shared secret? 18:49:02 sharing symetric keys for high through put messaging 18:49:03 stevemar, yes 18:49:10 I think we should be close on that one 18:49:17 yeah, we're close on it 18:49:18 ayoung, thanks. I think it not going to so complex to implement in Keystone (or Oslo) out of the box 18:49:22 I did all the requested changes so far :-) 18:50:11 bknudson: there was much discussion over the design for KDS, eventually it went symmetric mostly for the speed 18:50:35 ayoung, so once KDS is in, you expect default bind token? 18:50:46 fabiog, why should shared secret be stored in the clear? 18:50:55 I thought TLS/etc work by generating symmetric keys after PKI 18:50:58 gyee, completely different issues 18:51:00 gyee: no KDS has nothing to do with binding 18:51:10 ayoung, http://summit.openstack.org/cfp/details/255 did I cover everything? 18:51:17 bind token will require Kerberos or X509 support on the remote services, so it will be a rolling implementation 18:51:20 bknudson: it does 18:51:36 bknudson: the KDS design tracks closer to what kerberos does 18:51:45 but KDS an implementation of Kerberos no? 18:51:57 gyee: no, just same principals 18:52:04 bknudson, that is at transport layer, which MQ can use, but this is end to end message validity and then possibly encryption 18:52:19 gyee, no, it is like Kerberos, but Kerberos does much more. 18:52:56 It would have been easier to user Kerberos but that was deemed to high a bar to set for OpenStack undercloud setup 18:52:59 and PKI is too slow for end-to-end message validity and encryption? 18:53:06 dolphm, if ayoung is happy with my edits it can be moved back to approved. [post meeting likely] 18:53:18 morganfainberg: ack 18:53:28 morganfainberg, looks good to me. dolphm +1 18:53:33 bknudson, I was thinking SMIME 18:53:43 gyee, that is what we use for PKI tokens 18:53:45 morganfainberg: i didn't realize about the no edits policy, i'll review each individually as i schedule them 18:53:56 CMS is basically another term for SMIME 18:54:03 ayoung, right, SMIME is for message security 18:54:14 dolphm, hehe. i wouldn't have guessed except it was the way it worked. maybe you can edit them? not sure. 18:54:30 you mentioned securing MQ 18:54:37 that's why I was thinking SMIME 18:54:57 bknudson, topic has been hashed over fairly thoroughly. THere is an etherpad off the blueprint worth reading through 18:54:57 bknudson: the other problem with PKI is we would have to manage all those certificates and do signing, revocation, updating etc 18:55:13 lets all take another look at fabiog shared secret, it's close to being done 18:55:14 why would we manage them? there's already tools for it. 18:55:21 jamielennox, we are doing it for PKI tokens 18:55:25 at least we should be 18:55:34 gyee: no, in that case we only manage one cert 18:55:38 the one that does the signing 18:55:43 p.s. i discovered this recently https://wiki.openstack.org/wiki/KeystoneUseCases 18:55:56 this would need to manage a certificate for every host that issues a message 18:56:01 dolphm, wow 18:56:01 bknudson, https://wiki.openstack.org/wiki/MessageSecurity#A_Key_Distribution_Server_in_Keystone 18:56:18 that would be fun to version control 18:56:40 #topic open discussion 18:56:47 only a few minutes left 18:56:48 code review use case -> code review api (if necessary) -> code review implementation of new feature :P 18:56:54 dolphm isnt that way out of date 18:56:58 topol: very 18:57:23 based on what's written, i'm guessing it was from spring 2012 18:57:30 most of it, anyway 18:57:38 ~essex 18:57:54 predates me. 18:58:07 sounds about right. take it to the pawnstars show to get a history lesson on it 18:58:13 lol 18:58:16 jamielonnx did someone request Keystone to run CA service from the ML? 18:58:20 i don't know how to get the history out of the wiki, if there is any 18:58:24 dolphm, bknudson: i've added the strings only interface to API discovery, can you have another look: https://review.openstack.org/#/c/38414/ 18:58:38 dolphm, i was trying to do that, but i think the wikis have migrated right 18:58:39 everyone else as well ^ but we were discussion this yesterday 18:58:45 gyee, I think for a dev CA we can look into using certmaster 18:58:52 https://fedorahosted.org/certmaster/ 18:59:12 wouldn't use it in production, I'd recommend dogtag for that 18:59:21 gyee: it has been suggested in the past, i don't like it without a REALLY good reason 18:59:24 it would be interesting to have certmaster configured by devstack 18:59:31 i'd prefer to see barbican do that 18:59:40