18:00:30 <heckj> #startmeeting
18:00:31 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:15 <heckj> #topic agenda at http://wiki.openstack.org/Meetings/KeystoneMeeting
18:01:42 <heckj> We're closing in on the feature freeze end of this week
18:02:05 <heckj> There's a few reviews up that need some lovin'
18:02:41 <heckj> dolphm, ayoung - if you can take a few minutes over the next two days and review all the open keystone reviews
18:02:59 <heckj> dolphm has a V3 API initial cut up for review
18:03:09 <heckj> looking pretty good.
18:03:37 <heckj> 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 <ayoung> will do
18:04:00 <ayoung> if he can get an excpetion on policy, can I get one on token revocations?
18:04:48 <heckj> 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 <heckj> ayoung: however
18:05:19 <heckj> 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 <ayoung> 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 <dolphm> o/
18:05:44 <mnewby> ayoung: seconded.
18:05:48 <dolphm> ayoung: pki revocation?
18:05:58 <ayoung> mnewby is helping me out, and we've got PKI revocation scared....
18:06:00 <heckj> 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 <ayoung> heckj, we can have it ready for review in the next couple of days, I think
18:06:26 <mnewby> heckj: I concur
18:06:34 <heckj> sounds good
18:06:56 <ayoung> heckj, should we go through and triage the open requests?
18:07:14 <ayoung> https://review.openstack.org/#/q/status:open+project:openstack/keystone,n,z
18:08:25 <heckj> ayoung: do you have a question about one? (not sure what to triage there…)
18:08:42 <ayoung> no...
18:08:55 <ayoung> I'll take a look offline
18:08:58 <heckj> kk
18:09:23 <heckj> #topic Grizzly Design Summit
18:09:26 <heckj> #link http://etherpad.openstack.org/GrizzlyKeystoneSessions
18:09:54 <heckj> We have some suggestions for topics in Grizzly design summit
18:10:31 <heckj> TTX is getting set up with general scheduling - keystone meetings will be mostly on monday, some tuesday
18:11:05 <heckj> 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 <heckj> Other than what's the etherpad today - are there any burning topics folks want to bring up at the summit?
18:11:53 <ayoung> 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 <heckj> 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 <heckj> 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 <ayoung> should we have an intro to Keystone session for the rest of the people there?
18:13:11 <heckj> ayoung: would be a very good idea
18:13:36 <ayoung> I gave a presentation to the Boston user group.  My slides are here:
18:13:49 <ayoung> http://adam.younglogic.com/presentations/KeystoneFolsom/
18:14:02 <heckj> 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 <heckj> #link http://adam.younglogic.com/presentations/KeystoneFolsom/
18:14:27 <ayoung> 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 <mnewby> 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 <heckj> ayoung: nice - I'll steal some of that if it's OK with you
18:14:50 <dolphm> 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 <ayoung> heckj, I can send you a link to the original Open offic presentation
18:14:59 <heckj> mnewby: sounds like an excellent brainstorming session
18:15:14 <mnewby> heckj: I would agree.
18:15:32 <dolphm> mnewby: please share! i'm making some such changes
18:15:53 <heckj> dolphm: I think it matched the overall the growth
18:15:56 <mnewby> dolphm: Share here?  Or discuss offlin?
18:16:01 <ayoung> http://etherpad.openstack.org/GrizzlyKeystoneSessions
18:16:09 <ayoung> mnewby, ^^
18:16:16 <heckj> mnewby: if you've got some early thoughts, feel free to start some email threads too
18:16:16 <mnewby> ok
18:16:18 <heckj> (or here too)
18:16:25 <dolphm> mnewby: up to you -- i just want to know what's on your mind
18:17:00 <ayoung> 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 <ayoung> users come out of LDAP,  projects and roles are local.  Users are read only.  Authentication uses LDAP.
18:17:33 <heckj> ayoung: that's coming out as a very common use case
18:17:33 <mnewby> 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 <dolphm> ayoung: so, a more granular breakdown of catalog | identity | tokens | policy
18:18:10 <ayoung> dolphm, probably more like the ability to split identity
18:18:25 <ayoung> maybe authZ vs authN
18:18:37 <mnewby> +1000
18:18:49 <mnewby> I'd like to see a cleaner separation between z and n.
18:19:35 <mnewby> They are really separate contexts, and mixing them makes it difficult to ensure quality code.
18:19:40 <dolphm> policy is theoretically Z, and identity is theoretically N -- what do you want to move? roles?
18:20:14 <dolphm> in v3: identity = domains, projects, users, credentials & roles
18:20:36 <ayoung> dolphm, probably users
18:20:56 <dolphm> ayoung: out of identity?
18:21:09 <ayoung> dolphm, I think more the ability to delegate it from identity.
18:21:20 <ayoung> either it is going to be in the same DB as the rest or
18:21:22 <heckj> 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 <ayoung> it is going to be read only from remote
18:21:36 <ayoung> heckj, hence the session to brainstorm
18:21:46 <ayoung> we don't need to solve it now.
18:22:02 <heckj> 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 <heckj> cool - yeah
18:22:25 <ayoung> Actually, that was what I had in minde with the AD integration.  Maybe we should merge that session.
18:23:21 <heckj> ayoung: yeah - I'd like to come into that session with some concrete work in hand to inform the discussion
18:23:27 <heckj> (that's my plan, anyway)
18:23:50 <ayoung> 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 <dolphm> ayoung: policies for not-keystone?
18:25:01 <ayoung> dolphm, yes
18:25:01 <heckj> ayoung: That was what I'd asked liemn to help pull together, but he's disappeared this past few weeks
18:25:05 <dolphm> ayoung: i mean, other projects are already publishing precanned policy.json's
18:25:19 <ayoung> liemn is off of Openstack, I thought.
18:25:24 <dolphm> heckj: ^^
18:25:39 <heckj> ayoung, dolphm : I wanted to pull them all together and get at least a basic suggested deployment documented
18:25:58 <heckj> dolphm: yeah - got that note
18:26:16 <ayoung> 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 <primeministerp> heckj: that's what i'm talking about
18:26:42 <dolphm> 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 <mnewby> dolphm: agreed
18:27:09 <dolphm> 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 <ayoung> 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 <primeministerp> heckj: ayoung: please feel free to include me on any AD dicussions
18:27:55 <heckj> 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 <dolphm> heckj: can we just point to a higher level doc at openstack.org?
18:28:20 <heckj> primeministerp: so far, they
18:28:28 <dolphm> heckj: maybe a specific section
18:28:30 <ayoung> 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 <dolphm> of something
18:28:36 <dolphm> which we can write :P
18:28:39 <primeministerp> haha
18:28:41 <mnewby> heckj, dolphm: An RFC for how to do policy, without getting into specifics?
18:28:44 <heckj> primeministerp: they've been happening (or not - all quiet) in openstack-operators mailing list, and discussions here in IRC
18:29:15 <heckj> 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 <mnewby> heckj: +1
18:29:31 <heckj> I don't want it to be "keystone docs" , but "how to use Keystone in Openstack" docs
18:29:53 <primeministerp> heckj: well feel free to tap me as a resource
18:29:57 <primeministerp> if i can help i will
18:29:59 <heckj> primeministerp: will do, thank you
18:30:14 <mnewby> 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 <ayoung> 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 <ayoung> We also probably need to identify where it would be useful to have keystone developers listening in on other sessions.
18:31:43 <ayoung> "Intel Prep of the Battlefield" if you forgive the Army term
18:32:12 <dolphm> ayoung: that would be awesome
18:32:29 <heckj> ayoung: +1
18:32:53 <heckj> 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 <heckj> 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 <ayoung> yeah, I am guessing that it is going to be last minute.
18:33:14 <primeministerp> heckj: may I ask a question?  How formal is the discussion around AD?
18:33:14 <dolphm> 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 <heckj> #topic open discussion
18:33:43 <dolphm> So, even though its a Quantum session, it's about authz, so "relevant projects: Keystone"
18:33:51 <ayoung> 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 <primeministerp> heckj: did you mention any of it to any msft people you may have met at meetups in seatle?
18:33:57 <heckj> 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 <primeministerp> heckj: simple because it's part of the discussion here
18:34:42 <primeministerp> as work they are looking to do for Grizzley
18:34:49 <dolphm> 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 <heckj> 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 <ayoung> dolphm, nah, I mean the LDAP stuff I was talking about aboce
18:35:12 <primeministerp> heckj: I believe you met yigal
18:35:13 <ayoung> above.
18:35:55 <heckj> primeministerp: could easily have - I don't always remember everyone I meet there I'm afraid :-)
18:36:03 <primeministerp> heckj: we can discuss more off meeting if interested, but I think it would be worth while to sync up
18:36:27 <heckj> primeministerp: sure, happy to
18:36:40 <primeministerp> heckj: and make sure my mgmt is planning on duplicating existing efforts
18:36:56 <heckj> 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 <primeministerp> 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 <primeministerp> heckj: to speed efforts
18:38:11 <heckj> (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 <primeministerp> *nod*
18:38:43 <primeministerp> anyway thx for the time
18:39:43 <heckj> np
18:40:51 <ayoung> I wonder if we can get the folks that did that Federation proof-of-concept to present
18:40:59 <ayoung> I'd like to understand it a little better.
18:41:03 <heckj> ayoung: who did that?
18:41:12 <ayoung> looking
18:42:03 <ayoung> "David Chadwick" <d.w.chadwick@kent.ac.uk>
18:42:09 <ayoung> Subject: Federated Access to Keystone
18:42:38 <heckj> ayoung: let's definitely see if we can get him to talk about it!
18:43:34 <ayoung> I think what they have done is removed tokens, and used SAML for all services.
18:44:08 <heckj> ayoung: did they make their own auth_… middleware for other openstack services?
18:44:09 <ayoung> There are four docs in drop box
18:44:19 <heckj> ayoung: link?
18:44:31 <ayoung> heckj, damned if I know,  I am not signing up for a drop box account just tored their docs!
18:44:37 <ayoung> 1 sec
18:44:37 <heckj> :-)
18:44:41 <ayoung> http://dl.dropbox.com/u/44986510/Adding%20federated%20access%20to%20OpenStack%201.pdf
18:44:41 <ayoung> http://dl.dropbox.com/u/44986510/Client%20Connection%20API%20v1.pdf
18:44:41 <ayoung> http://dl.dropbox.com/u/44986510/Federated%20Middleware%20Services-v1.pdf
18:44:41 <ayoung> http://dl.dropbox.com/u/44986510/UserGuide.pdf
18:45:29 <heckj> yeah - they definitely did their own middleware
18:45:32 <ayoung> ah..loks like I can read them now
18:46:04 <heckj> specs mostly, description of operation
18:46:13 <ayoung> I think it is their own middleware...and that leaves the question of how they do  service catalog support
18:46:47 <heckj> yeah - I presume they're embedding it somewhere, but lord knows where
18:47:06 <heckj> ayoung: I'm mostly interested in their driving use cases that resulted in this implementation
18:47:43 <ayoung> heckj, so we can have that integrated in to the Federation session
18:48:14 <heckj> ayoung: yeah
18:50:19 <ayoung> One thing I am surprised we have not been bugged about is providing a store for user preferences from the WebUI.
18:52:13 <heckj> ayoung: so far they (horizon folks) have been stashing them into session cookies and keeping it pretty light
18:52:29 <ayoung> OK...well, if they don't ask, we won't offer
18:52:32 <heckj> :-)
18:52:43 <heckj> we've got enough to pull off with credentials :-)
18:53:08 <heckj> Anyone have other topics? I need to kick out into other meetings...
18:54:38 <mnewby> nothing from me.
18:54:47 <ayoung> I need to get back to PKI revocation...and so does mnewby
18:54:53 <ayoung> :)
18:54:56 <dolphm> 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 <heckj> dolphm: I wasn't entirely sure what credentials needed there - so fundamentally, I don't know
18:55:46 <dolphm> 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 <ayoung> 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 <heckj> 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 <heckj> ayoung: what's your preference?
18:57:40 <dolphm> heckj: i think they should both just be serialized blobs then
18:57:54 <heckj> dolphm: kk
18:58:09 <heckj> I need to skip out guys - be online later...
18:58:11 <heckj> #endmeeting