18:01:29 <heckj> #startmeeting
18:01:30 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:48 <heckj> (gimme a sec to get this together)
18:02:08 <heckj> Agenda for today:
18:02:17 <heckj> * status and progress (bugs, blueprints)
18:02:22 <heckj> * any high pri stuff?
18:02:26 <heckj> * open discussion
18:02:28 <heckj> So...
18:02:33 <heckj> #topic status and progress
18:02:45 <heckj> I'll start off with some updates from last meeting.
18:03:09 <heckj> 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 <heckj> 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 <heckj> 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 <heckj> I also took a run through the open questions and answered some of those.
18:05:00 <heckj> ayoung: could use your help on one: #link https://answers.launchpad.net/keystone/+question/189308
18:05:15 <ayoung> looking...
18:05:18 <heckj> 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 <heckj> Any answers there would make a good starting point for docs, which we really should have for the backends.
18:05:47 <ayoung> sqlalchemy.engine.base.Engine...
18:05:58 <ayoung> um  looks like a misconfiguration
18:06:01 <heckj> yeah
18:06:13 <heckj> But I think his core question was how to set up LDAP, which I didn't have any detail on...
18:06:44 <ayoung> heckj, http://adam.younglogic.com/2012/02/openstack-keystone-ldap-redux/
18:07:05 <ayoung> But I will come up with a distilled version for the Docs
18:07:05 <heckj> #link http://adam.younglogic.com/2012/02/openstack-keystone-ldap-redux/
18:07:10 <heckj> ayoung: ah, cool.
18:07:28 <heckj> ayoung: would you be interested in writing that into a restructured text doc for our keystone.openstack.org site?
18:07:48 <ayoung> sure...I've learned a bit since I wrote that, too, so I think I can make it clearer
18:07:57 <heckj> sweet! That would be great!
18:08:19 <ayoung> #action ayoung to write up LDAP config for  keystone.openstack.org
18:08:32 <heckj> Looking back, I'm not seeing a whole lot else from the prior meeting.
18:09:13 <heckj> 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 <heckj> (damn, that's speeding down on us).
18:09:45 <ayoung> heckj, would it make sense to put LDAP support into the keystone-manage toolchain?
18:09:53 <ayoung> is that the right approach?
18:10:10 <heckj> 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 <dolphm> Will do
18:10:56 <heckj> ayoung: damn, just erased what I meant to write.
18:11:11 <joesavak> \o hi all
18:11:23 <heckj> ayoung: any bootstrapping/init is relevant to keystone-manage
18:11:53 <dolphm> joesavak: http://wiki.openstack.org/KeystoneFolsomSummitTopics
18:12:04 <heckj> ayoung: any initialization of data beyond that we're running through the keystoneclient
18:12:07 <joesavak> hi dolph
18:12:09 <ayoung> 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 <heckj> joesavak -morning!
18:12:27 <heckj> ayoung: yeah, no problem!
18:12:28 <zns> Hi - I just got here too.
18:12:33 <heckj> morning Ziad!
18:12:38 <zns> morning!
18:12:50 <joesavak> afternoonish!
18:13:08 <heckj> 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 <heckj> Any high pri bugs or current "oh shit" issues that need immediate attention?
18:14:23 <ayoung> heckj, there is the general; set of tickets around the config stuff
18:15:08 <ayoung> 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 <heckj> 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 <heckj> there's some quesitons outstanding in #link https://review.openstack.org/#change,4547
18:16:09 <heckj> And that moved to the openstack list at #link https://lists.launchpad.net/openstack/msg08329.html
18:16:20 <heckj> (I hope I'm using this # link thing correctly)
18:17:01 <heckj> 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 <heckj> Any other big issues?
18:17:47 <zns> 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 <heckj> zns: "on master" meaning master in keystone? openstack-common?
18:18:26 <zns> heckj: master in Keystone pre-KSL
18:18:42 <heckj> zns: thanks, coolie
18:19:02 <zns> Is KSL using the same config files? If not, might nort be relevant...
18:19:17 <ayoung> zns, yes,  same files
18:19:27 <anotherjesse> heckj: working on landing the memcache support to auth_token
18:19:31 <heckj> (same problems too)
18:19:42 <heckj> anotherjesse: anything blocking that or making it difficult?
18:20:10 <zns> anotherjesse: is that a rewrite of the pre-KSL memcache code or a port?
18:20:21 <anotherjesse> 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 <heckj> 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 <anotherjesse> zns: https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py
18:21:01 <anotherjesse> zns: the token middleware was rewritten last week due to bugs that folks found
18:21:01 <heckj> zns: auth_token got a 22-patch-set extensive rewrite in the past week.
18:22:07 <heckj> Okay - moving on
18:22:14 <anotherjesse> heckj: https://bugs.launchpad.net/keystone/+bug/943722 will need addressed before RC
18:22:14 <heckj> #topic open discussion
18:22:14 <uvirtbot`> Launchpad bug 943722 in keystone "token auth needs unit tests" [Critical,Confirmed]
18:22:25 <heckj> anotherjesse: lookin'
18:22:47 <zns> heckj, anotherjesse: yes, I see it looks very different. OK.
18:23:00 <heckj> anotherjesse: agreed and tagged to RC1, so we've got it locked in for attention
18:23:27 <gyee> you guys still preserve the same interface as the old auth_token middleware right?
18:23:32 <anotherjesse> gyee: yep
18:23:38 <gyee> I love you guys!
18:23:45 <anotherjesse> gyee: and documented it in the file
18:23:54 <anotherjesse> https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py#L59
18:23:57 <heckj> 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 <heckj> 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 <gyee> I'll spend sometime reading the code
18:25:20 <heckj> 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 <heckj> (http://keystone.openstack.org/py-modindex.html)
18:25:45 <zns> 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 <gyee> zns, yeah, awesome video
18:26:04 <heckj> #link http://www.youtube.com/watch?v=aRDRNuFfYGo
18:26:12 <heckj> #link http://www.youtube.com/watch?v=dD80PDDn6gw
18:27:42 <anotherjesse> 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 <anotherjesse> http://jakedahn.com/os-example/identity.html
18:27:56 <rafaduran> I would like to ask: How tokens can be added to keystone?Neither keystoneclient support it nor keystone-manage, do they?
18:28:18 <anotherjesse> rafaduran: what does adding a token mean?
18:28:22 <heckj> 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 <rafaduran> create a new toke, e.g. the service token
18:28:44 <heckj> anotherjesse: Oooh! Nice!
18:28:44 <anotherjesse> 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 <anotherjesse> 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 <heckj> rafaduran: keystone doesn't have a means of accepting tokens created from extenal mechanisms and storing/using them.
18:30:42 <heckj> 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 <anotherjesse> heckj: ya - the preference seemed to be going towards service based user/pass
18:31:06 <rafaduran> 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 <anotherjesse> 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 <anotherjesse> 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 <heckj> 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 <heckj> anotherjesse: makes sense, will probably make any federation concepts a bit easier as well.
18:34:02 <zns> 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 <ayoung> heckj, so all of this falls under the PKI discussion we will have in Folsom
18:34:42 <heckj> 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 <rafaduran> 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 <ayoung> tokens can be done cryptographically,  and thus remove the need for a network call
18:34:56 <ayoung> to verify a token
18:35:07 <ayoung> but that is def beyond the Essex scope
18:35:17 <heckj> ayoung: ya - lots we could do much better there (folsom timeframe)
18:35:25 <gyee> is that the scalability BP we are talking about?
18:35:39 <ayoung> gyee, possibly
18:35:55 <zns> heckj: How does one call GET /tenants to get a list of all tenants?
18:35:55 <gyee> I think I commented on etherpad on that one
18:36:27 <ayoung> gyee, it will certainly increase the Keystone scalability.   It also has the potential to make the system more secure.
18:37:00 <ayoung> zns, needs the admin role...
18:37:02 <heckj> 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 <zns> ayoung: is there a blueprint out for that?
18:37:14 <gyee> ayoung, I am also concern about the size of the token
18:37:22 <ayoung> zns, for PKI?
18:37:23 <heckj> zns: take a look at the link that anotherjesse listed earlier for how it's created in devstack
18:37:24 <gyee> tokens are passed via http headers
18:37:32 <zns> ayoung: yes, BP for PKI.
18:37:35 <gyee> so if the size gets too big, it may not be http friendly
18:37:42 <ayoung> zns, not yet,  we just started the discussion
18:38:00 <ayoung> gyee, well,  HTTP handles client certs and server certs just fine....
18:38:11 <gyee> PKI's fine
18:38:21 <ayoung> so we just have to keep it that size or smaller
18:38:23 <heckj> gyee: valid concern, there's ways and things to watch out for in implementation.
18:38:39 <heckj> gyee, ayoung - you guys are coming to the folsom design summit, yeah?
18:38:40 <gyee> that scalability PB is talking about encoding all kinds of stuff into the token itself
18:38:53 <gyee> with RBAC, that token can only get bigger
18:38:54 <ayoung> heckj, I have to convince my Boss.  I'd like to,  but if not, I'll all in
18:38:56 <ayoung> call in
18:39:11 <zns> heckj: I see it. Thanks. joesavak: is this still compatible with Rackspace auth?
18:39:14 <ayoung> We will certainly have someone there.
18:39:19 <gyee> keckj, yes, I've registered already
18:39:25 <gyee> heckj
18:39:33 <heckj> 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 <joesavak> zns: i'll need to review
18:41:10 <zns> 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 <heckj> anything else for the meeting proper?
18:43:17 <heckj> Okay - thanks all. If you have anything you want to add to the agenda for next week, let me know.
18:43:21 <heckj> #endmeeting