18:01:29 #startmeeting 18:01:30 Meeting started Tue Mar 6 18:01:29 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:48 (gimme a sec to get this together) 18:02:08 Agenda for today: 18:02:17 * status and progress (bugs, blueprints) 18:02:22 * any high pri stuff? 18:02:26 * open discussion 18:02:28 So... 18:02:33 #topic status and progress 18:02:45 I'll start off with some updates from last meeting. 18:03:09 I didn't get all the bugs triaged (although I made some headway this morning), and while I've burned down the old blueprints, not many new ones have yet popped up. 18:03:36 I'm going to make a run through all the bugs and tag them with "blueprint" if I think they're likely more "work to do" rather than issues, to get things back aligned with how LP seems to want to work 18:04:19 Opening new blueprints is totally fair game - I'm going to stick with "please assign them to yourself" to present yourself as advocate for the work. Without an advocate for the work or design, a blueprint won't stand a chance of getting approved, etc. 18:04:44 I also took a run through the open questions and answered some of those. 18:05:00 ayoung: could use your help on one: #link https://answers.launchpad.net/keystone/+question/189308 18:05:15 looking... 18:05:18 It's about how to set up LDAP, and none of our docs have any detail about how to set that up based on your code submissions. 18:05:39 Any answers there would make a good starting point for docs, which we really should have for the backends. 18:05:47 sqlalchemy.engine.base.Engine... 18:05:58 um looks like a misconfiguration 18:06:01 yeah 18:06:13 But I think his core question was how to set up LDAP, which I didn't have any detail on... 18:06:44 heckj, http://adam.younglogic.com/2012/02/openstack-keystone-ldap-redux/ 18:07:05 But I will come up with a distilled version for the Docs 18:07:05 #link http://adam.younglogic.com/2012/02/openstack-keystone-ldap-redux/ 18:07:10 ayoung: ah, cool. 18:07:28 ayoung: would you be interested in writing that into a restructured text doc for our keystone.openstack.org site? 18:07:48 sure...I've learned a bit since I wrote that, too, so I think I can make it clearer 18:07:57 sweet! That would be great! 18:08:19 #action ayoung to write up LDAP config for keystone.openstack.org 18:08:32 Looking back, I'm not seeing a whole lot else from the prior meeting. 18:09:13 Aside from docs & bug fixing, my focus on the bugs, blueprints, and questions is to gather up as much detail and coordination around setting up the Folsom design summit as possible - coming up here in a just a month or so. 18:09:21 (damn, that's speeding down on us). 18:09:45 heckj, would it make sense to put LDAP support into the keystone-manage toolchain? 18:09:53 is that the right approach? 18:10:10 If you guys have a second, I'd love you to read through #link http://wiki.openstack.org/KeystoneFolsomSummitTopics (if you haven't already) and add in anything you think it missing 18:10:46 Will do 18:10:56 ayoung: damn, just erased what I meant to write. 18:11:11 \o hi all 18:11:23 ayoung: any bootstrapping/init is relevant to keystone-manage 18:11:53 joesavak: http://wiki.openstack.org/KeystoneFolsomSummitTopics 18:12:04 ayoung: any initialization of data beyond that we're running through the keystoneclient 18:12:07 hi dolph 18:12:09 heckj, OK, I think that probably needs to be a blueprint. If there is time at the end of this meeting, can we hack it together on an Etherpad? 18:12:14 joesavak -morning! 18:12:27 ayoung: yeah, no problem! 18:12:28 Hi - I just got here too. 18:12:33 morning Ziad! 18:12:38 morning! 18:12:50 afternoonish! 18:13:08 Okay - so administravia updates are pretty much complete at this point - I'll let you guys read the backlog for those details. 18:13:26 Any high pri bugs or current "oh shit" issues that need immediate attention? 18:14:23 heckj, there is the general; set of tickets around the config stuff 18:15:08 markmc did a decent amount of effort to try and clean up the keystone impl. We should, at a minimum, understand what he is trying to do, and either active embrace or reject it. 18:15:23 yeah - that whole design point is pending some continued discussion between termie and mark. Neither here, so I don't know that we can move that along right now, but it's definitely outstanding. 18:15:59 there's some quesitons outstanding in #link https://review.openstack.org/#change,4547 18:16:09 And that moved to the openstack list at #link https://lists.launchpad.net/openstack/msg08329.html 18:16:20 (I hope I'm using this # link thing correctly) 18:17:01 The general idea of moving in line with openstack-common I think we're all for - there's just some pending "how do we" design choices that need to be made around configuration options and testing. 18:17:45 Any other big issues? 18:17:47 we did the cfg implementation on master and had some tricky things to work through. Mostly around dashes vs. underscores. There may be some lessons learnt that could be helpful. Ed Leafe worked on it.. 18:18:11 zns: "on master" meaning master in keystone? openstack-common? 18:18:26 heckj: master in Keystone pre-KSL 18:18:42 zns: thanks, coolie 18:19:02 Is KSL using the same config files? If not, might nort be relevant... 18:19:17 zns, yes, same files 18:19:27 heckj: working on landing the memcache support to auth_token 18:19:31 (same problems too) 18:19:42 anotherjesse: anything blocking that or making it difficult? 18:20:10 anotherjesse: is that a rewrite of the pre-KSL memcache code or a port? 18:20:21 heckj: nope, just thinking through how to simplify it.. it has a lot of logic right now, trying to simplify to "cache this, if it expires, validate again and only cache what keystone says" 18:20:40 The other code base that needs some commentary attention is #link https://review.openstack.org/#change,4659 - I think most of you have already looked, but in case you hadn't seen it - it's enabling policy (like Nova) just within keystone for now. 18:20:40 zns: https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py 18:21:01 zns: the token middleware was rewritten last week due to bugs that folks found 18:21:01 zns: auth_token got a 22-patch-set extensive rewrite in the past week. 18:22:07 Okay - moving on 18:22:14 heckj: https://bugs.launchpad.net/keystone/+bug/943722 will need addressed before RC 18:22:14 #topic open discussion 18:22:14 Launchpad bug 943722 in keystone "token auth needs unit tests" [Critical,Confirmed] 18:22:25 anotherjesse: lookin' 18:22:47 heckj, anotherjesse: yes, I see it looks very different. OK. 18:23:00 anotherjesse: agreed and tagged to RC1, so we've got it locked in for attention 18:23:27 you guys still preserve the same interface as the old auth_token middleware right? 18:23:32 gyee: yep 18:23:38 I love you guys! 18:23:45 gyee: and documented it in the file 18:23:54 https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py#L59 18:23:57 If anyone else sees a bug they think it critical and we haven't marked it as such, yell at me (irc, email, etc) with a bug # to get my attention. 18:24:33 gyee: it definitely got a LOT of attention. The most patchsets on a single change that I've seen so far, and some of the horizon ones have really gone on... 18:25:18 I'll spend sometime reading the code 18:25:20 I noticed some of the module docs are flowing through to our keystone.openstack.org - I'm going to bug that and dig in it. Anyone else seen this? 18:25:34 (http://keystone.openstack.org/py-modindex.html) 18:25:45 Have you guys seen the gource videos: http://www.youtube.com/watch?v=aRDRNuFfYGo for keystone and http://www.youtube.com/watch?v=dD80PDDn6gw for all of openstack. CHeck'em out... 18:26:03 zns, yeah, awesome video 18:26:04 #link http://www.youtube.com/watch?v=aRDRNuFfYGo 18:26:12 #link http://www.youtube.com/watch?v=dD80PDDn6gw 18:27:42 not a permanent link but jakedahn is working on revising the sphinx html format to be similar to openstack.org (as part of docday) 18:27:42 http://jakedahn.com/os-example/identity.html 18:27:56 I would like to ask: How tokens can be added to keystone?Neither keystoneclient support it nor keystone-manage, do they? 18:28:18 rafaduran: what does adding a token mean? 18:28:22 Okay - docs and bugs right now - please take a look at #link https://bugs.launchpad.net/keystone/+bugs?search=Search&field.importance=Critical and #link: https://bugs.launchpad.net/keystone/+bugs?search=Search&field.importance=High for things that need pretty immediate attention 18:28:43 create a new toke, e.g. the service token 18:28:44 anotherjesse: Oooh! Nice! 18:28:44 you usually create a token by posting to /v2.0/token with the auth creds for the user/tenant you want a token for 18:29:28 rafaduran: the preferred way to do service tokens is to create a service tenant & users for each service and then put the user/pass in the auth_token config 18:29:31 rafaduran: keystone doesn't have a means of accepting tokens created from extenal mechanisms and storing/using them. 18:30:42 anotherjesse: I missed some of that early auth_token conversation - did the other project folks prefer a service based user/passwd in their configs to a "special token/shared secret"? 18:31:04 heckj: ya - the preference seemed to be going towards service based user/pass 18:31:06 ok, that's fine for users, but what about the service token? If I'm no wrong, other services need it to be created, do I? 18:31:33 rafaduran: a service is a special case of a user - https://review.openstack.org/gitweb?p=openstack-dev/devstack.git;a=blob;f=files/keystone_data.sh;h=958d2af4f2f19d392e993d4bf60a4d7c6734f9f7;hb=b7d1fbbe20ce8ef60607d937c22293dfff90e964 18:32:12 heckj: the idea being that we could improve the recommendation to certs instead of passwords for service users in folsom (or something more secure) 18:32:14 rafaduran: The sysadmin setting up openstack creates service accounts for all the services. Right now we have a single tenant that acts as the owner for these services. 18:32:37 anotherjesse: makes sense, will probably make any federation concepts a bit easier as well. 18:34:02 anotherjesse, heckj: do you need to create a tenant for the service users or owners? I had removed that dependency a while back and returned global endpoints for unscoped admin tokens. 18:34:32 heckj, so all of this falls under the PKI discussion we will have in Folsom 18:34:42 zns: the concept of scoping has been pitched out the window - all tokens are scoped. So we've added back in a tenant to collect the services. In devstack, it's named "service" by default. 18:34:43 I think I'm probabling using old configuration files where the token is needed, I will review, thanks all for your answer 18:34:52 tokens can be done cryptographically, and thus remove the need for a network call 18:34:56 to verify a token 18:35:07 but that is def beyond the Essex scope 18:35:17 ayoung: ya - lots we could do much better there (folsom timeframe) 18:35:25 is that the scalability BP we are talking about? 18:35:39 gyee, possibly 18:35:55 heckj: How does one call GET /tenants to get a list of all tenants? 18:35:55 I think I commented on etherpad on that one 18:36:27 gyee, it will certainly increase the Keystone scalability. It also has the potential to make the system more secure. 18:37:00 zns, needs the admin role... 18:37:02 zns: by authorizing as the service (which we set up to have an "admin" role), or as a user with administrative privs 18:37:11 ayoung: is there a blueprint out for that? 18:37:14 ayoung, I am also concern about the size of the token 18:37:22 zns, for PKI? 18:37:23 zns: take a look at the link that anotherjesse listed earlier for how it's created in devstack 18:37:24 tokens are passed via http headers 18:37:32 ayoung: yes, BP for PKI. 18:37:35 so if the size gets too big, it may not be http friendly 18:37:42 zns, not yet, we just started the discussion 18:38:00 gyee, well, HTTP handles client certs and server certs just fine.... 18:38:11 PKI's fine 18:38:21 so we just have to keep it that size or smaller 18:38:23 gyee: valid concern, there's ways and things to watch out for in implementation. 18:38:39 gyee, ayoung - you guys are coming to the folsom design summit, yeah? 18:38:40 that scalability PB is talking about encoding all kinds of stuff into the token itself 18:38:53 with RBAC, that token can only get bigger 18:38:54 heckj, I have to convince my Boss. I'd like to, but if not, I'll all in 18:38:56 call in 18:39:11 heckj: I see it. Thanks. joesavak: is this still compatible with Rackspace auth? 18:39:14 We will certainly have someone there. 18:39:19 keckj, yes, I've registered already 18:39:25 heckj 18:39:33 ayoung: Stefano asserted they were going to have live streaming/dial-in links for this one (like the Ubuntu summit). That's some serious networking, but I'm hoping we'll get that nailed well. 18:39:51 zns: i'll need to review 18:41:10 joesavak: let me know. I think I did a lot of testing with novaclient and keystone client against Rackspace Auth, but I'm not sure someone has picked that up from me (as I'm not doing that right now). 18:41:29 anything else for the meeting proper? 18:43:17 Okay - thanks all. If you have anything you want to add to the agenda for next week, let me know. 18:43:21 #endmeeting