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