18:00:52 <heckj> #startmeeting keystone
18:00:52 <openstack> Meeting started Tue Sep 25 18:00:52 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:54 <openstack> The meeting name has been set to 'keystone'
18:01:26 <heckj> agenda: http://wiki.openstack.org/Meetings/KeystoneMeeting
18:02:38 <heckj> Anything suggested for RC blockers?
18:02:59 <heckj> As of a few days ago, I hadn't seen anything - wanted to ask broadly though
18:03:06 <dolphm__> yes
18:03:12 <dolphm__> well, maybe
18:03:17 <heckj> bug?
18:03:20 <dolphm__> the comment at the end of https://bugs.launchpad.net/keystone/+bug/1046905
18:03:22 <uvirtbot> Launchpad bug 1046905 in keystone "Memcached Token Backend does not support list tokens" [Critical,Fix released]
18:03:32 * heckj reads
18:03:49 <dolphm__> i'm working to open a bug for it (so far, i've only reproduced it outside of keystone, against the memcache client directly): http://paste.openstack.org/raw/21112/
18:04:02 <dolphm__> in this case, i'
18:04:25 <heckj> that looks like a good one - agree it should RC block
18:04:36 <dolphm__> i'm not sure i understand how we've never seen this error before, as we have no protection against unicode keys (memcache requires ascii strings as keys)
18:04:59 <heckj> let's open a new bug with that last comment and mark it up - you want me to do that?
18:05:15 <dolphm__> anyway, i think the suggested fix in that bug needs to be applied across *all* calls to the memcache client
18:05:19 <dolphm__> doing it now
18:05:34 <heckj> I'd believe it
18:05:52 <ayoung> \O/
18:06:15 <heckj> howdy!
18:06:41 <heckj> ayoung: you got anything as a blocker for RC?
18:06:51 <ayoung> Nope
18:07:17 <ayoung> Agree that https://bugs.launchpad.net/keystone/+bug/1046905 should be
18:07:18 <uvirtbot> Launchpad bug 1046905 in keystone "Memcached Token Backend does not support list tokens" [Critical,Fix released]
18:07:53 <ayoung> but that comment at the end is probably not related to the earlier changes
18:07:57 <heckj> #action dolph to create new bug from comment #5 in https://bugs.launchpad.net/keystone/+bug/1046905  - mark it as RC blocker
18:08:03 <heckj> ayoung: yep
18:08:28 <heckj> Okay - topic switch, the controversial one
18:08:34 <heckj> #topic - where to put auth_token
18:08:50 <heckj> goal is to get it somewhere where it can be it's own package
18:08:58 <heckj> options - 1) put in keystoneclient
18:09:01 <heckj> 2) make a new repo for it
18:09:08 <heckj> 3) put in openstack-common
18:09:15 <heckj> 4) maybe others?
18:09:54 <heckj> ayoung: you were concerned about the dependencies that are needed for the PKI work  - suggestion for how/where to break this out so that all projects don't have to fully install keystone to get the code they need?
18:10:14 <dolphm__> opened bug 1056373
18:10:14 <uvirtbot> Launchpad bug 1056373 in keystone "memcache driver needs protection against non-string keys" [Undecided,New] https://launchpad.net/bugs/1056373
18:10:38 <ayoung> well, if people want just auth_token, they  should not be just copying the file around.  So first thing is we have to break them of the bad habits.
18:10:44 <gyee> +1 on 2)
18:10:59 <dolphm__> heckj: define package -- python package or distro package?
18:11:04 <ayoung> why do we need a new repo?  Python can't be that broken
18:11:25 <ayoung> there should be no problem with making multiple packages out of one git repo.
18:11:48 <heckj> dolphm__: new package meaning something at pypi and something that can be a separate distribution package (both)
18:12:00 <ayoung> why should there be a difference between python package and distro package?
18:12:16 <dolphm__> mtaylor explained why we need a seperate git repo on the mailing list
18:12:25 <heckj> ayoung: I've not seen a terribly clean way to have a single setup.py generate two python packages
18:12:28 <ayoung> yes, and I deleted my response telling everyone it was dumb
18:12:36 <ayoung> but it is dumb
18:12:45 <gyee> we (HP) consumes middleware independently of Keystone backend
18:12:52 <ayoung> just didn't want to get in a flameware
18:13:04 <gyee> middleware is just like another client
18:13:08 <ayoung> er, a flamewar without flame wear?
18:13:20 <heckj> gyee: we already got that - it's just a question of how to do it
18:13:20 <ayoung> gyee, agreed.
18:13:31 <ayoung> It should be do-able out of the existing repo structure.
18:13:34 <gyee> separate repo, easy to consume
18:13:43 <dolphm__> gyee: you mean you use auth_token but not the keystone service implementation, right?
18:13:55 <gyee> dolphm_ correct
18:14:12 <mordred> hang on ... reading scrollback for what's dumb...
18:14:16 <dolphm__> gyee: i imagine that's a common approach
18:14:17 <gyee> we extends middleware to add our own customization
18:14:20 <heckj> ayoung: you want to dig around on some ways to do it since you don't like the separate repo idea?
18:14:22 <mordred> ayoung: ah - yes. python is, in fact, that broken
18:14:23 <ayoung> <mugatu>Is the whole world taking crazy pills?</mugatu>
18:14:32 <ayoung> mordred, thanks
18:15:41 <gyee> in fact, middleware tests should be completely separate from Keystone backend tests
18:16:25 <dolphm__> i'd officially like to change my vote from python-keystoneclient to a new repo
18:16:45 <heckj> ayoung: what's your suggestion for how to wrangle this?
18:17:05 <dolphm__> the catch is that we need two new repos
18:17:21 <dolphm__> e.g. keystonecommon and keystonemiddleware
18:17:36 <mordred> do we really need keystonecommon?
18:18:07 <dolphm__> mordred: there's some code that's shared between auth_token and the keystone service
18:18:27 <dolphm__> mordred: i assume it should be extracted and pulled in as a dep to both keystonemiddleware and keystone
18:18:47 <dolphm__> i could see keystoneclient consuming it as well
18:18:48 <ayoung> heckj, let me take a look at the python utilities.  If they really are as broke as all that, I'll suggest an overall file structure.
18:19:44 <heckj> ayoung: I'm fine with deferring this until you've had a chance to dig a bit. I suspect you'll want more than a file structure. The constraint from CI is that one repo has one setup.py - and we'll need to respect that.
18:19:48 <dolphm__> ayoung: actually, what if the encryption stuff was *only* in the client? and keystone was dependent on the client
18:19:57 <ayoung> dolphm_, nope
18:19:58 <dolphm__> and keystonemiddleware was also dependent on the client
18:20:10 <ayoung> I tried that
18:20:18 <ayoung> it has the effect of confusing the code, too
18:20:22 <dolphm__> ?
18:20:37 <ayoung> server shouldn't depend on middleware
18:20:42 <gyee> we should refactor common/utils
18:20:47 <ayoung> and, as I said, there are multiple middlewares out there
18:20:48 <gyee> i.e. middleware doens
18:20:53 <gyee> t depend on passlib
18:20:57 <gyee> but we import it anyway
18:21:28 <ayoung> gyee, right,  that is just mixed in the utils
18:21:35 <dolphm__> ayoung: server depend on the client
18:21:37 <ayoung> hashlib is needed, not passlib\
18:21:53 <dolphm__> ayoung: make everything depend on the client
18:21:54 <gyee> middleware needs hashlib?
18:22:19 <ayoung> dolphm_, we can do lots of things that will "solve" the problem.  Lets first try for doing it straightforward, but still readable
18:23:12 <heckj> #action ayoung to dig on utilities to see what can be done to break up PKI dependencies for auth_token having it's separate package to pypi
18:23:16 <dolphm__> from keystoneclient.utils import validate; validate.token(token_id)
18:24:54 <dolphm__> or from keystoneclient.v3 import tokens; tokens.validate(token_id)
18:25:24 <heckj> dolphm__, gyee, ayoung : can we continue the details of the structure discussion in IRC post meeting? - I'd like to move on to summit topics
18:25:31 <dolphm__> yep
18:25:37 <heckj> #topic summit topics
18:25:42 <ayoung> dolphm_, are you sure you want to merge auth_token into client?
18:25:53 <ayoung> OK, I can table, too
18:26:21 <heckj> I went through summit.openstack.org and http://etherpad.openstack.org/GrizzlyKeystoneSessions and started to try and rectify
18:26:33 <ayoung> For summit, I plan on talking about AD integration and Federation.  I also have my current "Intro to Keystone" talk ready to go
18:26:40 <dolphm__> ayoung: no, i changed my vote to putting it in its own repo
18:26:56 <heckj> ayoung: I think the PKI next steps needs a new blueprint to keep things clear - could you create one?
18:26:57 <dolphm__> ayoung: awesome
18:27:14 <heckj> definitely on the topics of federation and AD integration
18:27:22 <heckj> Those are all pre-approved now
18:27:27 <ayoung> heckj, sure, although I think the PKI next steps is kindof wrapped up in Federation, at least my view of Federation
18:27:55 <heckj> ayoung: wasn't sure how it overlapped, but I wanted to keep it clear from the blueprint that you already have done, since we wrapped that up in Folsom
18:28:04 <heckj> (trying to keep a blueprint limited to a release cycle)
18:28:14 <gyee> ayoung, you really want discovery service? :)
18:28:20 <ayoung> gyee, no
18:28:32 <heckj> There's a couple other topics from the etherpad:
18:28:40 <ayoung> gyee, I want to register a client keystone server with a cetnraolized keystone server and keep it like that
18:28:53 <ayoung> I'll do a blueprint for PKI future, just to keep that stuff clear
18:28:55 <heckj> 2factor/multifactor auth - who's wanting/needing that one that can drive the discussion and is interested in the implementation?
18:29:10 <ayoung> We can use it for Federation, but if we go the Kent approach, I still want it to go in
18:29:40 <gyee> I kinda like discovery for openstack
18:29:41 <ayoung> heckj, I have some small knowledge of that field, but my dance card is full
18:29:51 <gyee> no endpoints from keystone
18:29:58 <gyee> just discover them :)
18:30:10 <heckj> dolphm__: last summit, Joe Savak was talking about a lot about it (multifactor auth) - is that something you'd be focusing on?
18:30:11 <ayoung> gyee, no.  Just...no
18:30:57 <dolphm__> heckj: i'm not sure we need/want multifactor implementation in openstack. however, i do think the v3/tokens API needs to support MFA if possible
18:31:01 <ayoung> heckj, lets get the talk on the schedule, and plan on moderating.  I'll participate, so at least we will have something to talk about.  You or Dolph can propose
18:31:08 <dolphm__> heckj: that's one of the reasons i haven't implemented anything on /tokens yet
18:31:48 <heckj> KK - will verify there's a BP on multifactor and a topic for discussing at the summit
18:31:50 <heckj> gyee: since you're bouncing all around - are there any summit topics that you're wanting to present and drive in implementation?
18:32:35 <gyee> heckj, we have a generic signature validation middleware if you guys are interest in hearing about it
18:32:38 <heckj> ayoung: there's nothing scheduled for a general "intro to keystone" talk - where you planning on submitting that talk?
18:33:23 <dolphm__> do we still have those breakout/whiteboard sessions?
18:33:34 <heckj> gyee: the question was more around "Is there a topic or code you'd like introduce into keystone that you're willing to drive?" -I'm always interested in hearing about interesting implementations and effort
18:34:01 <heckj> dolphm__: which whiteboard sessions? We can also make something, but I'm not aware of anything explicit on the shcedule for it
18:35:05 <gyee> heckj, I don't know yet. I'll check with the HP higher-ups to see what I can do. Will let you know.
18:35:05 <ayoung> heckj, I had suggested it a while back.  I thought you were planning on giving it, but I kept mine in my back pocket, since I am giving it to my team next week anyway
18:35:39 <ayoung> Also, since I already submitted 3, wasn't sure I should go for Four, but willing to do so
18:35:49 <heckj> ayoung: why don't we have you do it at the summit as well. I can, but I have created anything for an intro
18:35:57 <dolphm__> gyee: i'd be interested in that
18:36:11 <heckj> ayoung: I'm not worried about you submitting all the talks - I damn near did that last summit :-)
18:36:28 <ayoung> heckj, fine, just don't nominate me as PTL
18:36:37 <heckj> heh
18:36:49 <heckj> I'll be moderating and expect to do so
18:37:08 <heckj> Actually, I think the federation talk will be the most difficult - so many ideas and goals that folks have wrapped there
18:37:38 <heckj> dolphm__: any specific topics you want to submit or drive?
18:37:42 <ayoung> heckj, so I can call it either "Introduction to  Keystone"  or "Keystone internals."  Depending on how we want to advertise it?
18:38:12 <heckj> my preference to Keystone internals <-- want to keep it clear to internal on developing keystone, not using keystone
18:38:25 <heckj> unless it's really abouy deploying/using
18:39:00 <dolphm__> heckj: v3 api -- but i don't think that deserves a session
18:39:14 <heckj> KK
18:39:43 <heckj> actually, I think a session on it would be useful - at least to talk to status and show where it's at during the summit
18:39:59 <heckj> I'd be happy to propose, run, and wrangle since I did the all the wrangling on the drafts
18:40:21 <dolphm__> heckj: what, presenting the spec? lol
18:40:45 <heckj> dolphm__: in a sense, yeah - at least giving everyone outside of keystone a chance to talk about the "how to use it" API details
18:41:03 <dolphm__> heckj: or a "here's what's new, request for feedback" type thing
18:41:19 <heckj> dolphm__: yeah, pretty much
18:41:31 <heckj> #topic open discussion
18:42:03 <heckj> That's all i had - feel free to resume package setup/dependency discussion
18:42:36 <gyee> middleware should be light and independent
18:42:47 <gyee> just like an mobile app
18:42:55 <dolphm__> +1
18:43:01 <gyee> think of middleware repo as an app repo
18:44:06 <dolphm__> sudo mkdir github.com/openstack/keystone-middleware
18:47:58 <ayoung> heckj, http://summit.openstack.org/cfp/edit/76
18:49:00 <heckj> ayoung: approved! We have 3 hours unscheduled - won't be surprised to have last minute things fly at us
18:54:51 <heckj> all quiet for 5 minutes or so
18:54:58 <heckj> #endmeeting