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