18:01:24 #startmeeting 18:01:25 Meeting started Tue Jul 10 18:01:24 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:45 ola all 18:01:54 hi 18:02:10 #topic Folsom Release and general planning 18:02:10 How do? 18:02:37 So… looking at the release schedule, we're getting pretty close. 18:02:39 #link http://wiki.openstack.org/FolsomReleaseSchedule 18:03:18 I wrote this up. https://gist.github.com/3085149 18:03:34 That way maybe I don't hijack the whole meeting. 18:03:35 The general idea is that all feature work is wrapped up bu the end of folsom-3, which is scheduled for Aug 16th - about 4-5 weeks from now 18:03:46 ayoung: nice 18:04:15 Looking at the folsom blueprints and work, I'm guessing we're not going to get even half of this wrapped up: https://launchpad.net/keystone/+milestone/folsom-3 18:04:17 #link https://launchpad.net/keystone/+milestone/folsom-3 18:04:56 heckj, yeah...PKI tokens probably the only thing from that list that will get in 18:05:04 Outside of the PKI work, and the basic AD identity backend, I think everything is pending work on the V3 API 18:05:14 Maybe the token ID thing? 18:05:15 heckj: Do you think V3 is ready to start coding some features? 18:05:25 I suspect we can make a good start on the V3 API work, but I don't know that we'll have it ready to roll in 4 weeks 18:05:26 Stop Implementing Token IDs as part of URIs 18:06:03 #link PKI Status: https://gist.github.com/3085149 18:06:24 heckj, that is not really status so much as "actions" 18:06:39 er, sorry 18:06:49 yeah - just getting notes in the logs, sorry about that 18:07:01 #link PKI work items/actions: https://gist.github.com/3085149 18:07:01 status is more like: have proof of concept working, need to hammer out those details. 18:07:16 soudns good 18:07:37 related, the V3 api has it's third draft now up - I spammed the OpenStack mailing list with it this past saturday: https://docs.google.com/document/d/1VP-bTBbwsn6q-rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit 18:07:40 I'm still feeling confident in getting this in 18:07:42 #link V3 draft3 https://docs.google.com/document/d/1VP-bTBbwsn6q-rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit 18:07:54 ayoung: it looks like you're making excellent progress 18:08:20 So to answer rafaduran question, I think we're at the spot where we can start implementing the V3 API 18:08:39 heckj, can we break it down to a series of tickets? 18:09:02 I'm explicitly leaving open the API spec so that when we realise we painted ourselves into a corner, we can change the room and paint ourselves back out of it 18:09:03 heckj: I'm interested on the querying stuff, I can implement that part 18:09:46 ayoung: I'd absolutely love to do that - LP has a "workitems" thing, we could open "bugs" related to it, or we could use a different method. Any preferences? 18:10:10 maybe blueprints 18:10:14 bugs works for me...keep using the same system 18:10:22 rafaduran, they can all link to one blueprint 18:10:25 rafaduran: would love to have the help! One of the pending "Hmm, how's that going to work" is the request from Horizon (gabrielhurley) to allow the queries to request back related objects from the given REST resources. I don't have a good answer there. 18:10:29 just the individual line items 18:11:28 heckj: that's a interesting, issue, I will try to do some research whenever I have some free time 18:11:32 #action: heckj to create tags and bugs with an initial work breakdown 18:12:46 I'll make a first sweep of it (starting today) - will hit the mailing list with a reference to it, and we can iterate. I normally break down things with a group, so I expect it'll need revisions. 18:13:22 So - all the stuff depending on V3 IMPL, I'm going to drop from folsom today 18:13:39 #action heckj to drop all dependent pieces on V3 API implementation from Folsom series 18:14:15 I'm expecting some hollerin', but I just don't see the work getting done otherwise. 18:15:00 Any questions? 18:16:55 Okay - ayoung, did you want to get into any more detail about the PKI/signed tokens stuff? 18:17:06 (and we have rafarduran's topic pending) 18:17:13 heckj, just to give a 1 line summary 18:17:42 I am going to make it so the two types of tokens can coexist in order to simplify the upgrade process. 18:18:11 Anyone interested in the details (beyond the gist I wrote above) can chat after the meeting 18:18:46 sounds good, thanks ayoung 18:18:53 rafaduran: you're up 18:19:00 ok, thanks 18:19:02 #topic rate limiting middleware - feedback and corner cases 18:19:05 BTW, please send me review requests 18:19:16 I'' try to grab them if I see them, 18:19:41 As I said in previous meetings I'm working on a rate limit middleware 18:19:56 #link https://blueprints.launchpad.net/keystone/+spec/keystone-rate-limiting 18:20:10 I've updated the related bluprint 18:20:21 and the code start looking good 18:20:35 #link https://github.com/rafaduran/keystone/tree/bp/keystone-rate-limiting 18:21:05 #link https://github.com/rafaduran/keystone/tree/bp/keystone-rate-limiting 18:21:06 but I still need some feedback/help on some situations 18:21:40 specially on how to map requests to limits 18:21:56 I consider thre cases 18:22:26 requests that doesn't need authentication, authentication requests and authenticated requests 18:22:39 so my first idea was map tokens to user id 18:23:04 but now I'm not really sure, maybe it would be more useful map to usernames 18:23:56 a use case is devstack, if this is ever used would be much more difficult the devstack configuration 18:24:24 you need to create users, get the id and if you wan a custom limit then change keystone configuration 18:24:32 rafaduran: I suspect you're making this more complex than it needs to be. I'd guess you could map a limit to the REST URI and call it good at that for a first cut. 18:24:48 rafaduran, can you write up the issues you are dealing with and send it to the mailing list? I would be great to have them documented, and we could spend the time to get the answers correct. 18:24:53 rafaduran: did you specifically want to not ratelimit by a user? I'm not clear on that use case and why that would be needed... 18:25:02 ayoung: ++ 18:25:35 heckj: not, I want limits by user 18:26:16 but, how to map that user to the request is not clear 18:26:49 but as ayoung said probably is better send an email to the mailing list 18:26:50 I'm with ayoung that I think this is something that would be very worthwhile to take onto email, but in the more immediate timeframe, I'm not clear on why you want to map it to a user - what does that get you that you want to take advantage of? 18:27:09 I'm happy to wait if you'd prefer to do that 18:28:15 I want map users because I think I need track somhow the reqeusts 18:28:30 #action rafaduran to write up design questions for rate limiting 18:28:45 #action rafaduran to write up design questions for rate limiting 18:28:50 I mean, I need limit someone/something 18:28:57 maybe I'm wrong with that 18:29:01 (I think I need to do all those to get them into the logs - very annoying, but I'm not sure) 18:30:57 the idea also comes from how nova middleware works (it maps by username) 18:31:09 and my work started from it 18:33:18 ayoung: It would very useful if you can check what I'm doing, in order to be sure that is PKI compatible 18:33:42 since there is no API changes it should be, but I can miss something 18:33:51 rafaduran, I'd be happy to. If you have partial work, please commit it to your account on github and send me a link...or share some other way 18:35:05 ayoung: I've added the link when start writing 18:35:11 https://github.com/rafaduran/keystone/tree/bp/keystone-rate-limiting 18:35:11 SOunds good 18:35:49 it's not finished and I need solve what the mapping issue 18:36:04 but that's pretty much my idea 18:36:27 rafaduran, OK...It will take me some time to digest. 18:37:49 ayoung: you can check the middleware stuff directly 18:37:51 https://github.com/rafaduran/keystone/blob/bp/keystone-rate-limiting/keystone/contrib/rate/core.py#L283 18:38:53 rafaduran, OK, so with PKI, getting info out of the token should be cheaper....no need for a remote call 18:38:59 hmmm 18:39:38 heckj, once we get PKI tokens merged, we might want to think about somehow taking the info from the token and putting it into the request context so that we don't have multiple calls to openssl 18:40:20 yes, I was thinking about that too 18:40:51 ayoung: you might add the compatibility layer into it 18:40:59 rafaduran, give me a day or so to clean up the PKI stuff and repost to github, and we can work through these two issues together 18:41:12 ok 18:41:21 rafaduran, sounds about right...I'd have to look in to it to grok completely 18:42:22 heckj: implementation apart, I'm not really sure how to proceed in order to get the bp reviewed/approved 18:42:31 sec... 18:44:14 reading backtrace really quick - had to take a phone call 18:44:37 ayoung: re: populating the request context from the token, yes - I think that's an excellent idea 18:45:17 rafaduran: for the BP, I think we only really need to nail down the specifics of your use cases and what you're solving for, and once that's clear it is down to implemenation 18:46:00 #action auth_token middle populates request context with data from signed token so it does not have to be fetched multiple times. 18:46:39 I'm not OCD about mananging the blueprints with their various status' and such - it's more about the code to me, with a blueprint being a handy indicator that someone is wanting to do some feature work, and a means of linking review requests together 18:47:29 rafaduran: anything more? 18:47:46 no, I think that's all for now 18:47:53 #topic open discussion 18:48:13 I don't have anything more - just finished cleaning up the blueprints and unlinking a pile of things from Folsom 18:48:37 #info If you have a BP that you think can get done in the next 4 weeks, let heckj know and we'll link the BP's back up 18:49:07 heckj: one more thing about the querying 18:49:12 rafaduran: shoot 18:50:32 heckj: API 3 defines URL for all resources so I think we can send links, and additionaly, somehow (maybe at querystring) accept a eager load (I think that was Gabriel suggestion) of objects 18:51:01 so it can be included into the querying 18:51:57 rafaduran: yeah - that "eager load" was Gabriel's request - the idea being able to pull in specific sets of related objects with the query parameters. 18:51:59 I am going to be speaking at the Boston Openstack Meetup on July 24th about Keystone, and what to expect in Folsom. I guess I'll modify the slide about the V3 API 18:52:15 ayoung: heh, sorry :-) 18:52:44 ayoung: I think we'll have a good implementation by then - but I don't want to set an expectation of other projects being able to use it in Folsom. It's just too late in the cycle to ask folks to change all that stuff up 18:53:10 I was wayyyyyy to naive about how long it would take to nail down a revised and consolidated API 18:53:26 BTW: Any complains about renaming tenants back to projects? Now's the time to bitch... 18:53:39 heckj, that is fine. I want to be able to give an honest picture of what to expect. I was actually posting in order to solicit input: what are the most important things to communicate about Keystone? 18:54:17 My highlights would be PKI, bug fixes and stability, solid work towards an updated core API 18:54:31 heckj, so long as they are called projects *Everywhere* I am fine. I think the term *tenants* is too loaded, and we don't really meet the letter of the law on them anyway 18:54:47 dtroyer: since you're online, how's the progress on https://blueprints.launchpad.net/keystone/+spec/command-options? 18:55:55 heckj: it was merged last week 18:55:56 ayoung: I aimed to do a global search and replace, and move everything to back to "projects". The API certainly encapsulates that, and I'll make some work items with the V3 Implementation to revise the docs with it 18:56:12 dtroyer: fully implemented to what you wanted? (I haven't looked) 18:56:29 heckj: yes 18:56:37 dtroyer: thxusir! BP updated 18:56:46 heckj: thx, I forgot to do that... 18:56:48 heckj, are all of the openstack projects aligned with using the term "project" ? 18:57:30 ayoung: that was nova's original term, and they never changed from it. horizon still uses project, and swift never moved to "tenant" from whatever they were calling that grouping. 18:57:44 heckj, good 18:57:47 works for me 18:57:57 Glance uses different terms entirely (members, grouping) - which can be applied to whatever 18:58:25 thanks all - I've got to wrap this up and make a meeting in 2 minutes. 18:58:59 I'll post the BP update stuff to them mailing list since we didn't see dolph, guang and liem here today 18:59:03 #endmeeting