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