18:01:10 <heckj> #startmeeting keystone 18:01:10 <openstack> Meeting started Tue Sep 11 18:01:10 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:12 <openstack> The meeting name has been set to 'keystone' 18:01:16 * dolphm resumes dancing (for the meeting minutes) 18:01:25 <ayoung> \O/ 18:01:49 <ayoung> heckj, I added a couple items to the agenda 18:01:50 <heckj> nice 18:02:01 <heckj> ayoung: sure, what'cha got for today 18:02:12 <ayoung> I forgot...let me find the agenda 18:02:15 <heckj> I only had the prep for RC and related elements there 18:02:53 <ayoung> Moving auth_token middleware dependencies to openstack common 18:02:55 <dolphm> any rc blockers? 18:03:08 <ayoung> http://wiki.openstack.org/Meetings/KeystoneMeeting 18:03:32 <heckj> #link agenda : https://bugs.launchpad.net/python-keystoneclient/+bug/1031245 18:03:33 <uvirtbot> Launchpad bug 1031245 in python-keystoneclient "Get a User by Name" [High,Triaged] 18:03:36 <heckj> damnit 18:03:44 <dolphm> lol 18:03:45 <heckj> #link agenda http://wiki.openstack.org/Meetings/KeystoneMeeting 18:03:54 <heckj> can you tell I've been triaging bugs? 18:04:15 <heckj> re: https://launchpad.net/keystone/+milestone/folsom-rc1 18:04:33 <heckj> there's three bugs tagged against the RC1 release that aren't fully in 18:04:37 <heckj> only one is critical 18:05:09 <heckj> critical: https://bugs.launchpad.net/keystone/+bug/1041396 18:05:12 <ayoung> heckj, 1045962 is no RC worthy 18:05:30 <ayoung> 1041396 has the fix enroute 18:05:32 <heckj> kk - removing milestone tag so ttx won't yell at us 18:05:45 <dolphm> hmm 18:05:52 <dolphm> oh it's just the test failure 18:05:56 <dolphm> /agree 18:05:58 <heckj> last is https://bugs.launchpad.net/keystone/+bug/1022614 - wishlist. mnewby working on it 18:06:00 <uvirtbot> Launchpad bug 1022614 in keystone "Document Memcache server needed system time setting" [Wishlist,In progress] 18:06:29 <mnewby> heckj: Is there anything more required? 18:06:30 <heckj> the document update is in, mnewby asked a question I wanted to bring up here 18:06:35 <ayoung> 1022614 is documentation. mnewby are you going to get that done? https://bugs.launchpad.net/bugs/1022614 18:06:48 <ayoung> I type too slow 18:06:50 <mnewby> ayoung: There is a change that implements the doc fix. 18:06:54 <heckj> ayoung: the docs are done and I think in 18:06:58 * ttx yells anyway 18:07:13 <mnewby> heckj: Neeeds approval 18:07:17 * heckj duck tapes over ttx's mouth for this meeting 18:07:55 <ttx> mmmh. 18:08:09 <ttx> mm! mmh. 18:08:10 * ayoung reviewing now 18:08:10 * dolphm summons meetingbouncerbot 18:08:25 <mnewby> in case a keystone core member wants to +2 and approve: https://review.openstack.org/#/c/12605/ 18:09:07 <dolphm> -1 minor nit 18:09:20 <mnewby> ttx: And yes, I will create a separate bug. 18:09:25 <mnewby> dolphm: ok 18:09:32 <ayoung> dolphm, the content of https://review.openstack.org/#/c/12605/1/doc/source/configuration.rst looks good, but you are the format nit-picker-extroidanair...give it a look-see? 18:09:40 * ayoung too slow again 18:09:43 * markwash lines up to ask a question in the open discussion section 18:09:54 <ttx> mnewby: mmhmm mm. 18:10:05 <dolphm> ayoung: lol 18:11:43 <mnewby> dolphm: I don't see the nit? 18:11:44 <ayoung> heckj, so the recently merged patches for LDAP. I'd like to rc those as well 18:12:01 <heckj> ayoung: +1 on those changes 18:12:12 <heckj> ayoung: I think they've very worthwhile to get into RC 18:12:20 <ayoung> Those IDs are: (drumroll) 18:12:23 * heckj pulls off ttx's duct tape to see if he has an opinion there 18:12:31 <ayoung> https://code.launchpad.net/bugs/983304 18:12:34 <uvirtbot> Launchpad bug 983304 in keystone "Implementation of tenant,user,role list functions for ldap" [Medium,Fix committed] 18:12:50 <ayoung> https://code.launchpad.net/bugs/1047848 18:12:51 <uvirtbot> Launchpad bug 1047848 in keystone "LDAP identity Backend breaks on unscoped token" [Undecided,Fix committed] 18:12:55 <heckj> ayoung: I'd already linked that first against RC1 18:13:11 <heckj> just linked the second 18:13:14 * ttx looks 18:13:15 <ayoung> ah..cool 18:13:21 <dolphm> ayoung: mnewby: reviewed 18:13:34 <ayoung> https://code.launchpad.net/bugs/980085 possible 18:13:35 <uvirtbot> Launchpad bug 980085 in keystone "ldap Identity backend TenantAPI bugs" [Medium,In progress] 18:13:48 <ttx> ayoung, heckj: if they are fixCommitted they will be in RC1 18:13:59 <heckj> excellent - thats what we're after 18:14:00 <ayoung> ttx, cool 18:14:06 <ttx> ayoung: we didn't branch yet 18:14:09 <ayoung> when is the cut off? 18:14:13 <ttx> ayoung: we branch just before RC1 18:14:21 <heckj> Anything else on the RC1 lists that folks want to bring up? 18:14:29 <heckj> Otherwise I'll move onto the next topics... 18:14:52 <ttx> ayoung: i.e. we bump the version on master and cut the release branch from the previous commit 18:15:04 <ttx> then tag rc1 on release branch. 18:15:09 <ayoung> ttx, when is that happening? 18:15:25 <ttx> ayoung: when your buglist is empty and the PTL signs off on it 18:15:33 <ayoung> ah 18:15:42 * ttx puts the tape back on 18:15:48 <heckj> ayoung: soon, I'm hoping. 18:15:52 <heckj> #topic Moving auth_token middleware dependencies to openstack common 18:15:55 <ayoung> heckj, please define soon 18:16:05 <ayoung> I want to know if I have time to push through the Attribute changes 18:16:08 <ttx> ayoung: ideally in te next three days 18:16:25 <heckj> ayoung: I don't want to pop in any more non-critical bugs, and would like to wrap things in wihtin the next 24-48 hours if we can 18:16:49 <ayoung> https://review.openstack.org/#/c/12752/ is borderline. Without it, you can't add users with an LDAP backend 18:16:54 <heckj> if something blocker-ish came up, would be happy to reconsider, but I think we're pretty darned good for lockdown 18:17:06 <heckj> ah hell, that would be nice... 18:17:55 <heckj> dolphm: what do you think re: priority of https://bugs.launchpad.net/keystone/+bug/980085 18:17:57 <uvirtbot> Launchpad bug 980085 in keystone "ldap Identity backend TenantAPI bugs" [Medium,In progress] 18:18:21 <heckj> it's currently set to medium - with that priority, I'd assert we shouldn't pull it in. I wonder if it shouldn't be higher though 18:18:46 <ayoung> I think that he didn't yell loudly enough in the bug report. 18:18:56 <dolphm> hmm 18:19:07 <dolphm> there's like 3 bugs in this bug 18:19:24 <dolphm> 4 18:19:30 <heckj> yeah - it's a bit tricky, but the core that I think is valuable is being able to add users to LDAP 18:20:17 <dolphm> which change fixes that, specifically? 18:20:29 <dolphm> the description schema change? 18:20:34 <heckj> dolphm: is borderline. Without it, you can't add users with an LDAP backend 18:20:45 <heckj> dolphm: sorry = https://review.openstack.org/#/c/12752/ 18:20:59 <ayoung> 'email': 'mail', on line 336, as well as 18:21:32 <ayoung> the line 344 entry, which is what I thought boden was talking about in his comment 18:21:52 <ayoung> you can see that tenant_id is in the attribute_ignore list 18:21:55 <ayoung> and it worked for me 18:22:04 <ayoung> with out the change to the TenantAPI, you can't add tenants 18:22:24 <ayoung> lines 469 470 18:22:41 <dolphm> why the email mapping commented out? 18:22:45 <dolphm> why was* 18:23:08 <ayoung> dolphm, to be honest? Probably ignorance on my part way back when....I think I ported it over that way 18:23:12 <ayoung> let me look 18:23:43 <dolphm> just want to make sure it's not linked to another bug fix or something lol 18:25:09 <ayoung> so the value in LDAP is mail, but in Keystone we call it email. 18:25:26 <ayoung> LDAP should have left it as email, but the RFC is approved, so we can't argue with it 18:25:54 <ayoung> At one point we were going to drop email all together, which is why I think it was commented out 18:26:07 <dolphm> +1 in favor of dropping email lol 18:26:15 <heckj> heh 18:26:21 <ayoung> not for rc-1...or folsom for that matter 18:26:28 <dolphm> :) 18:26:45 <mnewby> dolphm: stupid question - how to execute doc build? 18:26:46 <heckj> sounds like this one needs a little more looking 18:26:47 <ayoung> the tenant changes are more important, 18:26:55 <ayoung> mnewby, use make... 18:26:58 <ayoung> I'll post 18:27:04 <mnewby> ah, really stupid question. 18:27:07 <mnewby> thank you 18:27:13 <ayoung> mnewby, cd doc 18:27:14 <ayoung> make 18:27:20 <ayoung> gives you a list of targets 18:27:25 <ayoung> I tend to test with html 18:27:27 <heckj> dolphm: any thoughts from what you've seen on bug priority? I think it would look good/nicely reactive if we kicked this up, but it means pushing to get this nailed and correct in the next 48 hours 18:27:29 <ayoung> so make html 18:27:45 <ayoung> and then view the generated doc using the browser 18:27:49 <dolphm> mnewby: python setup.py build_sphinx 18:27:56 <heckj> and I'd really like to see that review have assocaited tests to prove the backend is working... 18:28:09 <ayoung> heckj, a test would be meaningless 18:28:24 <ayoung> it is not something we would do with fakeldap 18:28:32 <heckj> ah, ok 18:28:39 <ayoung> and the test against live LDAP needs a live server 18:29:01 <ayoung> so what I would like is to get LDAP support into devstack, so more people can test out the LDAP back end.... 18:29:25 <ayoung> But I haven't put the time into it yet. I need an intern 18:30:45 <heckj> heh 18:30:48 <ayoung> the tenant changes are probably more important 18:31:11 <ayoung> as you cannot add a tenant without them. WIthout the email change, you can add a user, you just will get an error if you try to set the email addres 18:31:14 <ayoung> s 18:31:32 <dolphm> need to fix that 18:31:40 <heckj> dolphm: unless you object, I'm going to mark this bug as crticial and tap against RC1 18:31:45 <dolphm> heckj: agree 18:31:49 <ayoung> cool 18:31:53 <heckj> done 18:32:00 <heckj> Okay - next topic 18:32:02 <heckj> #topic Moving auth_token middleware dependencies to openstack common 18:32:10 <ayoung> I'll retest my change, but I think it is sufficient 18:32:43 <ayoung> heckj, posted the proposal to the mailing list for auth_token 18:33:22 <ayoung> looks like the feed back is that it is the right thing to do. What is the time frame? 18:33:27 <heckj> ayoung: I responded there - basically, I think it's pretty reasonable if we can get relatively fast changes made in through openstack-common. Are either of dolphm or ayoung core in that project? 18:33:30 <dolphm> shouldn't be any issues with auth_token config, right? 18:33:47 <ayoung> no, but markmc is PTL, and I work for him 18:33:49 <dolphm> i'm not 18:34:08 <heckj> ayoung: timeframe: I'd ideally like to do that at the start of grizzly 18:34:16 <ayoung> he's just off PTO, and bogged down in email, guessing he has not got to it yet 18:34:45 <ayoung> heckj, the thing is, what about naming? How does common get deployed? 18:34:49 <heckj> openstack-common is going to be keeping with copy-paste of code for a while - no packages though, so this doesn't entirely answer the packaging need that folks are asking for 18:35:00 <heckj> ayoung: yeah - just addressing that 18:35:03 <ayoung> yes, that is what i meant 18:35:14 <ayoung> Thus: Grizzly. OK 18:35:32 <dolphm> (why don't we use git submodules for things like openstack common? or just package openstack-common?) 18:35:40 <heckj> The big need is for the packages to be reasonably well encapsulated and the packagers informed/helped so that we can produce a package that's just auth_otoken and relevant dependencies in code 18:35:46 <ayoung> dolphm, bite your tongue...er fingers? 18:36:02 <ayoung> er... 18:36:11 <ayoung> well, I agree on the package openstack-common statement 18:36:30 <ayoung> just not on the git submodules....therein lies madness and Cthulu and stuff 18:36:59 <heckj> ayoung: When we move that code into different directories, then I think we can help the packagers make even an auth_token package or something (hell, I can submit the patch to debian). Don't know the RPM making world, but I suspect ayoung would be able to help there... 18:37:16 <dolphm> ayoung: never had an issue with them, but i've only used them on personal projects 18:37:17 <ayoung> we have packagers that will be involved 18:37:18 <heckj> that would cover the big request/need that we're seeing 18:38:12 <heckj> I'll reach out to the packaging crews on IRC and email today and let them know what we're thinking/planning and when, see what I get back 18:38:19 <ayoung> since that is Grizzly, we can postpone any other discussion, I just wanted to make sure it was not something I needed to do for Folsom 18:38:32 <heckj> #action heckj to reach out to openstack-packaging to consult re: auth_token package for easier deployment 18:38:42 <heckj> #topic recent LDAP changes from my (ayoung) perspective 18:38:50 <ayoung> heckj, we covered that 18:38:57 <ayoung> we can move on to v3 18:39:02 <heckj> #topic v3 reviews 18:39:10 * heckj has been bad and not done much there 18:39:29 <dolphm> i know i have some outstanding comments i need to address on the server side 18:39:40 <dolphm> and i just proposed a few changes to the client today 18:40:04 <heckj> There was a bug report today that was related to V3 - basically should we support enable/disable on services and/or endpoints 18:40:27 <dolphm> fair enough 18:40:38 <ayoung> Why doesn't https://review.openstack.org/#/c/12058/ show what depends on it? 18:41:01 <dolphm> ayoung: not sure ... it did 18:41:18 <ayoung> Yeah, I got to this link from things that needed it 18:41:33 <heckj> no idea 18:41:35 <ayoung> https://review.openstack.org/#/c/12106/3 18:41:56 <ayoung> Which is where I saw "[Outdated]" as well...I assume that is a related issue 18:42:17 <dolphm> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:feature/keystone-v3,n,z 18:42:42 <dolphm> server side changes ^ 18:42:44 <dolphm> client changes: https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:feature/keystone-v3,n,z 18:42:53 <heckj> (I look at them together: https://review.openstack.org/#/q/status:open+branch:feature/keystone-v3,n,z) 18:44:38 <heckj> any questions, or just admonishments that we need to do more review work? 18:44:54 <dolphm> ayoung: i've run into a few odd behaviors in git-review trying to work with the feature branch, filed a bug for one i was able to reproduce .. 18:45:19 <dolphm> review and file complaints please 18:45:38 <heckj> dolphm, ayoung - any bugs show stopper there? 18:45:46 <heckj> kk 18:45:53 <ayoung> heckj, no, just want to make sure we keep making progress 18:45:55 <heckj> #action all us lazy mofo's need to do more reviews 18:46:08 <heckj> #topic Summit sessions 18:46:12 <ayoung> With the limited number of reviewers, might I suggest that 18:46:24 <ayoung> we go with 1 core and one non core for the v3 chagnes? 18:46:35 <ayoung> assuming dolph reads his own code? 18:46:41 * dolphm waves 18:46:47 <heckj> ayoung: this is important enough that I think we really need our combined attention on it 18:47:00 * heckj promises to do more reviews ASAP to keep this flowing 18:47:04 <ayoung> heckj, so both you and I need to approve. Got it 18:47:21 <ayoung> I just want mnewby and gyee to feel motivated to continue to contribute 18:47:40 <dolphm> ayoung: heckj: i would also encourage everyone to checkout the client and server changes and actually play with it (interactive or write a script or whatever) 18:47:41 <gyee> I am reviewing some of them 18:47:49 <heckj> ayoung: their reviews are absolutely useful and important 18:48:11 <gyee> I will be doing the rest probably today 18:48:11 <ayoung> dolphm, is there an easy way to get the whole branch? 18:48:19 <dolphm> gyee: thanks! appreciate your feedback (haven't had time to respond yet) 18:48:23 <heckj> dolphm: with the pending reviews, is there an easy way to get the whole set and "try it out"? 18:48:27 <mnewby> I'm afraid I'm a bit resource-constrained at the moment 18:48:32 <dolphm> ayoung: i guess checkout the last dependency 18:48:32 <heckj> ayoung: heh, yeah 18:48:58 <dolphm> https://review.openstack.org/#/c/12185/ 18:49:01 <mnewby> Are all the reviews of equal importance? Were I to find some spare cycles, I'd like to konw what to work on. 18:49:04 <heckj> I'll give it a shot later today and send an email about how to get it all and try it out 18:49:16 <heckj> mnewby: they're all tightly connected I'm afraid 18:49:18 <dolphm> give me til the end of the day to get some more client changes into review 18:49:25 <heckj> dolphm: no problem 18:49:33 <mnewby> heckj: understood 18:49:44 <heckj> er, summit sessions? 18:50:01 <heckj> I haven't posted any up as yet this year - we had an etherpad where we were making some notes on possible topics 18:50:09 <heckj> Anyone request sessions for the summit yet? 18:50:54 <dolphm> did we have a session on multifactor auth last summit? 18:51:13 <ayoung> dolphm, running git fetch https://ayoung@review.openstack.org/openstack/keystone refs/changes/85/12185/3 && git cherry-pick FETCH_HEAD just gets the last change 18:51:27 <dolphm> ayoung: don't choose cherry-pick then :) 18:51:27 <ayoung> heckj, I requested a federation session 18:51:37 <dolphm> ayoung: use checkout 18:51:39 <heckj> dolphm: we talked about that we wanted it, but that's all the farther it got. savak has tried to pop some blueprints, but nobody was focused on enabling and driving a design after 18:51:46 <ayoung> dolphm, that make too much sense 18:52:23 <dolphm> heckj: i want to understand the impact on v3 auth, ASAP... if any 18:52:28 <markwash> is anyone considering next steps on PKI? 18:52:52 <ayoung> dolphm, OK I see the hash. THat worked 18:52:56 <ayoung> markwash, oh yeah 18:53:08 <ayoung> markwash, I don't consider the blueprint completed yet 18:53:17 <ayoung> next up is external auth 18:53:29 <ayoung> so the wsgi REMOTE_USER gets set by the web container 18:53:41 <ayoung> that will allow using x509 or other auth to the server 18:53:47 <ayoung> also 18:54:04 <ayoung> earluy in the grizzly dev cycle, I want to switch the default to be PKI tokens from UUID tokens 18:54:23 <heckj> #topic open discussion 18:54:30 <heckj> markwash: I assume that was your question? 18:54:44 <dolphm> ayoung: grizzly day 1! 18:54:46 <ayoung> markwash, I also want to use PKI as the basis for Federation 18:54:46 <mnewby> ayoung: Let's make sure there's an associated doc change that discourages use of the memcache and kvs backends. 18:54:49 <dolphm> make it happen 18:54:50 <markwash> yeah, I have a use case for glance I was assuming would fit into pki 18:54:51 <heckj> markwash: is there something specific you wanted 18:55:00 <gyee> rate limit would be 1 for PKI token request :) 18:55:09 <markwash> specifically, I want a good way for glance to know that nova is talking to it on behalf of a given user 18:59:28 <markwash> and I guess what I'd really like to see, is that nova's token can be pki-based 18:59:28 <mnewby> markwash: uses existing machinery, more flexible. 18:59:28 <markwash> and the user's token can be uuid based :-) 18:59:28 <ayoung> markwash, +1 18:59:28 <mnewby> markwash: not sure what that buys 18:59:28 <ayoung> markwash, not on the UUID -1 that 18:59:28 <mnewby> markwash: requires keystone to do more work, which is what pki was designed to avoid. 18:59:28 <markwash> well, for my deployment I'm probably keeping uuid tokens around 18:59:38 <markwash> I don't want to require it to be uuid based 18:59:43 <markwash> just support either 19:00:00 <markwash> let the deployer decide if the middleware can do the extra work 19:00:03 <dolphm> that's the plan, i think we'd just like to make uuid's default out of the box / preferred 19:00:07 <ayoung> markwash, I think that will work based on the token length already 19:00:19 <ayoung> the change is to validate multiple tokens 19:00:20 <dolphm> make PKI* 19:00:22 <heckj> guys, I'm afraid I have to run to another meeting 19:00:25 <markwash> cool 19:00:27 <heckj> #endmeeting