18:00:30 #startmeeting 18:00:31 Meeting started Tue Aug 14 18:00:30 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:15 #topic agenda at http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:42 We're closing in on the feature freeze end of this week 18:02:05 There's a few reviews up that need some lovin' 18:02:41 dolphm, ayoung - if you can take a few minutes over the next two days and review all the open keystone reviews 18:02:59 dolphm has a V3 API initial cut up for review 18:03:09 looking pretty good. 18:03:37 I think we're going to want to continue to move that forward while we keep master relatively locked down with feature requests - any recommendations on how to accomplish this? 18:03:40 will do 18:04:00 if he can get an excpetion on policy, can I get one on token revocations? 18:04:48 ayoung: I was trying to avoid the exceptions and thinking about doing something with feature branches - not sure what mtaylor has as a possibility there 18:05:01 ayoung: however 18:05:19 ayoung: i think the token recovation addition is worthwhile to get added in during the freeze if we get it in soon 18:05:29 heckj, we are close, but I would rather get it right, than rush to get it in under the deadline, and then do a slew of bug fixes 18:05:42 o/ 18:05:44 ayoung: seconded. 18:05:48 ayoung: pki revocation? 18:05:58 mnewby is helping me out, and we've got PKI revocation scared.... 18:06:00 ayoung: totally with you - just do'nt want to add it one week prior to RC cut if we can avoid it 18:06:18 heckj, we can have it ready for review in the next couple of days, I think 18:06:26 heckj: I concur 18:06:34 sounds good 18:06:56 heckj, should we go through and triage the open requests? 18:07:14 https://review.openstack.org/#/q/status:open+project:openstack/keystone,n,z 18:08:25 ayoung: do you have a question about one? (not sure what to triage there…) 18:08:42 no... 18:08:55 I'll take a look offline 18:08:58 kk 18:09:23 #topic Grizzly Design Summit 18:09:26 #link http://etherpad.openstack.org/GrizzlyKeystoneSessions 18:09:54 We have some suggestions for topics in Grizzly design summit 18:10:31 TTX is getting set up with general scheduling - keystone meetings will be mostly on monday, some tuesday 18:11:05 Last summit I set (almost) all the sessions - this time through I'm going to open it up to y'all to suggest and I'll help schedule coordinate the results 18:11:48 Other than what's the etherpad today - are there any burning topics folks want to bring up at the summit? 18:11:53 How well understood is Keystone by the community, and how attended do you think our sessions will be based on last time? 18:12:25 I think it's fairly poorly understood actually - many folks have deployment questions about it and "can I use it too…" assuming there are more backends than there are 18:12:52 Last summit, there were a few very vocal folks - but while there was significant attendance, there was little in the way of diverse feedback 18:12:54 should we have an intro to Keystone session for the rest of the people there? 18:13:11 ayoung: would be a very good idea 18:13:36 I gave a presentation to the Boston user group. My slides are here: 18:13:49 http://adam.younglogic.com/presentations/KeystoneFolsom/ 18:14:02 ayoung: we're screwed a bit by the scheduling - most of the general "intro to" workshops are concurrently scheduled with our first day 18:14:12 #link http://adam.younglogic.com/presentations/KeystoneFolsom/ 18:14:27 We can use that as the starting point. It is probably a good thing for us all to start on the same sheet of music WRT Keystone anyway 18:14:31 I haven't thought it out too much, but I would like to see some changes to keystone internals to make integration with non-sql backends less painful. 18:14:33 ayoung: nice - I'll steal some of that if it's OK with you 18:14:50 heckj: ayoung: folsom summit attendance was about double, on average, vs essex attendance, for keystone sessions (not sure how that compares to the size increase of the overall conference?) 18:14:55 heckj, I can send you a link to the original Open offic presentation 18:14:59 mnewby: sounds like an excellent brainstorming session 18:15:14 heckj: I would agree. 18:15:32 mnewby: please share! i'm making some such changes 18:15:53 dolphm: I think it matched the overall the growth 18:15:56 dolphm: Share here? Or discuss offlin? 18:16:01 http://etherpad.openstack.org/GrizzlyKeystoneSessions 18:16:09 mnewby, ^^ 18:16:16 mnewby: if you've got some early thoughts, feel free to start some email threads too 18:16:16 ok 18:16:18 (or here too) 18:16:25 mnewby: up to you -- i just want to know what's on your mind 18:17:00 dolphm, I suspect it is the case where there is some centralize auth server for the organization that is read only WRT openstack, but you need to keep group info local...hybrid LDAP SQL for example 18:17:33 users come out of LDAP, projects and roles are local. Users are read only. Authentication uses LDAP. 18:17:33 ayoung: that's coming out as a very common use case 18:17:33 Briefly, Keystone exposes a driver model for identity to aid in extensibility, but the way the driver is used is really only useful for an sql or memory-backed service. 18:17:53 ayoung: so, a more granular breakdown of catalog | identity | tokens | policy 18:18:10 dolphm, probably more like the ability to split identity 18:18:25 maybe authZ vs authN 18:18:37 +1000 18:18:49 I'd like to see a cleaner separation between z and n. 18:19:35 They are really separate contexts, and mixing them makes it difficult to ensure quality code. 18:19:40 policy is theoretically Z, and identity is theoretically N -- what do you want to move? roles? 18:20:14 in v3: identity = domains, projects, users, credentials & roles 18:20:36 dolphm, probably users 18:20:56 ayoung: out of identity? 18:21:09 dolphm, I think more the ability to delegate it from identity. 18:21:20 either it is going to be in the same DB as the rest or 18:21:22 ayoung: let's do this carefully - if at all. I think we need some hybrid backends here, but it's not clear how we should make that possible 18:21:26 it is going to be read only from remote 18:21:36 heckj, hence the session to brainstorm 18:21:46 we don't need to solve it now. 18:22:02 In particular, I want to see what we can do to allow roles and/or projects to come from groupings in read-only source (active directory LDAP) - right now it's just a freaking Identity backend, but it's all together reasonably 18:22:11 cool - yeah 18:22:25 Actually, that was what I had in minde with the AD integration. Maybe we should merge that session. 18:23:21 ayoung: yeah - I'd like to come into that session with some concrete work in hand to inform the discussion 18:23:27 (that's my plan, anyway) 18:23:50 related but different: once the policy mechanism is in place, will we need to provide som precanned policies to support common cases? 18:24:21 ayoung: policies for not-keystone? 18:25:01 dolphm, yes 18:25:01 ayoung: That was what I'd asked liemn to help pull together, but he's disappeared this past few weeks 18:25:05 ayoung: i mean, other projects are already publishing precanned policy.json's 18:25:19 liemn is off of Openstack, I thought. 18:25:24 heckj: ^^ 18:25:39 ayoung, dolphm : I wanted to pull them all together and get at least a basic suggested deployment documented 18:25:58 dolphm: yeah - got that note 18:26:16 dolphm, how about a session which is an over view of the policy mechanism, to include the current state at the start of grizzly development, and what is going to be expected in working with the other projects? 18:26:19 heckj: that's what i'm talking about 18:26:42 heckj: i don't think we should document much more than how to setup a policy for a service -- it's up to the service to provide the actual policy blob 18:27:06 dolphm: agreed 18:27:09 heckj: i don't want our docs to get into how-to-deploy-openstack, even though we're at the core of it 18:27:23 dolphm, yes...but, I think we also need to be prepared to answer other people's policies questions. It would be good if we were all on the same page. Train-the-trainer? 18:27:54 heckj: ayoung: please feel free to include me on any AD dicussions 18:27:55 dolphm, mnewby fair enough - but I think openstack as a global project *needs* that information, and some suggestions on how to solve some of those common issues will be coming from us 18:28:18 heckj: can we just point to a higher level doc at openstack.org? 18:28:20 primeministerp: so far, they 18:28:28 heckj: maybe a specific section 18:28:30 primeministerp, this is Summit planning. So we plan on kidnapping you there and duct taping you to a seat to answer the windows specific stuff. Or provide an alternate that we can kidnap 18:28:31 of something 18:28:36 which we can write :P 18:28:39 haha 18:28:41 heckj, dolphm: An RFC for how to do policy, without getting into specifics? 18:28:44 primeministerp: they've been happening (or not - all quiet) in openstack-operators mailing list, and discussions here in IRC 18:29:15 mnewby: I want to coordinate with someone doing genearl openstack docs (or just do it myself) to get that information genearlly available 18:29:25 heckj: +1 18:29:31 I don't want it to be "keystone docs" , but "how to use Keystone in Openstack" docs 18:29:53 heckj: well feel free to tap me as a resource 18:29:57 if i can help i will 18:29:59 primeministerp: will do, thank you 18:30:14 heckj: I think that's a good approach. That way service-specific issues can be documented but don't necessarily have to take keystone resources to do it. 18:30:42 so it sounds like we need to have two types of sessions, those for the rest of the openstack community, and then planning sessions for us 18:31:24 We also probably need to identify where it would be useful to have keystone developers listening in on other sessions. 18:31:43 "Intel Prep of the Battlefield" if you forgive the Army term 18:32:12 ayoung: that would be awesome 18:32:29 ayoung: +1 18:32:53 In the past, I've found that I had to do that in the week prior to the summit, because there wasn't general visibiltiy into potential sessions 18:33:07 I'll send an email to ttx and see what we can coordinate to make that easier to find out this time 18:33:08 yeah, I am guessing that it is going to be last minute. 18:33:14 heckj: may I ask a question? How formal is the discussion around AD? 18:33:14 ayoung: it'd be nice to have all session planner people throw some keywords into their session descriptions a list of "other relevant projects" or whatever 18:33:34 #topic open discussion 18:33:43 So, even though its a Quantum session, it's about authz, so "relevant projects: Keystone" 18:33:51 primeministerp, I was at first planning a break out session of it, but it looks like it makes sense to link in to a discussion about how to split identity out into readonly and writable segments 18:33:53 heckj: did you mention any of it to any msft people you may have met at meetups in seatle? 18:33:57 primeministerp: not terribly formal at this point - some questions in the past, notes from folks who've been implementing "Identity" backend/drivers 18:34:29 heckj: simple because it's part of the discussion here 18:34:42 as work they are looking to do for Grizzley 18:34:49 ayoung: i guess i'm lost on the need to split by read only / write required ... if you don't want write operations... don't implement them? and 501's get raised appropriately 18:34:59 primeministerp: with the local (seattle) meetups, only that there was some work going on there, but nothing specific got drawn out or brought up 18:35:11 dolphm, nah, I mean the LDAP stuff I was talking about aboce 18:35:12 heckj: I believe you met yigal 18:35:13 above. 18:35:55 primeministerp: could easily have - I don't always remember everyone I meet there I'm afraid :-) 18:36:03 heckj: we can discuss more off meeting if interested, but I think it would be worth while to sync up 18:36:27 primeministerp: sure, happy to 18:36:40 heckj: and make sure my mgmt is planning on duplicating existing efforts 18:36:56 primeministerp: I've been hesitant to drive any discussion until I have some time (or resources) to implement, but if folks are struggling to do that work, I want to make it happen and help there 18:37:48 heckj: well i have ad implemented and am a bit off from giving people access "today" but can easily arrange access to infrastructure 18:37:59 heckj: to speed efforts 18:38:11 (I'd planned for us to do that work this past release team, but didn't get the time to make it happen) 18:38:24 *nod* 18:38:43 anyway thx for the time 18:39:43 np 18:40:51 I wonder if we can get the folks that did that Federation proof-of-concept to present 18:40:59 I'd like to understand it a little better. 18:41:03 ayoung: who did that? 18:41:12 looking 18:42:03 "David Chadwick" 18:42:09 Subject: Federated Access to Keystone 18:42:38 ayoung: let's definitely see if we can get him to talk about it! 18:43:34 I think what they have done is removed tokens, and used SAML for all services. 18:44:08 ayoung: did they make their own auth_… middleware for other openstack services? 18:44:09 There are four docs in drop box 18:44:19 ayoung: link? 18:44:31 heckj, damned if I know, I am not signing up for a drop box account just tored their docs! 18:44:37 1 sec 18:44:37 :-) 18:44:41 http://dl.dropbox.com/u/44986510/Adding%20federated%20access%20to%20OpenStack%201.pdf 18:44:41 http://dl.dropbox.com/u/44986510/Client%20Connection%20API%20v1.pdf 18:44:41 http://dl.dropbox.com/u/44986510/Federated%20Middleware%20Services-v1.pdf 18:44:41 http://dl.dropbox.com/u/44986510/UserGuide.pdf 18:45:29 yeah - they definitely did their own middleware 18:45:32 ah..loks like I can read them now 18:46:04 specs mostly, description of operation 18:46:13 I think it is their own middleware...and that leaves the question of how they do service catalog support 18:46:47 yeah - I presume they're embedding it somewhere, but lord knows where 18:47:06 ayoung: I'm mostly interested in their driving use cases that resulted in this implementation 18:47:43 heckj, so we can have that integrated in to the Federation session 18:48:14 ayoung: yeah 18:50:19 One thing I am surprised we have not been bugged about is providing a store for user preferences from the WebUI. 18:52:13 ayoung: so far they (horizon folks) have been stashing them into session cookies and keeping it pretty light 18:52:29 OK...well, if they don't ask, we won't offer 18:52:32 :-) 18:52:43 we've got enough to pull off with credentials :-) 18:53:08 Anyone have other topics? I need to kick out into other meetings... 18:54:38 nothing from me. 18:54:47 I need to get back to PKI revocation...and so does mnewby 18:54:53 :) 18:54:56 heckj: quick api consistency Q: the two attributes Credential.data and Policy.policy should have the same attribute name, i'm thinking, and the spec is unclear whether Credential.data is actually supposed to be serialized or not? 18:55:39 dolphm: I wasn't entirely sure what credentials needed there - so fundamentally, I don't know 18:55:46 heckj: as i recall, the description describes Credential.data as a serialized blob, but it's just a deeper json tree in the example 18:56:26 BTW, on the V3 API, should we make it explicit that the client needs to send the "Content-Type:application/json" header 18:56:28 dolphm: I think the only hard example we really have are the EC2 credentials, and a desire to host SSH keys for logging into instances 18:57:37 ayoung: what's your preference? 18:57:40 heckj: i think they should both just be serialized blobs then 18:57:54 dolphm: kk 18:58:09 I need to skip out guys - be online later... 18:58:11 #endmeeting