18:01:53 <dolphm> #startmeeting keystone
18:01:54 <openstack> Meeting started Tue Apr 22 18:01:53 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:55 <nkinder_> hi all
18:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:58 <openstack> The meeting name has been set to 'keystone'
18:02:34 <dolphm> alright, i was waiting on sched.org... but that looks like it's going to take more than a couple minutes...
18:02:39 <dolphm> anyway:
18:02:42 <dolphm> #topic Icehouse released!
18:02:49 <morganfainberg> w00t!
18:02:52 <ayoung> ＼(◎o◎)／
18:03:04 <stevemar> woot woot
18:03:18 <dolphm> #link http://lists.openstack.org/pipermail/openstack-announce/2014-April/000225.html
18:03:21 <topol> Great job! Congrats!!!
18:03:36 <topol> Lot of great stuff in icehouse
18:03:45 <nkinder_> woohoo!
18:03:52 <dolphm> "Thanks to the hundreds of people who contributed to this development cycle and helped in making this release great!" <-- i can't echo that enough!
18:04:32 <ayoung> Here's a special thank you to our own Atlas.  Three cheers for the PTL.  Well done, dolphm
18:04:39 <lbragstad> ++
18:04:40 <gyee> good stuff!
18:04:42 <topol> +++++
18:04:46 <stevemar> +++
18:04:49 <dolphm> it's been surprisingly quiet on the bug front, so i'm hesitantly excited about that too :P
18:04:52 <topol> Great job dolphm!!!
18:04:56 <morganfainberg> +++++
18:04:56 <dolphm> ayoung: danke
18:05:07 <atiwari> +++
18:05:38 <dstanek> ++
18:05:44 <jamielennox> ++
18:05:54 <dolphm> more fun stuff...
18:05:57 <dolphm> #topic Design summit schedule
18:06:06 <dolphm> #link http://junodesignsummit.sched.org/
18:06:30 <dolphm> i *just* pushed a tentative schedule to sched.org a few minutes ago, so the keystone track should appear there at some point ^
18:07:08 <dolphm> in the mean time, it looks something like this:
18:07:09 <dolphm> #link http://i.imgur.com/Mglw49y.png
18:07:36 <bknudson> 8 sessions?
18:07:48 <dolphm> this is very much a first draft: timeslots WILL be shuffled, etc
18:07:54 <dolphm> bknudson: yes
18:08:02 <dolphm> bknudson: one fewer than previous summits due to the cross-project tack
18:08:04 <dolphm> track*
18:08:22 <topol> dolphm, looks good
18:08:34 <nkinder_> more reason to schedule a mid-cycle hackfest
18:08:43 <dolphm> nkinder_: ++
18:08:51 <topol> in San Antonio. Bring the pace pciante salsa
18:08:59 <nkinder_> ..get a rope
18:09:00 <topol> ++
18:09:03 <dolphm> we should also be a bit more organized for topics outside of formal design sessions
18:09:23 <gyee> just look for dolphm at the developer's lounge
18:09:26 <morganfainberg> mid-cycle fun again!
18:09:28 <nkinder_> yeah, there are some topics that would be nice to discuss that aren't in the sessions
18:09:34 <dolphm> gyee: you should be able to look for a keystone flag or something :)
18:09:42 <dolphm> gyee: not sure how it's all going to work yet
18:09:44 <gyee> grease him with beer, money, or whatever
18:09:50 <morganfainberg> gyee, whiskey
18:09:52 <topol> those breakfast burritos were good.  I hope the lamb food truck is there this time
18:09:57 <bknudson> if we're going to discuss service catalog we should consider what we're going to do with templated catalog
18:10:05 <morganfainberg> bknudson, ++++
18:10:07 <bknudson> since it seems to be getting left behind
18:10:14 <gyee> morganfainberg ++
18:10:15 <ayoung> Leav it behind
18:10:21 <morganfainberg> bknudson, i'm kindof for making it disappear.
18:10:43 <topol> how do we know there arent folks relying on it?
18:10:45 <ayoung> it can easily be supported by SQL, or a KVS impl, so why keep a readonly, hard coded version?
18:10:46 <morganfainberg> bknudson, its suboptimal on many fronts.
18:10:46 <gyee> bknudson, catalog is a big elephant we need to tackle
18:10:48 <dstanek> morganfainberg, bknudson: does anyone use it?
18:10:57 <morganfainberg> dstanek, unfortunately we do
18:11:12 * ayoung is visualizing gyee tackling an elephant.  It is quite entertaining.
18:11:23 <morganfainberg> dstanek, but it caused us major issues so we will move off it as soon as possible
18:11:27 <ayoung> dstanek, we deprecate, and see if anyone shouts
18:11:28 <dolphm> topol: lack of bug reports, for starters. we're aware of issues that our users don't seem to care about
18:11:29 <bknudson> you can't get a v3 token using the templated catalog now
18:11:47 <gyee> ayoung, I mean elephant in the room, american thing, you don't want me to translate into other language
18:12:03 <dolphm> i'd be happy to fix it if there are users
18:12:06 <ayoung> WE NEED V2 /V3 INTEROP OR WE WILL NEVER GET PEOPLE TO V3
18:12:28 <morganfainberg> this sounds like a ML topic to me
18:12:31 <dolphm> ayoung: i suspect that will be a significant topic for the client session
18:12:33 <ayoung> ++
18:12:34 <morganfainberg> probably x-posted to operators
18:12:53 <ayoung> dolphm, wasn't there a miniscule patch that did the "chop v.20" off the endpoints?
18:13:02 <dolphm> ayoung: that landed
18:13:10 <dolphm> ayoung: i think it's in 0.7.0
18:13:13 <jamielennox> ayoung: it got merged - it doesn't really cover everything though
18:13:15 <ayoung> Ah...I was looking for it.  Good.
18:13:16 <morganfainberg> preferably I'd like that mail to be out there before we hit the summit so we have some information
18:13:17 <morganfainberg> if needed i can write that email up.
18:13:24 <ayoung> jamielennox, I realize, but its a start
18:13:55 <ayoung> jamielennox, what critical is missing?
18:14:00 <dolphm> morganfainberg: i'd like to tackle that v2 deprecation bp in the next coupld weeks
18:14:15 <ayoung> I mean, aside from support for other services....anything specific to Keystone>
18:14:16 <ayoung> ?
18:14:22 <jamielennox> https://review.openstack.org/#/c/81146/
18:14:23 <morganfainberg> dolphm, yeah good plan
18:14:33 <topol> dolphm in any of the federated sessions can we discuss audit support for federated environments?
18:14:50 <morganfainberg> topol, i thiink the answer is "we should emit audit for it"
18:15:03 <dolphm> topol: i think it's a given that we'll need to emit the appropriate audit notifications -- what is there to discuss?
18:15:05 <morganfainberg> topol, and anyone who complains about it is probably wrong
18:15:07 <jamielennox> ah, it's been a while - i can't find the dependant one
18:15:22 <topol> OK, so handle the details via blueprints. Thats cool
18:15:25 <stevemar> dolphm, there are a bunch of sessions marked as unreviewed, should those be considered rejected?
18:15:46 <morganfainberg> topol, yep, it would be silly not to do audit
18:15:57 <dolphm> stevemar: likely, yes - unless i meant to merge something and didn't. i updated the statuses of as few as possible in a flurry right before this meeting
18:15:59 <ayoung> jamielennox, starrring that one...
18:16:13 <stevemar> dolphm, cool
18:16:30 <jamielennox> ayoung: there are a couple in my client list to do with discovery, version-less auth etc
18:16:40 <jamielennox> the one i can't find is version-less endpoints in the catalog
18:16:44 <jamielennox> it should dep on that one
18:16:57 <nkinder_> As an aside, has using gerrit for blueprints been previously discussed at all? (nova started doing this recently)
18:17:13 <lbragstad> I think that led into a discussion about storyboard
18:17:24 <sjcazzol_> I was creating an specification to add quotas for users/projects by domain in the blueprint tenants-users-quotas
18:18:32 <sjcazzol_> what do you think about this blueprint?
18:18:36 <gyee> jamielennox, is the discovery mechanism a standard or something we came up with
18:19:05 <jamielennox> gyee: it's something that is close to standard (which is possibly worse)
18:19:24 <jamielennox> gyee: we forked it from nova - and made changes, other projects either did the same or came up with there own
18:19:43 <gyee> jamielennox, I think TC should take on this one
18:19:49 <sjcazzol_> this blueprint is in the path to get parity on quota management with AWS
18:19:52 <dolphm> nkinder_: yes
18:19:53 <gyee> as it has wider impact
18:20:08 <jamielennox> gyee: i did a spec a while ago https://wiki.openstack.org/wiki/VersionDiscovery
18:20:23 <dolphm> gyee: ++
18:20:32 <jamielennox> gyee: publicised as much as i could and was well received - but who knows if people look at it
18:20:53 <jamielennox> gyee: the problem is no one will change because they all need backwards compat
18:21:12 <dolphm> jamielennox: the only opposition i recall is that there's an IETF draft of something similar?
18:21:21 <jamielennox> or at the very least we need to support older versions pre-changed because we can't afford  to wait for them all to standardize
18:21:28 <morganfainberg> dolphm, really an IETF draft?
18:21:47 <jamielennox> dolphm: not an IETF thing - there's a json-home spec which one of the new projects is using
18:21:51 <dolphm> morganfainberg: well there's a few, but one actually has some traction IIRC
18:21:54 <morganfainberg> ah.
18:22:03 <dstanek> dolphm: url?
18:22:08 <dolphm> #link http://tools.ietf.org/html/draft-nottingham-json-home-02
18:22:13 <dolphm> not sure if that's the latest
18:22:17 <jamielennox> AFAIK no-one is actually converting anything though
18:22:26 <dolphm> jamielennox: thanks, i couldn't remember the name
18:22:51 <dolphm> #link https://github.com/otto-de/jsonhome
18:22:54 <morganfainberg> this is something the TC should weigh in on and specify a direction to take since it needs to be consistent across projects
18:23:04 <dolphm> draft 3!
18:23:05 <dolphm> #link http://tools.ietf.org/html/draft-nottingham-json-home-03
18:23:13 <jamielennox> morganfainberg: i don't disagree - but we can't wait for that
18:23:46 <morganfainberg> jamielennox, we may not be able to wait, but we can at least get that up for consideration with the new TC convening soon
18:23:51 <gyee> jamielennox, wait for a consistent approach, or go alone and risk retrofit later? :)
18:23:52 <ayoung> ++
18:24:15 <morganfainberg> jamielennox, if we have a clear direction, we can figure out where we're headed and how to best get there
18:24:16 <ayoung> gyee, or make keystoneclient own the service catalog and just solve it for everyone
18:24:18 <jamielennox> gyee: this is client side, we are always going to have to support older versions
18:24:25 <gyee> retrofitting protocol is much difficult
18:24:32 <morganfainberg> ayoung, ++
18:24:41 <jamielennox> ayoung: that is the plan
18:24:46 <morganfainberg> ayoung, we should absolutely own the SC in either case
18:24:51 <ayoung> and policy
18:25:11 <jamielennox> if anything this means that at least all discovery should come from one place so it should be easier to convert people later
18:25:11 <dolphm> ayoung lost me -- this doesn't have much to do with the catalog...
18:25:15 <morganfainberg> ayoung, that is a slightly different topic...but don't disagree.
18:25:34 <morganfainberg> ayoung, lets table the policy bit from this convo, it's not directly relevant
18:26:26 <ayoung> sure
18:26:31 <jamielennox> for comparison dtroyer has a similar discovery mechanism in OSC and (i think it's new again) in -SDK
18:26:50 <jamielennox> anything that expects to work across projects is going to have a really bastardized/hacky discovery mechanism
18:27:16 <morganfainberg> jamielennox, ok so i come back to we need the TC to set the direciton then work to get from here to there -- however hacky it is.
18:27:35 <morganfainberg> jamielennox, but making another standard.....
18:27:36 <gyee> morganfainberg, amen, brother
18:27:46 <morganfainberg> jamielennox, wait isn't there an XKCD about standards.
18:27:53 <jamielennox> morganfainberg: right - but that's a future direction. we don't get to wait for interop until the TC makes all projects convert to a standard
18:28:16 <gyee> jamielennox, then what is TC for?
18:28:24 <nkinder_> can't we do both?  Start consulting with the TC, but let them know we need to forge ahead?
18:28:30 <gyee> ceremonial?
18:28:32 <morganfainberg> nkinder_, ++
18:28:34 <nkinder_> we might get at least some early guidance
18:28:36 <jamielennox> i honestly couldn't care less what the format is, we need to get people moving to v3 and that doesn't happen until we can do discovery
18:28:43 <ayoung> lets provide them with a solution
18:28:46 <morganfainberg> nkinder_, i think we can get an answer on where we are doing and work towards it without interop
18:29:07 <nkinder_> yes, we might serve as the model for the standard if we start working with the TC from the outset
18:29:11 <jamielennox> the wiki i linked earlier was the most common elements of nova/keystone/glance etc the older projects
18:29:25 <jamielennox> the projects that were going to find it most difficult to change
18:29:30 <ayoung> I think what jamielennox was driving towards works for the majority of the services. The ones it doesn't work for are one-offs anyway
18:29:41 <ayoung> and will require specific fixes that are not generalizable
18:29:46 <morganfainberg> nkinder_, we should get the TC involved before we get too deep into the impl so we don't end up with yet-another-standard
18:29:57 <dolphm> i suspect nottingham's proposal was at least in part a result of his time spent working in/around openstack
18:30:05 <jamielennox> morganfainberg: this is not creating a standard - it's reacting to existing standards
18:30:38 <ayoung> jamielennox, please make sure the relevant reviews have keystone-core +nkinder set as reviewers
18:30:40 <jamielennox> dolphm: i didn't think he had anything to do with openstack
18:30:55 <morganfainberg> jamielennox, and if we go create an implementation to solve that... without clear direction that this is the way going forward, we have created another "standard" that the new system needs to support
18:31:15 <jamielennox> dolphm: the way i read it it was related to the json-api stuff, but it's been a while
18:31:18 <dolphm> jamielennox: http://www.mnot.net/personal/resume.html
18:31:24 <morganfainberg> jamielennox, i'm not saying don't do the work, i'm saying concurrently involve the TC so we know where we need to eventually land and we don't write ourselves into a corner reacting to the current situation
18:31:25 <topol> would it be worth an email on the mailing list to see if anyone still uses the templated catalog?
18:31:42 <topol> just to do a little cya for us if we pull it?
18:31:45 <morganfainberg> topol, yes. x-posted to operators list as well
18:31:58 <topol> morganfainberg will you handle that?
18:32:17 <morganfainberg> topol, yeah was planning on it once the meeting was done since no one responded to my earlier question
18:32:24 <topol> cool
18:32:31 <dstanek> json-home appears to be a document format - what does that have to do with discovery?
18:32:37 <ayoung> So...we should make a concerted push on all client issues in the lull between now and the summit
18:32:43 <dolphm> morganfainberg: awesome
18:32:45 <morganfainberg> topol, just going to ask for metrics on use not indicate we're trying to remove it.
18:32:52 <ayoung> aside from discovery....thkns for the help thus far on comporessed tokens
18:32:53 <morganfainberg> topol, don't want to induce panic
18:32:58 <jamielennox> morganfainberg: sure, that's what i tried to do with that wiki page - but client still claims compatability with like essex clouds so we are going to have to react to the current
18:33:09 <ayoung> https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient,n,z    quite a few there still
18:33:14 <dstanek> it's more about navigating hypermedia to navigate the API - similar to what html provides
18:33:26 <morganfainberg> jamielennox, and thats fine. lets get this on the agenda for the TC first thing and start the work now.
18:33:51 <morganfainberg> jamielennox, we can put some compat stuff in as needed for the old deployments
18:34:23 <ayoung> https://review.openstack.org/#/c/81166/  revocation API needs to be in the client before it is usable.
18:34:34 <dolphm> ayoung: ++
18:34:45 <morganfainberg> ayoung, +++++
18:35:20 <nkinder_> one other topic that would be nice to discuss at the design summit is keystone scalability/performance
18:35:28 <topol> morganfainberg, nice. good to not induce panic.
18:35:40 <ayoung> jamielennox's client patches  https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+owner:jamielennox,n,z
18:35:42 <stevemar> nkinder_, it doesn't do either well atm :(
18:35:42 <dolphm> nkinder_: absolutely, and i'm sure we will
18:35:45 <morganfainberg> nkinder_, that is plan for the POD/Dev Lounge
18:35:46 <nkinder_> I was talking with someone last week who has a large delpoyment, and keystone is the performance bottleneck
18:36:06 <ayoung> https://review.openstack.org/#/c/74599/  that was the heart of the discussion, right?
18:36:07 <jamielennox> ayoung: on the up side that list is the shortest it's been in a while
18:36:07 <nkinder_> Ok, great.  I know the ephemeral token work is a part of it, but it would be good to outline a plan for other areas too
18:36:19 <stevemar> nkinder_, <sarcasm tell them to flush tokens />
18:36:28 <morganfainberg> nkinder_, yep, and expanding caching, working on improving SQL performance etc
18:36:46 <morganfainberg> nkinder_, lots of things to do
18:36:48 <nkinder_> stevemar: that was my first response, followed by reducing the token validity period :)
18:37:01 <bknudson> a rally person was in openstack-keystone the other day discussing how they can post their results for perf tests
18:37:13 <ayoung> nkinder_, do they have any profiling data?
18:37:21 <nkinder_> ayoung: we can get some I'm sure
18:37:27 <ayoung> and are they on anything modern, or is this an essex setup?
18:37:37 <nkinder_> once thing mentioned was scaling across cores (not just for keystone)
18:37:37 <ayoung> (RHOS 4 I assume)
18:37:41 <nkinder_> ayoung: havana
18:37:45 <morganfainberg> bknudson, yeah i want to sync up w/ the rally guys and get that info going in (probably on the checks)
18:38:31 <ayoung> nkinder_, so, is the bottleneck calling Keystone from Horizon (list users etc) or token request and verification?  Are they using UUID tokens?
18:38:37 <ayoung> Or PKI
18:38:57 <ayoung> RHOS4 == Havana for the rest of the team
18:39:15 <morganfainberg> ayoung, ah yes.
18:39:22 <ayoung> 5 will be Icehouse and so on
18:39:40 <nkinder_> ayoung: spinning up hundreds/thousands of new instances at once
18:39:49 <ayoung> interesting....
18:39:50 <sjcazzol_> I would discuss a bp to add quotas for the # of projects/users created by domain
18:39:53 <nkinder_> ayoung: this was >1000 pyhsical systems
18:39:56 <dolphm> #topic open discussion
18:39:58 <morganfainberg> nkinder_, that is not exclusively a keystone issue but it's def related.
18:40:11 <ayoung> scripted?  Are they reusing tokens or getting a new one for each op?
18:40:15 <morganfainberg> nkinder_, we have had similar complaints (smaller hypervisor counts)
18:40:17 <bknudson> I was wondering if we could discuss https://bugs.launchpad.net/python-keystoneclient/+bug/1287301
18:40:19 <uvirtbot> Launchpad bug 1287301 in python-keystoneclient "Keystone client token cache doesn't respect revoked tokens" [Medium,In progress]
18:40:24 <nkinder_> morganfainberg: sure, other areas are problems too (nova scaling across cpus, etc.)
18:40:29 <morganfainberg> nkinder_, yep
18:40:38 <jamielennox> bknudson: looking
18:41:05 <morganfainberg> nkinder_, they were scripted against the API directly but similar issues, adding neutron in causes more pain (due to token issuance insanity)
18:41:07 <ayoung> gyee is gone...he's the one that held up https://bugs.launchpad.net/python-keystoneclient/+bug/1287301
18:41:17 <bknudson> so the proposed fix was, I think, to check both the token cache AND the revocation list
18:41:20 <ayoung> I still don't understand his concern
18:41:25 <ayoung> I think he's wrong
18:41:28 <bknudson> whereas before it was checking only the token cache
18:41:45 <morganfainberg> bknudson, that was my understanding
18:41:55 <jamielennox> bknudson: i was under the impression that became a non-issue
18:41:57 <bknudson> which doesn't seem like a terrible thing to do
18:42:09 <sjcazzol_> I would discuss a bp to add quotas for the # of projects/users created by domain in https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas
18:42:22 <bknudson> well, the revocation cache and the token cache were changed to have the same timeout
18:42:43 <bknudson> so maybe it is a non-issue?
18:43:17 <jamielennox> sjcazzol_: i think this or something similar has been raised before
18:43:17 <morganfainberg> bknudson, i think it is worth revisiting.
18:43:20 <ayoung> bknudson, yeah, his concern seems ill-=placed.  I PMed him and his response still puzzles me
18:43:29 <dolphm> sjcazzol_: it's open discussion, feel free
18:43:50 <morganfainberg> sjcazzol_, i know there is demand from my company's customers for something like that (when we move to domains)
18:44:13 <ayoung> "If you really want to do it right, get rid of revocation_cache_time and come
18:44:13 <ayoung> up with a lightweight daemon process to listen on the revocation events and update the cache accordingly. Similar to how Certmonger monitoring the certificate status and perform automatic renewal."
18:44:16 <morganfainberg> sjcazzol_, so please :) lets discuss it!
18:44:43 <jamielennox> sjcazzol_: and from memory there are two problems 1 there is no standard quotaing method in keystone or openstack 2. why? users are cheap
18:44:51 <ayoung> sjcazzol_, how are you going to distribute global quotas, and how are you going to enforce?
18:44:51 <bknudson> ayoung: I can see the desire to have some kind of notification... maybe revocation events makes it a non-issue
18:45:00 <morganfainberg> jamielennox, it's project quotas
18:45:03 <ayoung> bknudson, regardless...he's wrong
18:45:03 <morganfainberg> jamielennox, not users.
18:45:14 <jamielennox> morganfainberg: users per project
18:45:22 <morganfainberg> jamielennox, oh wait did i misread it?
18:45:28 <morganfainberg> jamielennox, ah
18:45:32 <jamielennox> users per domain, users per project
18:45:45 <morganfainberg> sjcazzol_, i'm in support of working on a quota of projects per domain
18:45:50 <morganfainberg> sjcazzol, but i don't see a value to users per domain?
18:46:02 <ayoung> bknudson, cache is to keep from doing a validation again, but a revocation event timeout (or revocation list) still needs to be checked.  It doesn't render the cache useless.
18:46:03 <jamielennox> morganfainberg: is it just a billing thing?
18:46:20 <morganfainberg> jamielennox, less billing more they allow anyone to create projects on demand
18:46:25 <nkinder_> I suppose you could prevent someone from adding 1M users that way
18:46:29 <morganfainberg> jamielennox, they would like to limit it because a project can consume a network
18:46:34 <morganfainberg> jamielennox, etc.
18:46:46 <morganfainberg> jamielennox, so you can give them a domain and they get X projects to play with
18:47:10 <gyee> ayoung, you have a question for me, sorry I have a shitty connection here
18:47:15 <morganfainberg> jamielennox, dev, stage, prod, prod2, etc but not 1000 projects
18:47:16 <ayoung> gyee, yeah
18:47:26 <morganfainberg> jamielennox, you can make a policy saying "no don't do that" or you can enforce "you get X projects"
18:47:40 <ayoung> gyee, can you please unblock  https://bugs.launchpad.net/python-keystoneclient/+bug/1287301
18:47:46 <uvirtbot> Launchpad bug 1287301 in python-keystoneclient "Keystone client token cache doesn't respect revoked tokens" [Medium,In progress]
18:47:49 <bknudson> gyee: https://review.openstack.org/#/c/78241/
18:47:53 <ayoung> I think you are wrong in that it does not invalidate the value of the cache
18:48:00 <jamielennox> morganfainberg: fair enough, it'd be nice if this stuff was a bit more generic across openstack
18:48:05 <morganfainberg> jamielennox, yeah
18:48:23 <ayoung> cache in this case will prevent a popen openssl cms call
18:48:25 <jamielennox> morganfainberg: i wouldn't prefer not to have a whole quotaing system within keystone
18:48:27 <gyee> that one doesn't *fix* the problem completely
18:48:31 <bknudson> since https://review.openstack.org/#/c/78241/ is abandoned, may not be able to re-do
18:48:41 <ayoung> and you still want to check that the token is not revoked separate from cached timeout
18:48:51 <morganfainberg> jamielennox, ++ consistent quota system would be nice. but i don't think we have anything like that yet*
18:48:51 <dolphm> jamielennox: is that a +1 for a standalone quota service? :D
18:48:56 <ayoung> we can resubmit in a different reviewid if needs be
18:49:06 <jamielennox> dolphm: i think i +1ed that a while ago
18:49:09 <dolphm> morganfainberg: there is actually an abandoned standalone quota service
18:49:11 <sjcazzol_> morganfainberg, what about to have quotas for user but per project instead of domain?
18:49:13 <dolphm> jamielennox: probably so
18:49:22 <morganfainberg> bknudson we can have infra restore a review
18:49:23 <gyee> ayoung, best we can do is reverse the order between revocation cache and token cache
18:49:31 <ayoung> ?
18:49:36 <dolphm> gyee: reverse the check?
18:49:41 <dolphm> order of checks*
18:49:42 <gyee> dolphm, yes
18:49:44 <ayoung> gyee, that makes no sense
18:49:46 <morganfainberg> sjcazzol_, i don't see a value to limiting the number of users in that regard, what is the value / usecase?
18:49:47 <morganfainberg> sjcazzol_, users are cheap.
18:49:56 <gyee> right now token_cache_time have priority over revocation_cache_time
18:50:05 <ayoung> we pull the token out of memcached first, check against the revocation list second
18:50:10 <gyee> that patch, if implemented correct, will reverse the order
18:50:24 <bknudson> currently we're not checking revocation list if it's in the cache
18:50:25 <gyee> and that's it, but its still not real time
18:50:28 <morganfainberg> gyee, if we hit the cache, no popen call
18:50:45 <morganfainberg> gyee, avoiding popen would be good?
18:50:49 <morganfainberg> gyee, doesn't mean we shouldn't also check revocation list
18:51:24 <gyee> morganfainberg, yes, it's only helpful if token_cache_time is much greater than revocation_cache_time
18:51:32 <morganfainberg> gyee, oh i see, no popen is needed if we check TRL first
18:51:35 <gyee> right now they are both default at 300 seconds
18:51:45 <bknudson> both those cache times are configurable.
18:51:56 <gyee> lemme unblock, but that's just an half-ass solution
18:52:05 <sjcazzol_> morganfainberg, I think it should be to avoid performance issues
18:52:30 <morganfainberg> sjcazzol_, i would argue that limitation is premature optimisation
18:52:40 <gyee> if you want real time check, implement a lightweight process to listen on revocation events and update the cache
18:52:59 <gyee> similar to certmonger
18:53:30 <sjcazzol_> morganfainberg, yes
18:53:31 <morganfainberg> gyee, sure. better solution, but we should make things incrementally better if we can as well.
18:53:53 <jamielennox> gyee: also a standalone service on every machine with auth_token is a big ask
18:54:13 <gyee> jamielennox, no
18:54:22 <ayoung> gyee, you mean thread, right?
18:54:29 <gyee> memcached is usually running in a ring
18:54:32 <morganfainberg> ayoung, thread/process same thing right?
18:54:34 <gyee> you just need one process
18:54:35 <dolphm> jamielennox: on every machine?
18:54:45 <morganfainberg> ayoung, when you involve external (memcache) kvs for the cache
18:54:46 <morganfainberg> ayoung, this isn't in-mem
18:54:47 <sjcazzol_> morganfainberg, also it could be used to charge extra money in case a domain is requesting more users/projects
18:55:01 <ayoung> its like token_flush.
18:55:08 <jamielennox> dolphm: i guess it depends on where memcache is
18:55:22 <jamielennox> but i'm guessing for auth_token it's largely just on the same machine
18:55:24 <gyee> ayoung, can't unblock, patch is abandon
18:55:32 <ayoung> revoation list fetch could easily be done external to the flow, but it would not make a difference.
18:55:33 <gyee> author needs to restore it first I guess
18:55:36 <nkinder_> I'd like to briefly discuss the keystone security info wiki pages while we still have a few minutes (or we can take it to #openstack-keystone afterwards)
18:55:49 <ayoung> gyee, NP.  so long as you agree in principal to the direction, we can create a new review if necessary
18:56:13 <nkinder_> I've added a new security info page for keystone in Juno now that Icehouse has been released
18:56:20 <gyee> ayoung, I don't agree with the current impl, but its some improvement nevertheless
18:56:23 <morganfainberg> sjcazzol_, sure, lets work on figuring out quota stuff and we can implement as many/few quota implements then (argue about the individual ones)
18:56:40 <dolphm> jamielennox: ah, i thought you were referring to another web service
18:56:46 <morganfainberg> nkinder_, awesome!
18:56:49 <nkinder_> I added a new section at the bottom to cover security items that have changed since the previous release
18:56:54 <bknudson> I asked on -infra if https://review.openstack.org/#/c/78241/ could be restored.
18:57:03 <dolphm> gyee: leave a comment that you'll unblock when the author restores?
18:57:04 <nkinder_> https://wiki.openstack.org/wiki/Security/Juno/Keystone#Notable_changes_since_Icehouse
18:57:12 <gyee> dolphm, sure
18:57:35 <nkinder_> We have a few things in progress that I called out there (and the LDAP hashing patch that landed)
18:57:49 <morganfainberg> i hear we might have a new gerrit soon™, and i think cores will be able to restore patches for their project from abandoned
18:57:53 <bknudson> gyee: https://review.openstack.org/#/c/78241/ is restored now
18:57:53 <ayoung> gyee, I think you are caluclating wrong
18:57:59 <dolphm> this showed up at some point:
18:58:00 <dolphm> #link http://junodesignsummit.sched.org/overview/type/keystone
18:58:04 <dolphm> design summit schedule ^
18:58:12 <dolphm> (TENTATIVE)
18:58:24 <ayoung> cache time of 300 starts when token is validated.  Revocation cache time is every 300 regardless.  They do not necessarily align
18:58:25 <dolphm> also, time's up
18:58:28 <bknudson> looks like I don't have to show up until wed
18:58:34 <morganfainberg> bknudson, hehe
18:58:42 <dolphm> bknudson: cross-project tracks tuesday
18:58:45 <morganfainberg> bknudsonm there are cross project things on tuesday
18:58:55 <dolphm> #endmeeting