18:01:24 <heckj> #startmeeting
18:01:25 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:45 <heckj> ola all
18:01:54 <rafaduran> hi
18:02:10 <heckj> #topic Folsom Release and general planning
18:02:10 <ayoung> How do?
18:02:37 <heckj> So… looking at the release schedule, we're getting pretty close.
18:02:39 <heckj> #link http://wiki.openstack.org/FolsomReleaseSchedule
18:03:18 <ayoung> I wrote this up. https://gist.github.com/3085149
18:03:34 <ayoung> That way maybe I don't hijack the whole meeting.
18:03:35 <heckj> 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 <heckj> ayoung: nice
18:04:15 <heckj> 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 <heckj> #link https://launchpad.net/keystone/+milestone/folsom-3
18:04:56 <ayoung> heckj, yeah...PKI tokens probably the only thing from that list that will get in
18:05:04 <heckj> Outside of the PKI work, and the basic AD identity backend, I think everything is pending work on the V3 API
18:05:14 <ayoung> Maybe the token ID thing?
18:05:15 <rafaduran> heckj: Do you think V3 is ready to start coding some features?
18:05:25 <heckj> 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 <ayoung> Stop Implementing Token IDs as part of URIs
18:06:03 <heckj> #link PKI Status: https://gist.github.com/3085149
18:06:24 <ayoung> heckj, that is not really status so much as "actions"
18:06:39 <heckj> er, sorry
18:06:49 <heckj> yeah - just getting notes in the logs, sorry about that
18:07:01 <heckj> #link PKI work items/actions:  https://gist.github.com/3085149
18:07:01 <ayoung> status is more like:  have proof of concept working,  need to hammer out those details.
18:07:16 <heckj> soudns good
18:07:37 <heckj> 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 <ayoung> I'm still feeling confident in getting this in
18:07:42 <heckj> #link V3 draft3 https://docs.google.com/document/d/1VP-bTBbwsn6q-rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit
18:07:54 <heckj> ayoung: it looks like you're making excellent progress
18:08:20 <heckj> So to answer rafaduran question, I think we're at the spot where we can start implementing the V3 API
18:08:39 <ayoung> heckj, can we break it down to a series of tickets?
18:09:02 <heckj> 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 <rafaduran> heckj: I'm interested on the querying stuff, I can implement that part
18:09:46 <heckj> 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 <rafaduran> maybe blueprints
18:10:14 <ayoung> bugs works for me...keep using the same system
18:10:22 <ayoung> rafaduran, they can all link to one blueprint
18:10:25 <heckj> 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 <ayoung> just the individual line items
18:11:28 <rafaduran> heckj: that's a interesting, issue, I will try to do some research whenever I have some free time
18:11:32 <heckj> #action: heckj to create tags and bugs with an initial work breakdown
18:12:46 <heckj> 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 <heckj> So - all the stuff depending on V3 IMPL, I'm going to drop from folsom today
18:13:39 <heckj> #action heckj to drop all dependent pieces on V3 API implementation from Folsom series
18:14:15 <heckj> I'm expecting some hollerin', but I just don't see the work getting done otherwise.
18:15:00 <heckj> Any questions?
18:16:55 <heckj> Okay - ayoung, did you want to get into any more detail about the PKI/signed tokens stuff?
18:17:06 <heckj> (and we have rafarduran's topic pending)
18:17:13 <ayoung> heckj, just to give a 1 line summary
18:17:42 <ayoung> I am going to make it so the two types of tokens can coexist in order to simplify the upgrade process.
18:18:11 <ayoung> Anyone interested in the details (beyond the gist I wrote above) can chat after the meeting
18:18:46 <heckj> sounds good, thanks ayoung
18:18:53 <heckj> rafaduran: you're up
18:19:00 <rafaduran> ok, thanks
18:19:02 <heckj> #topic rate limiting middleware - feedback and corner cases
18:19:05 <ayoung> BTW,  please send me review requests
18:19:16 <ayoung> I'' try to grab them if I see them,
18:19:41 <rafaduran> As I said in previous meetings I'm working on a rate limit middleware
18:19:56 <rafaduran> #link https://blueprints.launchpad.net/keystone/+spec/keystone-rate-limiting
18:20:10 <rafaduran> I've updated the related bluprint
18:20:21 <rafaduran> and the code start looking good
18:20:35 <rafaduran> #link https://github.com/rafaduran/keystone/tree/bp/keystone-rate-limiting
18:21:05 <heckj> #link https://github.com/rafaduran/keystone/tree/bp/keystone-rate-limiting
18:21:06 <rafaduran> but I still need some feedback/help on some situations
18:21:40 <rafaduran> specially on how to map requests to limits
18:21:56 <rafaduran> I consider thre cases
18:22:26 <rafaduran> requests that doesn't need authentication, authentication requests and authenticated requests
18:22:39 <rafaduran> so my first idea was map tokens to user id
18:23:04 <rafaduran> but now I'm not really sure, maybe it would be more useful map to usernames
18:23:56 <rafaduran> a use case is devstack, if this is ever used would be much more difficult the devstack configuration
18:24:24 <rafaduran> you need to create users, get the id and if you wan a custom limit then change keystone configuration
18:24:32 <heckj> 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 <ayoung> 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 <heckj> 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 <heckj> ayoung: ++
18:25:35 <rafaduran> heckj: not, I want limits by user
18:26:16 <rafaduran> but, how to map that user to the request is not clear
18:26:49 <rafaduran> but as ayoung said probably is better send an email to the mailing list
18:26:50 <heckj> 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 <heckj> I'm happy to wait if you'd prefer to do that
18:28:15 <rafaduran> I want map users because I think I need track somhow the reqeusts
18:28:30 <ayoung> #action rafaduran to write up design questions for rate limiting
18:28:45 <heckj> #action rafaduran to write up design questions for rate limiting
18:28:50 <rafaduran> I mean, I need limit someone/something
18:28:57 <rafaduran> maybe I'm wrong with that
18:29:01 <heckj> (I think I need to do all those to get them into the logs - very annoying, but I'm not sure)
18:30:57 <rafaduran> the idea also comes from how nova middleware  works (it maps by username)
18:31:09 <rafaduran> and my work started from it
18:33:18 <rafaduran> 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 <rafaduran> since there is no API changes it should be, but I can miss something
18:33:51 <ayoung> 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 <rafaduran> ayoung: I've added the link when start writing
18:35:11 <rafaduran> https://github.com/rafaduran/keystone/tree/bp/keystone-rate-limiting
18:35:11 <ayoung> SOunds good
18:35:49 <rafaduran> it's not finished and I need solve what the mapping issue
18:36:04 <rafaduran> but that's pretty much my idea
18:36:27 <ayoung> rafaduran, OK...It will take me some time to digest.
18:37:49 <rafaduran> ayoung: you can check the middleware stuff directly
18:37:51 <rafaduran> https://github.com/rafaduran/keystone/blob/bp/keystone-rate-limiting/keystone/contrib/rate/core.py#L283
18:38:53 <ayoung> rafaduran, OK,  so with PKI,  getting info out of the token should be cheaper....no need for a remote call
18:38:59 <ayoung> hmmm
18:39:38 <ayoung> 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 <rafaduran> yes, I was thinking about that too
18:40:51 <rafaduran> ayoung: you might add the compatibility layer into it
18:40:59 <ayoung> 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 <rafaduran> ok
18:41:21 <ayoung> rafaduran, sounds about right...I'd have to look in to it to grok completely
18:42:22 <rafaduran> heckj: implementation apart, I'm not really sure how to proceed in order to get the bp reviewed/approved
18:42:31 <heckj> sec...
18:44:14 <heckj> reading backtrace really quick - had to take a phone call
18:44:37 <heckj> ayoung: re: populating the request context from the token, yes - I think that's an excellent idea
18:45:17 <heckj> 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 <ayoung> #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 <heckj> 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 <heckj> rafaduran: anything more?
18:47:46 <rafaduran> no, I think that's all for now
18:47:53 <heckj> #topic open discussion
18:48:13 <heckj> I don't have anything more - just finished cleaning up the blueprints and unlinking a pile of things from Folsom
18:48:37 <heckj> #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 <rafaduran> heckj: one more thing about the querying
18:49:12 <heckj> rafaduran: shoot
18:50:32 <rafaduran> 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 <rafaduran> so it can be included into the querying
18:51:57 <heckj> 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 <ayoung> 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 <heckj> ayoung: heh, sorry :-)
18:52:44 <heckj> 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 <heckj> I was wayyyyyy to naive about how long it would take to nail down a revised and consolidated API
18:53:26 <heckj> BTW: Any complains about renaming tenants back to projects? Now's the time to bitch...
18:53:39 <ayoung> 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 <heckj> My highlights would be PKI, bug fixes and stability, solid work towards an updated core API
18:54:31 <ayoung> 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 <heckj> dtroyer: since you're online, how's the progress on https://blueprints.launchpad.net/keystone/+spec/command-options?
18:55:55 <dtroyer> heckj: it was merged last week
18:55:56 <heckj> 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 <heckj> dtroyer: fully implemented to what you wanted? (I haven't looked)
18:56:29 <dtroyer> heckj: yes
18:56:37 <heckj> dtroyer: thxusir! BP updated
18:56:46 <dtroyer> heckj: thx, I forgot to do that...
18:56:48 <ayoung> heckj, are all of the openstack projects aligned with using the term "project" ?
18:57:30 <heckj> 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 <ayoung> heckj, good
18:57:47 <ayoung> works for me
18:57:57 <heckj> Glance uses different terms entirely (members, grouping) - which can be applied to whatever
18:58:25 <heckj> thanks all - I've got to wrap this up and make a meeting in 2 minutes.
18:58:59 <heckj> 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 <heckj> #endmeeting