18:03:01 <heckj> #startmeeting keystone
18:03:02 <openstack> Meeting started Tue Feb 26 18:03:01 2013 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:05 <openstack> The meeting name has been set to 'keystone'
18:03:05 <heckj> Ola all
18:03:57 <gyee> \o
18:04:25 <heckj> #topic burning issues
18:04:49 <heckj> So we've got RC1 cut, and very active work going on with trusts and pluggable authn mechanisms
18:05:04 <henrynash> rc1 is cut already?
18:05:11 <heckj> Did Thierry actually give us an extension on that?
18:05:36 <topol> Did pluggable authn make the cut?
18:05:46 <henrynash> oh, you mean "one of our issues is the rc1 cut", (I hope)
18:05:48 <heckj> henrynash: the blueprints are closed up for G3, and the trusts and authn shifted to RC1
18:05:55 <heckj> yeah, sorry - G3 was cut
18:06:03 <henrynash> heckj: phew
18:06:15 <heckj> I didn't get any formal word from Thierry - was hoping maybe one of you had on IRC
18:06:30 <topol> Whats the date for RC1 availability?
18:06:51 <heckj> topol: here's all that I know: #link https://wiki.openstack.org/wiki/GrizzlyReleaseSchedule
18:07:29 <heckj> At the RC meetings in a few hours, theirry wil propsoe and start to come up with an RC1 cut time to trial the first one. It's not yet nailed down on time
18:07:29 <gyee> heckj, pluggable auth is mostly there, probably some minor tweaks to dolphm's liking
18:07:44 <heckj> I'd guess he's aiming at Mar 14th
18:07:50 <dolphm> pluggable is technically merged, but plugins have some responsibility that i think needs to be extracted
18:08:18 <dolphm> heckj: march 14 seems really late?
18:08:23 <dolphm> heckj: for rc1 at least
18:08:43 <heckj> dolphm: I'm basing it on his release schedule - at least what I see
18:09:16 <dolphm> heckj: hmm... i just figured it'd be asap after feature freeze extensions were up, and critical bugs were fixed
18:09:28 <heckj> We've got two weeks until thierry is wanting RC cuts, that means any heavy lifting needs to be done now, and only cleanup & bugs over this next week
18:09:46 <heckj> dolphm: I think he's giving 2 weeks to get the critical bugs fixed in this schedule
18:09:51 <henrynash> heckj: I have some minor bug fixes…but only major one is to make sure that the keystone middleware understands a v3 token
18:10:09 <heckj> (at the last summit, the keystone topcs were directly against Thierry's sessions, so I could go see them)
18:10:47 <dolphm> that's nice of him :)
18:11:11 <heckj> henrynash: sounds good. We'll need to be very careful about heavy tweaks to auth_token - even though that's now in the client (which isn't aligned by the other release schedules), I'd prefer not to have the world pissed off at us for breaking a release :-)
18:11:12 <dolphm> definitely going to be a lot of client activity over the next month
18:11:18 <dolphm> which will hopefully reveal more bugs in keystone
18:11:32 <henrynash> heckj: I hear you
18:11:58 <heckj> wow - I am totally not used to this new wiki setup
18:12:26 <heckj> So - topics are pretty open. Nothing on the agenda anyway
18:12:29 <heckj> #topic open discussion
18:12:53 <heckj> I see dolphm and ayoung charging ahead on the dev channel
18:12:56 <dolphm> :)
18:13:03 <gyee> heckj, its too late to submit blueprint for the summit?
18:13:07 <ayoung> we can continue here
18:13:08 <gyee> is it?
18:13:22 <heckj> FWIW - quite some time ago I registred and coordinated a #keystone-dev channel on IRC if the signal-to-noise ration gets bad for y'all
18:13:24 <ayoung> gyee, only too late for the public talks
18:13:25 <dolphm> gyee: i think http://summit.openstack.org just opened a week or so ago
18:13:34 <heckj> gyee: internal is still very open
18:13:41 <ayoung> design topics for us are wide open
18:13:47 <henrynash> dolphm: fyi, you still have a keystone client change for v3 auth….probably good to get that in
18:13:49 <heckj> #link please submit design talks to http://summit.openstack.org
18:13:55 <dolphm> heckj: #openstack-keystone?
18:14:11 <dolphm> henrynash: definitely
18:14:19 <gyee> heckj, cool, I'll submit the blueprints then
18:14:30 <heckj> dolphm: would make more sense - this was before the other rooms existed, and monty arranged it for me
18:14:45 <dolphm> henrynash: that's now broken by recent spec changes, btw
18:14:57 <dachary> I'm interested in http://summit.openstack.org/cfp/details/6
18:15:04 <dolphm> heckj: -dev is going to die off :P
18:15:05 <henrynash> dolphm: yep, saw thta
18:15:34 <topol> I kind of like having a place where everyone was getting global knowledge
18:15:39 <heckj> dolphm: not surprised I guess
18:15:46 <heckj> we never used it, but wanted to mention it since it was there
18:16:13 <topol> People who I had know idea who they were would answer questions I was pestering dolphm or ayoung with
18:16:44 <heckj> If it still works, don't move from it
18:16:58 <heckj> topol: I agree - I still lurk and periodically try to answer things in #openstack
18:16:58 <dolphm> heckj: i'm more worried that we cause too much noise for other projects
18:17:07 <heckj> dolphm: don't be
18:17:15 <gyee> topol, lets revisit our LDAP strategy at the summit
18:17:16 <dolphm> heckj: -dev makes a lot of sense for cross project chatter
18:17:20 <dachary> have you heard of #openstack-101 ?
18:17:37 <heckj> saw something in the ML about it, but haven't been in there
18:17:39 <topol> gyee, Yes. I was planning on submitting something. Want to do it jointly?
18:18:13 <dolphm> topol: gyee: +1 make it a long session :)
18:18:27 <gyee> dolphm, oh yes
18:18:50 <dachary> FWIW, my focus is on storage and I'm trying to figure out how keystone + KMIP can help with volume encryption ( hence my interest in http://summit.openstack.org/cfp/details/6 )
18:18:52 <gyee> topol, I don't have anything specific right now, was thinking of a new LDAP auth plugin
18:19:00 <dolphm> review requested (not ayoung you're busy :P): https://review.openstack.org/#/c/22893/
18:19:08 <topol> gyee, exactly!!!
18:19:17 <topol> gyee, I will bring use cases!
18:19:46 <dolphm> dachary: we're on track for that with /v3/credentials
18:20:12 <ayoung> dolphm, does that need to be in before the meeting today?  I am afraid it is going to cause rebase issues with trusts.  I am willing to fix them afterwards if that is the case
18:20:18 <dachary> dolphm: good :_)
18:20:34 <ayoung> return self.auth['identity']['methods']  is not how the trust tests are calling.
18:20:34 <dolphm> gyee: with an ldap auth plugin, we might want to consider killing the ldap identity driver?
18:20:48 <ayoung> dolphm, nope
18:20:57 <ayoung> there is need for the LDAP identity as well
18:21:00 <gyee> dolphm, yes, we need a strategy for read-only LDAP use cases
18:21:23 <dolphm> gyee: we're struggling to support domains and groups and stuff as-is
18:21:40 <topol> ayoung +1, don't kill it.  Let just have good options for readonly ldap
18:21:49 <gyee> dolphm, understood, that's why we need to take a hard look at LDAP again
18:21:50 <ayoung> topol, yes
18:22:02 <topol> dolphm, sahdev will soon post code for group ldap
18:22:14 <dolphm> cool
18:22:31 <dolphm> i'm not saying we need to kill it, i'm just saying it sounds like an option for H+2 if we wanted to
18:22:45 <topol> dolphm, WIP is out there. He says he is 75% done. Will need some experts to review it though
18:23:15 <gyee> topol, I can review it if you want
18:23:29 <topol> gyee, excellent!
18:24:03 <topol> dolph, But I still agree we need to revisit for read only ldap
18:26:18 <gyee> topol, most enterprises won't let an app make changes to corporate LDAP, especially schema changes :)
18:26:46 <topol> gyee, Thats what I keep hearing.
18:27:04 <heckj> gyee, topol yep - probably the biggest informal complaint I've heard of our LDAP support to date
18:27:05 <gyee> in my past experience, 99.999% of the time we have to deal with read-only corporate LDAPs
18:28:14 <topol> Gyee, I agree.  We need to be able to handle that scenario very well.  In fact someone named Brant will contact you to see if your pluggable authentication will help us
18:28:42 <gyee> apache mod_ldap is a good example of how LDAP auth is supposed to be done
18:28:59 <topol> Gyee, Your 99% issue is my biggest headache to worry about for this year
18:28:59 <bknudson> gyee: I was wondering if I could use the pluggable authentication for ldap auth in grizzly
18:29:17 <gyee> topol, not 99%, its 99.999% :)
18:29:21 <topol> Gyee, bknudson= Brant :-)
18:30:03 <gyee> bknudson, lets work on porting apache mod_ldap
18:30:21 <bknudson> we've got projects here that ask how to use ldap with openstack and think that the ldap backend might be what they're looking for...
18:30:42 <bknudson> but these projects are going to be used in enterprise envs where the ldap backend won't work
18:31:09 <topol> Gyee, I'm hoping your pluggable authn will allow us to handle the use cases bknudson is seeing
18:31:19 <bknudson> gyee: you mean somehow using mod_ldap directly or re-implementing what it does in python?
18:31:19 <gyee> topol, it will
18:31:38 <gyee> bknudson, we need to port mod_ldap to python
18:31:54 <gyee> should be very straight forward
18:32:20 <bknudson> gyee: yes, I've already got something like it already in a branch. just not using pluggable auth modules.
18:32:59 <topol> So Gyee, you, bknudson, and I should setup sometime to discuss the options
18:33:30 <gyee> topol, bknudson, sounds good
18:33:49 <gyee> that's going to be good topic for the summit
18:33:55 <bknudson> bknudson: sure, whenever it's convenient.
18:34:03 <bknudson> gyee: sure, whenever it's convenient.
18:34:10 <topol> gyee, definitely!
18:36:20 <gyee> dolphm, what was the reason we got rid the "extra" attributes from the spec?
18:37:20 <dolphm> gyee: in which part? it was never in v2, and shouldn't have been in any v3 calls -- i'm a little lost on why it was intentionally added to auth though
18:37:45 <dolphm> gyee: it's always intended to be a feature of the sql driver -- nothing more
18:38:25 <gyee> dolphm, ok, I was under the impression extra is for deployment-specific attributes
18:38:27 <dolphm> gyee: all drivers should be capable of regurgitating arbitrary attributes (like description) on any entity without requiring explicit support for it -- sql does that by stashing them into the 'extra' column
18:38:51 <gyee> but "extra" is not carry over to the APIs?
18:39:04 <dolphm> gyee: no, it shouldn't be
18:39:49 <gyee> dolphm, reason I am asking is how to extend APIs without having to make schema changes
18:39:56 <dolphm> gyee: sql.DictBase.as_dict() packs unrecognized attributes into 'extra' and then sql.DictBase.to_dict() unpacks the 'extra' column into first-class attributes
18:40:29 <dolphm> gyee: depends on if you're asking from an api perspective or impl perspective
18:40:53 <henrynash> dolphm:…although I think we might filter them out in the sql driver when we unpack them (which is odd to me)
18:41:08 <gyee> dolphm, from API standpoint
18:41:24 <heckj> one of the things we probably need to serious consider is setting up a better API extension mechanism in Keystone - Nova has a decent (if complex) one, and there's clear need from these recurring requests
18:41:40 <gyee> heckj, absolutely agreed
18:41:50 <gyee> nova was asking for metadata
18:41:58 <gyee> metadata for the projects
18:42:15 <gyee> like quota classes, zone availability, etc
18:42:34 <heckj> yeah - quota is one that's been talked about for some time, but hasn't had effort against it yet
18:43:07 <henrynash> gyee: heck: +1 on all that
18:43:08 <heckj> things that are closely associated with either user identity or project "attributes" (not meaning the dwchadwick term there)
18:43:14 <gyee> heckj, we need to figure out how to carry arbitrary metadata for the resources
18:44:05 <dolphm> henrynash: not sure what you mean by filter them out -- v3 tests are exercising that in a few entities
18:44:10 <gyee> heckj, sounds like another good topic for the summit
18:44:40 <henrynash> dolphm: let me see if I can find the case I was looking at later…may be that I was reading it wrong
18:45:01 <henrynash> dolphm: excellent if we have tests that ensure it works
18:45:03 <dolphm> gyee: we can do it today -- add any attribute to a POST /projects requests and it'll work
18:45:10 <dolphm> gyee: we just don't return it on auth or anything
18:45:53 <gyee> dolphm, for auth, client can follow the links retrieve the full object right?
18:46:08 <gyee> I mean we do/will return the links
18:48:33 <dolphm> gyee: that's the goal
18:49:15 <dolphm> gyee: i don't think we do any cross-controller calls today, but the wrap_member methods are classmethods, so it should be trivial
18:50:26 <gyee> dolphm, sounds good
18:53:58 <dolphm> gyee: maybe refactor that to a link_member method since you may not need to wrap them with {"entity": {}}
18:54:47 <heckj> I'm going to wrap up the meeting...
18:54:50 <heckj> #endmeeting