Monday, 2016-01-25

*** EinstCrazy has joined #openstack-keystone00:03
* notmorgan continues on campaign to fix caching ick00:04
*** shoutm has joined #openstack-keystone00:05
*** EinstCrazy has quit IRC00:08
*** dims_ has joined #openstack-keystone00:19
*** shoutm_ has joined #openstack-keystone00:20
*** dims has quit IRC00:22
*** shoutm has quit IRC00:22
notmorganjamielennox: http://paste.openstack.org/show/484783/ the kwarg aware funciton_key_generator00:27
notmorganand it has to be py2.6 compat so... dict(()) version of dict comprehensions00:28
*** rcernin has quit IRC00:30
notmorgansome minor fixes i've done since. but it's essentially ... the same00:31
notmorganjust changes the self detection00:31
notmorganoh that is horrifying00:34
notmorganthe multi key thing is unlikely to ever work.00:34
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/26947900:34
*** dslev has joined #openstack-keystone00:34
*** boris-42 has joined #openstack-keystone00:39
*** simondodsley has quit IRC00:48
*** lhcheng has quit IRC00:56
*** henrynash has joined #openstack-keystone01:00
*** ChanServ sets mode: +v henrynash01:00
*** dims_ has quit IRC01:00
*** dslev has quit IRC01:05
*** lhcheng has joined #openstack-keystone01:15
*** ChanServ sets mode: +v lhcheng01:15
openstackgerrithenry-nash proposed openstack/keystone: Verify project unique constraints for projects acting as domains  https://review.openstack.org/15837201:16
*** shoutm_ has quit IRC01:19
*** shoutm has joined #openstack-keystone01:20
*** shoutm_ has joined #openstack-keystone01:27
*** dims has joined #openstack-keystone01:27
*** dims has quit IRC01:27
*** shoutm has quit IRC01:28
*** davechen1 has joined #openstack-keystone01:31
*** hogepodge has joined #openstack-keystone01:34
notmorganstevemar: we should deprecate the current template driver (catalog) and do a quick implementation of a YAML or JSON based templated thing01:35
notmorganstevemar: so people can still do CMS managed disk-based catalog just not the horrible templated driver we have01:35
*** davechen has joined #openstack-keystone01:36
*** davechen1 has quit IRC01:38
jamielennoxnotmorgan: i essentially volunteered for this at summit01:38
*** hogepodge has quit IRC01:38
*** markvoelker has joined #openstack-keystone01:42
openstackgerritMorgan Fainberg proposed openstack/keystone: Make AuthContext depend on auth_token middleware  https://review.openstack.org/25568601:44
*** boltR has quit IRC01:45
*** boltR has joined #openstack-keystone01:46
*** markvoelker has quit IRC01:46
notmorganjamielennox: so what is needed for ksm to use oslo.context properly and keystone to work with that now?01:57
notmorganjamielennox: cause, i would like to see that soooooon01:57
jamielennoxnotmorgan: so ksm doesn't have much to do with it, ksm is a producer01:57
jamielennoxoslo.context is created based on the output of auth_token01:58
notmorganright. we just want to make sure we're getting an oslo.context in keystone01:58
jamielennoxkeystone integration with auth_token is ready to go now that ksm has had a release01:58
notmorganand if that is relying on ksm, what is needed?01:58
jamielennoxoslo.context hasn't released the from_environ patch afaik01:58
notmorganright, did a rebase/waiting for check01:58
notmorganwhen did it land?01:58
jamielennoxnot long01:58
notmorganlike since mitaka-2?01:58
notmorganand we should explicitly ask for a release if they'd be open to it so we can unblock our work01:59
notmorgani think it is a reaosnable request "hey this is super duper important for us"01:59
jamielennoxnotmorgan: it's not a blocker, it's a helper function we can rely on when it's there01:59
notmorganok01:59
*** Ephur has quit IRC01:59
jamielennoxwe already construct an oslo.context in keystone01:59
notmorganso if it isn't there can we still get to the oslo_context stuff?01:59
notmorganahhhh when did that change?01:59
jamielennoxwe have to to do logging and notifications01:59
jamielennoxbut there's nothing very useful in it01:59
notmorganoh neato01:59
notmorganhey, then i can already leverate it02:00
notmorganwithout anything else02:00
notmorgansince there is a thread.local, right?02:00
notmorganleverage it*02:00
jamielennoxfrom memory you would need to fill it02:00
notmorgani expect i need to anyway02:00
jamielennoxhttps://review.openstack.org/#/c/255686/5/keystone/middleware/auth.py L16002:01
notmorganok hmm.02:01
notmorganso i don't care about the other data in the oslo.context02:01
notmorganjust so i have a well-defined place to stash these lookups02:02
jamielennoxi wasn't thinking of using the threadlocal part of oslo.context - but i wouldn't really object, i just don't particularly like thread locals :)02:02
jamielennoxnotmorgan: you should care about the other data02:02
notmorganjamielennox: not in what i'm looking to do ;)02:02
notmorganjamielennox: the other data is useful for otherthings02:02
jamielennoxnotmorgan: context.user == user_id etc so you can use that instead of doing lookups02:02
notmorganright, except we still need to do a user_lookup one time02:03
jamielennoxnotmorgan: nope02:03
notmorganand if it is populated via the manager ever [inc. from building the context] my data will be populated as verified02:03
jamielennoxnotmorgan: auth_token middleware handles token validation, that's it02:03
notmorganso if the ATM does the manager call [i assume it does in this case?]02:04
notmorganit would still populate the data the way i want to do this02:04
notmorgani want to hook into dogpile so any call down populates the lookup for us.02:04
notmorganand it's effectively a 2-layer cache02:04
notmorganthread.local cache and the shared-cache02:04
notmorganthe thread.local cache is for this request, don't ever ask the driver again, or memcache, or anything02:05
notmorganthe shared cache is the typical caching layer02:05
jamielennoxnotmorgan: i would subclass oslo.context's twice02:05
jamielennoxone for CRUD where you are given a token, one for token creation where you construct a token02:06
notmorganoh sure.02:06
jamielennoxthe CRUD should be exactly the same as everyone else02:06
notmorganone from authenticate and one for authenticate_for_token02:06
jamielennoxif you want to do fancy cache integration for token creation then whatever02:06
notmorganor whatever it is02:06
* jamielennox would still like to see those two services logically split02:07
notmorganright02:07
notmorgani have some ideas on some helper funcs we can add to make that more explicit02:07
notmorganrather than .get_user()['id'] all the time we make a .get_user_id() which is smart enough to look in the context if it's there.02:07
notmorganand then passes through and down, if it hits the backend query, it would populate the user_data anyway02:08
jamielennoxi think you've got that backwards02:08
jamielennoxyou should always ask the context and let it fill it in if not present02:08
notmorganhow does the context fill it in ? .get_user()['id']?02:09
notmorganbad example cause we use user_ids.02:09
notmorganuser_project_id02:09
notmorganit still has to talk to the manager02:09
notmorganat some point02:09
jamielennoxhmm, maybe for token creation that's not valid02:10
notmorganthe way i see it is we make a helper function that knows how to look this up, if it can't find it it just hits the backend, and that populates the cache02:10
notmorganand subsequent .get_user() for any data would be a local-in-mem cache hit02:10
notmorganif it is in context, we don't even need to worry about the cache hit02:10
notmorganthat way asking for id becomes more explicit.02:11
notmorganand because we have cache hits we can expand the methods to be less "ask for the SQLA thing" and "ask for the element we care about"02:11
notmorganthe manager can handle that logic02:11
notmorganand we'll always look to our request-specific cache first or where appropriate the context from auth_middleware02:12
jamielennoxi'd prefer not to mix those concepts02:12
notmorganso for example: .get_user_project_id() - if in_context, return, if not, context populates it, but also populates a local cache so all future "give me user_project_thing" requests hits the request local cache02:13
notmorganfor the life of the request02:13
jamielennoxconstruction can be/has to be a special case, but there's no reason you should need to ask the manager for a project_id when you've been through auth_token middleware02:13
* notmorgan doesn't care if the "get_useR_project" is a functionl of the context or not02:13
notmorganit can always be ask the context and the context will ask the manager if needed02:14
notmorganbut there are other things we do, operations that involve not-my-project and not-my-domain etc, it can always be cached in the same way under the hood.02:15
notmorganso maybe what we need is 3 subclasses?02:16
notmorganbase[with cache]02:16
notmorgantoken_constructor02:16
notmorganand CRUD02:16
jamielennoxnotmorgan: yep we will always need to do some of that - but those calls never happen in a token construct right?02:16
notmorganwell in token construct they do, we do a lot of "look to see if X thing is there"02:16
notmorganover and over02:16
jamielennoxyou will always need a way to do get_project() for listing or whatever02:17
notmorganright02:17
notmorganso, i think the cache concept makes sense regardless02:17
notmorgansome times you'll ask the manager, sometimes you'll ask the context.02:17
jamielennoxyea, it's just figuring out a pattern02:17
jamielennoxcontext is always current user, manager is always give me general info02:17
notmorganso my thought is lets cache it all, then worry about asking context appropriatelyu02:17
jamielennoxcache goes behind that regardless02:17
notmorganyeah02:18
notmorganexactly02:18
notmorganso if your thing lands i can do my thing pretty low-cost ways02:18
jamielennoxnotmorgan: we can do the thread local stuff anyway as oslo.cache is already there02:19
notmorganjust build a dogpile proxy and always apply it and then make it so disable simply always returns NO_VALUE from the backend so regeneration always occurs02:19
notmorganoh we already have it?02:19
jamielennoxwe would need buy in on a blueprint to use that object though rather than the current context dict02:19
jamielennoxnotmorgan: https://github.com/openstack/keystone/blob/master/keystone/middleware/auth.py#L14702:19
jamielennoxso defined for all CRUD operations02:20
notmorganjamielennox: for all requests02:20
notmorganeven auth02:20
notmorganright?02:20
notmorgandoes that mean the thread.local thing is there? because it means i can do a speculative change to implement this immediately for testing performance gains02:21
jamielennoxnotmorgan: sorry yes02:21
notmorganfantastic02:21
notmorganso i don't need to change anything except make a subclass that i can store in and access from02:21
notmorgansweet.02:21
notmorgani am going to bet this is going to be a fairly large improvement02:22
notmorgani'm just going to need to be *very* sure we GC the request correctly02:22
notmorganso we don't memleak02:22
jamielennoxnotmorgan: it will be overriden on each request02:23
notmorganjamielennox: right, but it's about how refs are stacked/held onto02:23
notmorganif we're not careful we might not be able to GC out of the context even as a thread.local02:23
jamielennoxnotmorgan: if at all possible don't store objects on the request02:24
jamielennoxstore basic types02:24
notmorganit'll be dicts mostly02:24
jamielennoxi had another review that got reverted02:24
notmorgansince that is what we use outside of the SQL-A backends02:24
notmorgani just need to be sure i don't do something silly02:25
notmorganwe don't pass SQL-A objects up beyond the drivers unless we have a bug.02:25
jamielennoxnotmorgan: https://review.openstack.org/#/c/264021/ got reverted because heat does silly things02:25
notmorganso it should always be basic types02:25
notmorganwell python-native02:25
jamielennoxnotmorgan: but in general that's how contexts are used in projects and it'd be good if we stick to that02:26
jamielennoxso don't save user = {'domain_id': 'xyz', name: 'abc', ... }02:26
notmorganthe only issue i see is we don't know the flattend values people want02:26
notmorganyeah that isn't going to work for what i need02:26
jamielennoxsave context.user_name = 'abc'02:26
jamielennoxcontext.user_id = 'def'02:26
jamielennoxuser_domain_id = ..02:27
notmorganunless we make the managers always ask for user_name not user['name']02:27
jamielennoxetc02:27
notmorgani can probably write someting to flatten the dict out and do some magic to make it look like a dict02:27
notmorganso get_user() can reconstruct from flattend properties02:28
jamielennoxnotmorgan: is it mostly because of extras?02:28
notmorganno because we say identity_api.get_user('id')02:28
notmorganthen we act on the dict02:28
notmorganand check verisou things02:28
notmorganbut i can do this by making properties like <calculated_cache_key>_<prop_name>02:29
notmorganand then reconstruct it to a dict on .get02:29
notmorganor i can just store the native dict02:29
jamielennoxi don't think that's going to be a problem02:29
notmorganit actually will be pretty straightforward code in either case02:30
notmorganso should i flatten the dicts down to properties?02:31
notmorganor should i just store the dict02:31
jamielennoxnotmorgan: i think it is two seperate problems02:33
jamielennoxcontext is always the current user, what you add to that should be flattened but you should only need basic properties about the current uesr02:33
jamielennoxyou will still have the dict available for token building etc02:33
*** EinstCrazy has joined #openstack-keystone02:33
notmorganjamielennox: i'm trying to offload the calls to the backends02:33
notmorganas well02:33
notmorganso we stop saying .get_user() many times02:33
notmorganor .get_domain() just to see if it's around02:34
notmorganlike .get_project calls .get_domain02:34
notmorganwhy not store the result of .get_domain() so all subsequent calls know it's valid02:34
notmorganwe only need to check once really unless there is an explicit invalidate on the current request02:34
notmorganor a global invalidate on the region (role_assignments, catalog)02:35
notmorganthe only difference is i'm storing the result in the context for the life of the request02:35
jamielennoxi think we shouldn't be checking that in the drivers02:35
notmorganit's not in the driver02:35
notmorganit's in the manager02:35
jamielennoxand in the managers we should be smart enough to know that it's already been checked02:35
jamielennoxbut i know we don't02:35
notmorganthat is wht i'm trying to do02:35
notmorgan;)02:35
notmorganbut rather than needing to always make the manager "smart enough"02:36
notmorganwe cache things. why not leverage the caching layer that already knows how to do this02:36
notmorganit also limits the volume of code change to say "oh uh... we checked this already"02:36
notmorganwe can improve the managers but i don't know where you're going to stash the "this was already checked" and we still have cases where we use the resulting data from the backend multiple times02:37
notmorganin subsequent calls02:37
notmorganhere let me run my errand and spin up a change tonight to try this out02:38
*** EinstCrazy has quit IRC02:40
*** shoutm_ has quit IRC02:41
jamielennoxnotmorgan: yea, i think try it out02:45
notmorganjamielennox: so first pass, flatten the returns out or store the dict? i am thinking flatten so there is no way someone can accidently "modify" the stored data02:46
jamielennoxnotmorgan: i think for arbitrary data (not current user) there shouldn't be much advantage in the context02:47
notmorganjamielennox: i think you'll be surprised.02:48
jamielennoxnotmorgan: i don't mind if you keep dicts, just that i want to do something like that review i showed so assume that context.user and context.project is the string id02:48
jamielennoxyou can do whatever you like beyond that02:48
notmorganoh right, this is stuff that should never ever be touched outside of this code i'm writing02:48
notmorganall 100% internal02:48
jamielennoxi don't like reconstituting dicts from flattened attributes02:48
notmorganmy only concern is if someone does a .get_domain then sets a value on it02:49
*** shoutm has joined #openstack-keystone02:49
notmorganand i want to avoid needing to copy.deepcopy a lot02:49
notmorganthough that might be less expensive than flatten/unflatten02:50
jamielennoxi think the deepcopy will be cheaper02:51
notmorganwell i can start there. it's def simplier code02:52
*** shoutm has quit IRC02:56
ayoungjamielennox, please give https://review.openstack.org/#/c/242614/  your blessing, or at least rage at it again.  There is a long line of Henry's work that is based on it, and I am worried about that stuff geting dropped because no one can review it until late02:58
ayoungthis is maybe imperfect, but should be good enough02:58
ayoungand I would not like to break the revision record on this review if possible02:59
ayounggetting close02:59
*** shoutm has joined #openstack-keystone03:00
*** davechen1 has joined #openstack-keystone03:25
*** davechen has quit IRC03:27
notmorganjamielennox: ... so quick first pass, this looks like it's speeding up tests like 50+03:28
notmorganjamielennox: some failures but things are happening much faster03:28
notmorganjamielennox: visual guessing though03:29
notmorgan50%+ that is03:29
notmorgani think i have an isolation bug though.. need to do an explicit clear of the cache in core test case(s)03:30
*** richm has joined #openstack-keystone03:32
*** davechen1 is now known as davechen03:40
*** markvoelker has joined #openstack-keystone03:43
*** markvoelker has quit IRC03:47
notmorganbah isolation bug was speeding things up03:54
openstackgerritMorgan Fainberg proposed openstack/keystone: WIP/DNM: Use requst local caching  https://review.openstack.org/27188504:00
*** dslev has joined #openstack-keystone04:01
openstackgerritDave Chen proposed openstack/keystone: Consolidate `test_contrib_ec2.py` into `test_credential.py`  https://review.openstack.org/27188604:04
openstackgerritDave Chen proposed openstack/keystone: Consolidate `test_contrib_ec2.py` into `test_credential.py`  https://review.openstack.org/27188604:06
*** shoutm_ has joined #openstack-keystone04:06
*** dslev has quit IRC04:06
*** shoutm has quit IRC04:09
*** shoutm has joined #openstack-keystone04:10
*** shoutm_ has quit IRC04:11
*** richm has quit IRC04:13
openstackgerritMerged openstack/keystoneauth: Use positional library instead of our own copy  https://review.openstack.org/26730004:17
*** shoutm has quit IRC04:28
*** shoutm has joined #openstack-keystone04:30
openstackgerrithenry-nash proposed openstack/keystone: Projects acting as domains  https://review.openstack.org/23128904:32
*** su_zhang has joined #openstack-keystone04:48
davechennotmorgan: what does "check experimental" means?04:49
notmorgandavechen: i'm using one of your patchsets as a baseline test ;)04:49
notmorgandavechen: it runs the check jobs in the experimental queue04:49
davechennotmorgan: where i can see it?04:49
notmorganthis is actually a case where i want to see the rally output . first and only time04:49
notmorganlook at zuul.openstack.org and the 'Experimental' queue04:50
davechengot it.04:50
notmorganyou'll see a couple things running04:50
notmorgani'm profiling a change to try and offload queries to the backends/DB for a given request04:50
notmorgannot sure how much benefit there is04:51
boris-42notmorgan: it's really bad that you guys removed rally job04:51
davechennotmorgan: ha, i saw it, this the first time I know this.04:51
notmorganboris-42: no it isn't04:51
notmorganboris-42: the job has been useless. not changed since it was implemented. fix it and make it useful and we'll add it back04:51
boris-42notmorgan: it is, it was smarter to learn how to use it04:51
boris-42notmorgan: you didn't get our patches04:51
notmorganboris-42: running it in isolation like it is is not very useful04:51
boris-42notmorgan: amaretsky was working on it04:51
notmorgansince every node has different performance profile and we're still not tracking data ovet time04:52
*** chlong has joined #openstack-keystone04:52
boris-42notmorgan: it is, if you used it fully you won't make the stuff with removing cache and blocking whole openstack development for few days04:52
notmorganfor the record, that was mostly an overblown reaction04:52
notmorganmostly04:52
notmorganit was impactful but there are a lot of otherthings going on too04:53
boris-42notmorgan: yep agree04:53
notmorganbut again, i can't know if rally being slow is that node, or more global without looking at every patchset04:53
notmorganit's not really useful04:53
notmorganif the data is cenrtalized, it becomes very useful04:53
boris-42notmorgan: so usually from what i saw for 3 years04:53
notmorgancentralized/searchable/not a pain in the butt to get / correlate changes on04:54
boris-42notmorgan: performance can be different about 2 times*04:54
boris-42notmorgan: put sla with avg * 2 and you'll get failing job when something is going badly wrong04:54
notmorganagain, make it so i can see the difference between runs. i disagree with rally as it stands.04:54
boris-42notmorgan: I understand that you would like to get everything instantly and for free04:54
notmorganfor a unit/check job04:55
boris-42notmorgan: with prediciton & showing where code fails04:55
boris-42notmorgan: but it won't happen immediately04:55
notmorganit's why i didn't remove the thing and made it expiermental, run it on demand. literally not a single person in the meeting had ever used the data04:56
notmorganthat means there was a failure in garnering adoption/making it useful.04:56
notmorganto us in general04:57
*** lhcheng has quit IRC04:57
notmorgani will jump for joy when we have it being useful and it goes back in.04:57
boris-42notmorgan: ok04:57
boris-42notmorgan: maybe I should make a video demo04:57
notmorgani didn't delete it because i didn't want it to be totally gone.04:57
boris-42notmorgan: about rally in gates04:57
notmorganboris-42: you need to make the data easy to get at04:57
*** roxanagh_ has joined #openstack-keystone04:58
notmorganboris-42: if the data is easy to get at / understand that will go a long way too.04:58
notmorgani think i asked a year and a half ago for a central view of over-time w/ rally + searchable.04:58
notmorganwhen we threatend to remove it last04:58
boris-42notmorgan: yep it is quite old task04:59
notmorganbut i did leave it experimental because it allows someone to use it but it's not consuming resources (a real premium atm) on every check run04:59
boris-42notmorgan: ok04:59
boris-42notmorgan: but not sure that somebody will find it now =(05:00
notmorganbtw: rally would not have picked up the issue with the caching05:00
notmorganthat was not a keystone server issue05:00
notmorganthat was a keystone middleware issue, keystonemiddleware never ever ever is run against keystone05:00
boris-42notmorgan: it was middlerware I know05:00
notmorganerm as keystone05:00
boris-42notmorgan: it will catch actually (because we have scenarios that tests caching)05:00
notmorganbut ... it can't catch caching changes on keystonemiddleware for the keystonejob05:01
notmorganthats all05:01
notmorgansince middleware isn't involved05:01
boris-42notmorgan: and now you are running only keystone?05:01
boris-42notmorgan: in dsvm jobs?05:01
boris-42notmorgan: we are testing caching (from different projects e.g. nova/cinder)05:02
notmorganthe job we made experiemental wouldn't have caught this bug05:02
notmorganthat was my point05:02
*** roxanagh_ has quit IRC05:02
boris-42notmorgan: so we have exatcly scenarios that tests glance/cinder/nova token caching =)05:02
boris-42notmorgan: jfyi05:02
notmorgani also wont say it is not useful in nova05:02
notmorganit is not useful in keystone specifically05:02
notmorgani wouldn't advocate making the job experimental elsewhere05:02
notmorgani haven't looked to see how useful it is05:03
* stevemar is pretty sure notmorgan has worked on keystone all weekend05:03
notmorganbut you get a more end-to-end view with other services mixed in05:03
notmorganso since we only ran token creates in our job05:03
notmorganand very limited other things05:03
notmorganit shows me it wasn't a useful job05:03
notmorganstevemar: i have sortof05:03
stevemarnotmorgan: i am close to finalizing the mid cycle schedule05:04
notmorganstevemar: nice05:04
boris-42notmorgan: ok05:04
notmorganboris-42: so mayyyybe having a job that is doing specific per-project things isn't useful maybe we need a baseline "here are all the things we check no matter what" set05:05
davechenstevemar: will this bug is included in the schedule?  (https://bugs.launchpad.net/keystone/+bug/1501740)05:05
openstackLaunchpad bug 1501740 in OpenStack Identity (keystone) "Creating a region without request parameters failed." [Medium,In progress] - Assigned to Dave Chen (wei-d-chen)05:05
notmorganboris-42: and then some project-spefici things05:05
davechenstevemar: different reviwers has different views on this.05:05
boris-42notmorgan: so basically we are able to specify specific things per job05:05
notmorganboris-42: again the problem with the keystone job is it was purely isolated and not showing a heck of a lot. plus a lot of "this isn't super useful to look at as is"05:05
boris-42notmorgan: with SLA05:05
stevemardavechen: it's definitely one of the items i want to discuss, just trying to find a slot for it05:06
notmorganboris-42: ok but i don't want to have to see an update to keystone every single time we need to add things, and nova and glance and cinder05:06
boris-42notmorgan: so except trending which is really hard and requires hardware that I don't have05:06
notmorganboris-42: look at bandit. it has some basic profiles05:06
notmorganboris-42: that we can then override/modify05:06
notmorganthat means when bandit adds a new thing, we get it for free [yeah linter != rally, but you get the idea]05:07
davechenstevemar: cool, if notmorgan's comments got buy in from the mid cycle, we will check the APIs instead.05:07
notmorganboris-42: lets circle up w/ infra, maybe we can do some simple graphite magic or some sort of "make this data something we can correlate" with ELK or the like05:08
notmorganboris-42: i'd see that as super useful05:08
boris-42notmorgan: it's very hard task, we can keep all results in single db and fetch it05:08
boris-42notmorgan: however it's hard to normalize results05:08
notmorganboris-42: we can probably also trend the checks with graphite and run a post job to show outliers05:09
boris-42notmorgan: it want stop merging bad code05:09
boris-42won't*05:09
notmorganboris-42: no it wont. but we can for sure show at a glance when something went wonky or show that a given changeset is horrrrribly out of whack05:09
boris-42notmorgan: okay I will work on this for a bit05:10
notmorganboris-42: i'm happy to help chat with infra to see if we can get some resources for centralizing it in a sane way05:10
boris-42notmorgan: so what we need is to have just isolated resources (but they say that they don't have)05:10
notmorganthis would be like the log server05:11
notmorgana place where we can inject the raw data and show the over-time changes. maybe the over-time changes is a gate-only job, and the check job shows comparison to the over time changes05:11
notmorganboris-42: lets plan to talk more post keystone midcycle and i'm happy to help you plan this out05:12
boris-42notmorgan: i mean we already have DB05:12
boris-42notmorgan: in Rally05:12
boris-42notmorgan: that stores all results05:12
notmorganboris-42: a persistent db?05:12
boris-42notmorgan: yep05:12
notmorganis it available to query?05:12
boris-42notmorgan: it's SQL db05:12
boris-42notmorgan: so what we need is just to have single DB instead of each time new one05:13
notmorganright05:13
boris-42notmorgan: and run post jobs and store results05:13
notmorganyes05:13
notmorgansomething like that05:13
boris-42notmorgan: and I will make simple reporting for that05:13
notmorganheck we do it with some subunit2sql now too05:13
boris-42notmorgan: I mean Rally DB exists since the begging of Rally ;)05:13
notmorganright. but it's per run. not central for everything05:14
notmorganso each run is a clean / new db?05:14
notmorganas in local to the dsvm run05:14
boris-42notmorgan: yep it's current implementation05:14
notmorganok05:14
boris-42notmorgan: of dsvm job for rally05:14
boris-42notmorgan: for post job we will need a bit different job05:14
notmorganso lets work on either making that a central resource we can keep data in or finding a way to push the data to a central resource we can use in a post jb05:15
notmorganjob*05:15
notmorganwhether it's SQL or something else.05:15
notmorganand i think that will make rally significantly more interesting.05:15
notmorgani also still recommend making a set of baseline scenarios we get for free that are just part of rally, like how bandit works05:16
boris-42notmorgan: so it's very hard... because it really depends on project05:16
boris-42notmorgan: we are working on OPS stuff05:16
boris-42notmorgan: https://github.com/openstack/rally/tree/master/certification/openstack05:17
boris-42notmorgan: but not sure that this is suitable for your case05:17
notmorganboris-42: right but you know that genrrally you can do a nova  boot x instances for the generic rally job05:17
notmorganso maybe that should be always there05:17
notmorganwhere the add_remove_user_role job [keystone] is really a keystone specific thing05:17
notmorgansince it wont be impacted by anything nova does05:18
boris-42notmorgan: so we can make large-ops-job-like-task05:18
boris-42notmorgan: and keep it in rally05:18
boris-42notmorgan: but where you would like to use it ?05:18
* notmorgan is trying to give suggestions that makes rally more interesting/useful without asking for each and every change to require a change to keystone and nova and glance etc to enable a scenario05:18
notmorganbut i think the central data is really going to be killer addon for the gate :)05:19
boris-42notmorgan: ok I will manage to work on that05:19
boris-42notmorgan: however need to finish osprofiler first05:20
notmorgansure05:20
*** EinstCrazy has joined #openstack-keystone05:23
*** markvoelker has joined #openstack-keystone05:44
notmorganjamielennox: oh my05:44
notmorganjamielennox: so... deepcopy is REALLY expensive05:44
notmorganjamielennox: insanely so05:44
notmorganjamielennox: http://paste.openstack.org/show/484793/05:46
notmorganjamielennox: let me try spinning my patch with a flatten/reconstruct bit of code05:47
notmorganand i mean that thing i did there was so bloody synthetic i don't know what to say ^05:47
notmorganand that is far far simpler than what i was doing.05:48
*** markvoelker has quit IRC05:48
*** jaosorior has joined #openstack-keystone05:52
*** rcernin has joined #openstack-keystone05:54
*** tyagiprince has joined #openstack-keystone05:55
tyagiprinceHii.  I want to know why is it necessary to run neutron-ovs-cleanup command on nodes before starting the openstack services like dhcp and l3-agent. Please help me.05:56
*** su_zhang has quit IRC05:56
jamielennoxnotmorgan: wow, that's kind of nutes05:57
notmorganjamielennox: right?05:58
notmorganwant to see the comparison on pickle?05:58
notmorganjamielennox: http://paste.openstack.org/show/484794/05:58
jamielennoxtyagiprince: i have no idea, probably best to try the openstack-neutron channel05:58
notmorganjamielennox: it also tells me we may be suffering copy.deepcopy things on the cache-isolating proxy for testing05:59
notmorganmight be adding a significant overhead for our unit tests05:59
jamielennoxi don't know if it's going to cause problems though05:59
*** roxanagh_ has joined #openstack-keystone05:59
*** EinstCrazy has quit IRC05:59
tyagiprincejamielennox: Tried that.. Been asking there since 2-3 days.. no one talks there :P05:59
jamielennoxalso if you have actual objects you can add __copy__ to speed up the guessing05:59
notmorganjamielennox: i'm going to run a similar synthetic test with json serialize now06:00
jamielennoxtyagiprince: well last 2-3 days have been the weekend :) i'm surprised though - anyway networking is all just magic stuff, can't help06:00
tyagiprincejamielennox: the problem I am facing is when I restarted my connet (controller + network) node, the dhcp agent status goes down.06:01
tyagiprinceokay.. Thanks :)06:01
jamielennoxnotmorgan: gotta run out for a bit, will see result later though06:01
*** ajayaa has joined #openstack-keystone06:02
tyagiprincenotmorgan: you might be able to help me out. I see you there in openstack-neutron:P06:03
*** EinstCrazy has joined #openstack-keystone06:03
*** henrynash has quit IRC06:03
*** roxanagh_ has quit IRC06:04
notmorgantyagiprince: i lurk in a lot of channels06:05
notmorgan:P06:06
notmorganand i mean a lot06:06
notmorganmostly for when people need keystone advice06:06
notmorgannot sure what neutron-ovs-cleanup does, but my guess is it removes the networking stuff that isn't needed / cleans up all the linvering definitions so neutron can repopulate them sanely06:06
tyagiprincenotmorgan: Yup, you have helped me alot earlier :)06:06
notmorganjamielennox: 7usec per loop on json deserialize06:07
notmorganjamielennox: so json deserialize is 2x faster than deepcopy is06:07
notmorgan0.o06:07
*** tyagiprince1 has joined #openstack-keystone06:11
*** Nirupama has joined #openstack-keystone06:11
*** tyagiprince has quit IRC06:14
*** tyagiprince1 is now known as tyagiprince06:14
notmorganoh interesting... revoke tree has circular references!06:19
* notmorgan glares.06:19
stevemarnotmorgan: why shouldn't it!06:19
notmorgani'll bet that has something to do with.. $OMGSLOW$06:19
notmorganthings you learn when you try and serialize an object06:19
ajayaaHi. Is this blueprint https://blueprints.launchpad.net/keystone/+spec/pagination-backend-support still  relevant?06:21
ajayaaI am interested in picking it up.06:21
notmorganajayaa: you don't want tpo ask me that question06:21
notmorgancause i have very strong opinions on pagination06:21
notmorganstevemar: can atest to that06:22
ajayaaokay. notmorgan, please pretend the you didn't see the above question. :)06:22
*** jaosorior has quit IRC06:22
ajayaas/the/that06:22
notmorganstevemar: so.. i think we have a problem in revoke events =/, if this is really a circular reference it's non-GC'able06:23
notmorganstevemar: so we're leaking memory in keystone06:23
* notmorgan puts on Oh GOD IT MAKES MY EYES BLEED debugging hat06:23
stevemarnotmorgan: we had some folks looking at revoke events internally, and they def had criticism about it06:24
notmorganstevemar: i have a sweeping change i want to make06:25
stevemarmaybe a tree wasn't the best impl. for it06:25
notmorganstevemar: dump the entire tree thing and just rely on the backend [SQL] to do the heavy lifting06:25
notmorganit does mean a lot more indexes06:25
stevemarnotmorgan: sweeping changes in mitaka-3, no big deal06:25
notmorganbut i mean, we can do a simple SQL query and say "oh something matches"06:25
stevemartrue06:25
notmorganand it'll be destroying the interfaces06:25
notmorganthat were unfortunately "public"06:26
notmorganthere is no way to maintain compat.06:26
notmorganafaict06:26
notmorganbut it's on objects no one should ever ever ever ever ever ever ever ever be touching06:26
notmorganso it should be ok06:26
stevemarnotmorgan: what about just changing the impl. without affecting the manager/driver interfaces?06:27
notmorganthats the issue06:27
notmorganwell we need to change the driver interface06:27
notmorganbecause we have to pass a lot more data down or we need to do driver -> manager calls06:27
notmorganwhich we said was bad (no cross driver calls)06:28
notmorganbut that is mostly versionable06:28
notmorganit's the model that isn't06:28
notmorganbut no one should ever get a model unless then do ._get_revoke_tree06:28
*** chlong has quit IRC06:28
notmorganit's just the revoke tree is "technically" public06:29
notmorganand we will be throwing it out06:29
notmorganand never using it and breaking compat on being able to use it06:29
*** jaosorior has joined #openstack-keystone06:30
* notmorgan tries to figure out how the hell revoke tree has circular references06:30
*** jamielennox is now known as jamielennox|away06:31
stevemarnotmorgan: double check that it actually does, like i said, we had folks internally who took a long look at and found issues, but never circular references06:33
*** jamielennox|away is now known as jamielennox06:33
notmorganoh look at that we can use the gc module to deal with freeing it06:34
notmorganugh06:34
notmorganstevemar: this is based on trying to serialize it. the error is "circular refernce found" so i am thinking it realy is one06:34
notmorganthe fact that it does recursive self modification it doesn't surprise me06:34
notmorganit isn't going to be "easy"to see where the ref happens06:35
*** su_zhang has joined #openstack-keystone06:36
*** henrynash has joined #openstack-keystone06:40
*** ChanServ sets mode: +v henrynash06:40
*** gildub has quit IRC06:41
*** belmoreira has joined #openstack-keystone06:44
*** lhcheng has joined #openstack-keystone06:46
*** ChanServ sets mode: +v lhcheng06:46
*** EinstCrazy has quit IRC06:47
openstackgerritSteve Martinelli proposed openstack/python-keystoneclient: use positional library instead of utils  https://review.openstack.org/27190606:49
stevemarpoke notmorgan and jamielennox https://review.openstack.org/#/c/271906/06:49
notmorganstevemar: -106:50
stevemarnotmorgan: oh noes06:50
*** lhcheng has quit IRC06:50
notmorganstevemar: can't remove the import versions of ksm require it in .utils06:50
jamielennoxstevemar: what he said06:51
notmorganso it'll need to live there for a long time06:51
stevemar:(06:51
notmorganlike... forever06:51
notmorganso maybe we need a # NOTE(): DO NOT REMOVE06:51
jamielennoxit's not a big deal, just put a comment in there and we'll remove it later06:51
openstackgerritMorgan Fainberg proposed openstack/keystone: Removed deprecated revoke KVS backend  https://review.openstack.org/26777706:51
notmorganstevemar: ^ that fixes the test cases06:51
stevemarnotmorgan: oh thanks06:52
stevemarjamielennox: abandon: https://review.openstack.org/#/c/179703/4 ?06:52
jamielennoxstevemar: oh -yep06:52
openstackgerritSteve Martinelli proposed openstack/python-keystoneclient: use positional library instead of utils  https://review.openstack.org/27190606:54
stevemarnotmorgan: added a comment06:54
openstackgerrithenry-nash proposed openstack/keystone: Removes project.domain_id FK  https://review.openstack.org/23327406:56
notmorganhenrynash: oh that's in lifght of using project as a domain?06:56
henrynashnotmorgan: yes, the phase 1 stuff06:57
notmorganhenrynash: we may not want to be rid of the FK though06:58
notmorganit might just need to be FK(project.id)06:58
notmorgannot sure if that is valid in mysql, but i think it's valid SQL06:58
notmorgananother example would be employee.manager is an employee but a FK06:58
notmorgansince you want the relationship06:58
stevemarnotmorgan: whats up with "self.config_fixture.config(group='revoke', driver='sql')", sql is the default now06:59
henrynashnotmorgan: conceptually I agree - however, since domain_id can be None (for projects acting as domains), taht could be tricky06:59
notmorganhenrynash: a check on the SQL-A model bind to ensure project.id != domain.id06:59
notmorganhenrynash: this is something that needs to be added to the SQL-Model itself.06:59
henrynashnotmorgan: and in fact we store a special value instead of None in teh domain_id column, so as to still use uniqueness constaints06:59
notmorganuh07:00
notmorganwait what?07:00
notmorgani don;t like that at all07:00
notmorganstevemar: we can remove them but we have them lingering elsewhere07:00
henrynashwhich part :-)07:00
openstackgerritSteve Martinelli proposed openstack/keystone: Removed deprecated revoke KVS backend  https://review.openstack.org/26777707:00
notmorganhenrynash: a not none for uniqueness constraints?07:01
notmorganwhy does there need to be uniqueness constraints?07:01
henrynashnotmorgan: we still want name+domain_id to be unique07:02
notmorgandomain names are globally unique07:02
notmorganso name+None is unique07:02
notmorganwell name+null07:02
henrynashnotmorgan: and for projects actinsg as domains, the domain_id is None07:02
notmorganso thats fine07:02
henrynashnotmorgan: yep07:02
notmorganso no reason to store a special value07:02
notmorganand the FK can exist, but be NULL07:02
notmorganso column is FK -> project.id and nullable=True07:03
henrynashnotmorgan: although I don;t think sql supoer for a unquness constarints with a null value is that stadnard07:03
henrynashnotmotgan: at least not according to the literature07:03
notmorganwe can also make a special row called "root" that is self-referring07:03
openstackgerritSteve Martinelli proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113507:04
henrynashnotmorgan: you could…but see the patch for what I am proposing: https://review.openstack.org/#/c/264533/07:04
notmorgani'm checking if null is part of a constraing when doing unique() now07:04
*** EinstCrazy has joined #openstack-keystone07:05
notmorganhenrynash: solution07:05
notmorganmight work...07:05
notmorgangive me a sec07:05
notmorganah null is not distinct07:06
openstackgerritSteve Martinelli proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113507:07
notmorganactually.. we can work around that07:08
henrynashnotmorgan: and we have to deal with legacy drivers who might not supprt None as domain_id07:08
notmorganso we do something evil07:09
openstackgerrithenry-nash proposed openstack/keystone: Projects acting as domains  https://review.openstack.org/23128907:09
notmorganwe create a row that is called "root" that has it'self as domain.id07:09
notmorganor __keystone_root__07:09
notmorganand we just strip it out in all cases07:09
notmorganmake it's id like Default, a string vs uuid07:10
notmorganso  we know it's static07:10
notmorgananything that is a domain is parented to __keystone_root__07:10
openstackgerritSteve Martinelli proposed openstack/keystone: Remove eventlet support  https://review.openstack.org/24948607:10
notmorganand we can handle that internally07:10
notmorgani don't like using a non-FK for this because it should be enforced to exist.. alternatively you can use a bind in the SQL-A driver to enforce existence. but that seems like a lot of extra work07:11
notmorganand the driver itself can handle the adding/removing of the __keystone_root__ id07:11
stevemarnotmorgan: since you're on a 'decrease-test-time-kick', henrynash has a patch that'll speed things up here: https://review.openstack.org/#/c/271106/07:12
henrynashnotmorgan: so understand your approach, not yet convinced it’s less evil than mine…but let me think about it!07:12
notmorganhenrynash: i am worried you're going to get inconsistencies in the db because somehow because we're not ensuring a cascade delete07:12
notmorganhenrynash: and orphaned projects are relatively concerning if somehow a domain is deleted with projects still attached to it07:13
notmorganhenrynash: the cases we removed the FKs before we move the things into other backends. so we know we had x-driver actions07:13
notmorganthis time we're doing something a bit odd and referencing something in our own table07:14
notmorganthis one worries me a bit that is all.07:15
notmorganbecause until now it was impossible to orphan a project07:15
henrynashnotmorgan: so we are not changing the Fk for  child project to it’s parent, that’s still presnet -  Iguess youre argument is tha t we shold do the same for domain_id, with the project table07:15
notmorganright07:15
henrynashnotmorgan: ok, understand the concern….let em mull in it07:16
notmorganyeah need to figure out the right way to solve it, since unique() shouldn't have nullable columns07:16
notmorganbut then how do we represent a domain properly07:16
notmorganand avoid the non-unique domain name issue07:16
*** shoutm_ has joined #openstack-keystone07:17
stevemarmaking a call to cancel the keystone meeting on tuesday, any dissenters?07:19
notmorganah07:19
notmorganhenrynash: have a workaround07:19
henrynashstevemar: nix it07:19
henrynashnotmorgan: ok....07:19
stevemar++07:19
*** shoutm has quit IRC07:20
notmorganhenrynash: ignore the :trigger:07:20
notmorganwe don't want that07:20
notmorganhttp://paste.openstack.org/show/484798/07:20
notmorgantaken from https://bugs.mysql.com/bug.php?id=17825 [towards the bottom]07:20
notmorganand we can use SQL-A bind or the driver to enforce that the dummy [or in our case is_domain] is only set for domains07:21
notmorganthis would be mysql-specific. we'd need to see how pgsql and db2 handles it07:21
*** lhcheng has joined #openstack-keystone07:21
*** ChanServ sets mode: +v lhcheng07:21
notmorganbut basically the constraint would be (name, is_domain)07:22
notmorganfor mysql07:22
*** tyagiprince1 has joined #openstack-keystone07:22
notmorganand the domain_id would be FK project.id07:22
henrynashnotmorgan: although that’s not enough…since we want name+domain_id for all other domains to unique as well07:22
notmorganthat is fine.07:22
notmorganyou cna still unqiue(name, domain.id)07:23
notmorgannow in non-mysql dialects it probalbly is sufficient to unique name domain.id07:23
henrynashah, right - so two different uniqueness constaints07:23
notmorganalso maybe domains use themselves as the domain.id07:23
notmorgan?07:24
*** tyagiprince has quit IRC07:24
*** tyagiprince1 is now known as tyagiprince07:24
notmorgani actually think the root row of __keystone_root_domain__ is probably the best answer07:24
notmorganthat way all the enforcement is handled in a sane way07:24
henrynashnotmorgan: …I think that is better than your last suggestion, yes….07:25
stevemarnotmorgan: fixes the revert from the eventlet gate failure: https://review.openstack.org/#/c/271851/107:27
*** tyagiprince has quit IRC07:28
notmorganhenrynash: mysql> insert into test (`id`, `parent`) VALUES(10, 10);07:30
notmorganhenrynash: Query OK, 1 row affected (0.01 sec)07:30
notmorganmysql> insert into test (`id`, `parent`) VALUES(10, 12);07:30
notmorganERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`ks`.`test`, CONSTRAINT `fk_parent` FOREIGN KEY (`parent`) REFERENCES `test` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)07:30
notmorganhenrynash: so self-reference works well.07:30
notmorganhenrynash: my test was create table `test` ( `id` int unsigned not null auto_increment, `parent` int unsigned default null, primary key(`id`), constraint `fk_parent` FOREIGN KEY (`parent`) references `test` (`id`) on delete cascade on update cascade) engine=InnoDB;07:31
henrynashnotmorgan: good…and we use that already for the child->parent project Id07:31
notmorganhenrynash: could make parent Not Null07:31
henrynashnotmorgan: certainly making a “root” row, would be one wayt to do this07:31
notmorganhenrynash: and the backend driver can just strip it out07:32
notmorganand automatically add it back in where needed07:32
notmorganso the business logic code can ignore it07:32
notmorganand we get None as expected07:32
notmorganor the SQL-A model bind does the magic for that07:32
henrynashnotmorgan: (which is how I implemted the special value…it’s all in the driver)07:32
openstackgerritSteve Martinelli proposed openstack/python-keystoneclient: remove CLI from keystoneclient  https://review.openstack.org/25818107:32
henrynashnotmorgan: so same idea, but agree yours would provide more referential integrity07:33
notmorganhenrynash: see line ~143 and such https://review.openstack.org/#/c/269693/4/keystone/common/sql/core.py if you want to see something neat/hacky we can do to make it baked into the model07:33
notmorgani think we can do that too with the sql-a model not just a type07:33
notmorganbut we could also make it project_domain_id type that does the work so the driver isn't even responsible.07:34
notmorganhenrynash: but in the driver is good for me.07:34
henrynashnotmorgan: yep, maybe…although maybe keeping it more standard might give us confidence it will work acorss all sqls07:35
notmorganhenrynash: ok posted a comment on the review07:36
notmorgan-1 as well.07:36
notmorgansorry07:36
henrynashnotmorgan: nothing wround with that :-)07:37
henrynash(wrong with)07:37
notmorganstevemar: +2/+A on henrynash's stop doing duplicate tests07:37
*** shoutm_ has quit IRC07:37
stevemarnotmorgan: yay07:38
notmorgani have to pack bags, do laundry, get hair cut, and send things back to amazon tomorrow07:38
notmorganso tuesday i can hop on a plain stupid early07:38
*** shoutm has joined #openstack-keystone07:39
openstackgerritSteve Martinelli proposed openstack/keystone: Enhance manager list_role_assignments to support group listing  https://review.openstack.org/26565007:40
stevemarhenrynash: rebased ^ for you07:40
notmorganstevemar: i don't know if we want https://review.openstack.org/#/c/215715/ because it dirty touches internal interfaces07:40
henrynashstevemar: thx07:40
notmorganstevemar: but it's the only way i think we're landing role caching this cycle.07:40
notmorgani am trying to figure out how to make that friendly in upstream dogpile07:41
stevemarnotmorgan: hehe your comment is funny: "YES!"07:41
notmorganbut i'm not sure if there is an easy  way.07:41
notmorganbut that patch [except my own -1 for the sake of "damn it bad comment"] is able to pass/go07:42
stevemarnotmorgan: role_assignments are pretty expensive07:42
notmorganand it can fix catalog too07:42
notmorganwhich we need to basically rip out the caching in that requires region.invalidate or we need the same fix07:42
notmorganand backport the fix07:42
notmorganstevemar: https://bugs.launchpad.net/keystone/+bug/153761707:42
openstackLaunchpad bug 1537617 in OpenStack Identity (keystone) "caching of the catalog does not invalidate across processes" [High,Triaged]07:43
stevemarnotmorgan: y, i saw that in the devstack patch07:43
*** EinstCrazy has quit IRC07:43
openstackgerritMorgan Fainberg proposed openstack/keystone: Apply invalidation proxy to the catalog cache region  https://review.openstack.org/27153607:44
*** markvoelker has joined #openstack-keystone07:44
openstackgerrithenry-nash proposed openstack/keystone: WIP: Remove domain table references  https://review.openstack.org/16593607:44
notmorganstevemar: so i personally think region.invalidate means we did something horrrrrribly wrong07:45
notmorganin our design07:45
notmorganbut. it's hard to refactor all of it to solve the issue.07:45
*** topol has quit IRC07:45
notmorgani have an alternative approach, but it's also kindof ... ugly07:46
notmorganwe can also use a version id of somesort we can share across instances [somehow?] and pass that in as an argument or somehow utilize it as part of the cachekey building.07:47
*** roxanagh_ has joined #openstack-keystone07:47
notmorganand an invalidate simply changes that key's value.07:47
*** topol_ has joined #openstack-keystone07:47
notmorganstill will suffer from much of the same issues of "if shared store dies" or whatever.07:47
notmorganbut..07:47
notmorganat the very least it doesn't patch internal interfaces.07:47
openstackgerrithenry-nash proposed openstack/keystone: Bye Bye Domain Table  https://review.openstack.org/16185407:48
*** markvoelker has quit IRC07:49
openstackgerritSteve Martinelli proposed openstack/python-keystoneclient: remove oslo-incubator apiclient  https://review.openstack.org/25712707:49
*** EinstCrazy has joined #openstack-keystone07:50
*** roxanagh_ has quit IRC07:51
*** henrynash has quit IRC07:51
* stevemar yawns07:57
stevemarnotmorgan: lets let ayoung push https://review.openstack.org/#/c/267777/ through, revoke is his baby07:58
notmorganstevemar: nope, gonna +A that the moment it passed07:58
notmorganpasses07:58
notmorganif i'm awake07:58
notmorganhe's already good with it07:59
stevemarnotmorgan: oh, in that case, it's ready07:59
notmorganyeah i was just waiting for jenkins +1 but feel free to +A now07:59
stevemaroh wait, zuul is failing it07:59
notmorganyou BROKE SOMETHING08:00
notmorgan:P08:00
notmorganuhm08:00
stevemar./keystone/tests/unit/test_revoke.py:193:1: E302 expected 2 blank lines, found 108:00
notmorganwhat08:00
notmorganstill has .kvs entries?08:00
stevemari just changed the commit msg :P08:00
stevemarnotmorgan: i think you missed this one: https://github.com/openstack/keystone/blob/c0c1227c30457fcb0c9e4bb104aaa89292aede9e/keystone/tests/unit/test_v3_auth.py#L319308:02
*** shoutm_ has joined #openstack-keystone08:02
notmorgandealing with it now08:02
*** shoutm has quit IRC08:03
openstackgerritMorgan Fainberg proposed openstack/keystone: Removed deprecated revoke KVS backend  https://review.openstack.org/26777708:03
jamielennoxnotmorgan, stevemar:  can you give your thoughts on https://review.openstack.org/#/c/271929/ when you have a minute08:04
notmorganjamielennox: i love it.. no wait i hate it ... no wait... CHANGE PLACES08:05
notmorgan10/16 lets have a tea party08:05
*** EinstCrazy has quit IRC08:05
notmorganoer erm 10/608:06
jamielennoxnotmorgan: maybe i should ask again tomorrow instead ...08:06
notmorganjamielennox: lol08:06
*** EinstCrazy has joined #openstack-keystone08:06
notmorgani'm not opposed to this really08:06
stevemarjamielennox: follow the yellow brick road08:06
notmorganstevemar: Who.... are.... yooooouuuu?08:06
notmorganstevemar: Follow the yellow brick road?08:07
notmorganfollow the yellow brick road!08:07
jamielennoxi'm not sure if architecturely it should be an oslo.policy credentials_dict_from_context method - but either way i would like to get a standard list08:07
stevemarjust a scared tin man08:07
notmorganstevemar: if you only had a heart.08:07
notmorganstevemar: is it bad that i'm catching up to you on -2's for mitaka08:08
notmorganjamielennox: yeah not sure if that is right, but standardizing would be fantastic08:09
stevemarjamielennox: i08:10
stevemarjamielennox: i'll keep it open in my tab08:10
notmorganjamielennox: quick +2/+A before it escapes https://review.openstack.org/#/c/271906/08:11
*** EinstCrazy has quit IRC08:11
stevemarjamielennox: and it's child patch08:12
stevemarcause that's a lot of rebasing :P08:12
openstackgerritSteve Martinelli proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113508:13
stevemarjamielennox: i'll hit up that oslo patch tomorrow, bed time for me08:16
jamielennoxstevemar: yea, whenever you can - thanks08:16
jamielennoxstevemar: night08:16
*** EinstCrazy has joined #openstack-keystone08:30
openstackgerritMerged openstack/keystone: Revert "skip test_get_token_id_error_handling to get gate passing"  https://review.openstack.org/27185108:39
openstackgerritMerged openstack/keystone: Remove duplicate LDAP test class  https://review.openstack.org/27110608:39
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/26947908:41
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/26947908:42
*** fhubik has joined #openstack-keystone08:42
*** fhubik is now known as fhubik_brb08:42
openstackgerritMorgan Fainberg proposed openstack/keystone: WIP/DNM: Use requst local caching  https://review.openstack.org/27188508:42
*** roxanagh_ has joined #openstack-keystone08:48
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate keystone.common.kvs  https://review.openstack.org/27194808:49
*** roxanagh_ has quit IRC08:52
*** fhubik_brb is now known as fhubik08:52
*** pnavarro has joined #openstack-keystone08:56
*** topol_ is now known as topol09:00
*** ChanServ sets mode: +v topol09:00
*** su_zhang has quit IRC09:00
*** fhubik has quit IRC09:06
openstackgerritMerged openstack/python-keystoneclient: Use positional library instead of local code  https://review.openstack.org/26837909:06
openstackgerritMerged openstack/python-keystoneclient: use positional library instead of utils  https://review.openstack.org/27190609:07
*** shoutm has joined #openstack-keystone09:07
openstackgerritMorgan Fainberg proposed openstack/keystone: Removed deprecated revoke KVS backend  https://review.openstack.org/26777709:09
*** shoutm_ has quit IRC09:10
*** tjcocozz has quit IRC09:12
*** bapalm has quit IRC09:12
*** shoutm_ has joined #openstack-keystone09:13
*** shoutm has quit IRC09:13
*** shoutm_ has quit IRC09:18
*** EinstCra_ has joined #openstack-keystone09:19
*** EinstCrazy has quit IRC09:21
openstackgerritMorgan Fainberg proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113509:22
*** mhickey has joined #openstack-keystone09:22
*** jistr has joined #openstack-keystone09:23
odyssey4menotmorgan thank you for your feedback on https://review.openstack.org/271357 :)09:23
notmorganodyssey4me: happy to help09:25
notmorgan:)09:25
*** mattt has joined #openstack-keystone09:25
openstackgerritDave Chen proposed openstack/keystone: test_credential.py work with python34  https://review.openstack.org/27196509:28
odyssey4menotmorgan and we're happy to find bugs :)09:31
openstackgerritDave Chen proposed openstack/keystone: test_credential.py work with python34  https://review.openstack.org/27196509:32
odyssey4meand especially happy to find them within the development cycle, not during the stable cycle09:32
*** markvoelker has joined #openstack-keystone09:45
*** markvoelker has quit IRC09:50
*** davechen has left #openstack-keystone09:54
*** vgridnev has joined #openstack-keystone09:56
arif-aliHi all,10:00
arif-aliwas wondering the reason that keystone-salt-formula project wasn't maintained anymore?10:00
*** roxanagh_ has joined #openstack-keystone10:00
*** roxanagh_ has quit IRC10:05
openstackgerritDina Belova proposed openstack/keystone: Integrate OSprofiler in Keystone  https://review.openstack.org/10336810:06
*** EinstCra_ has quit IRC10:08
*** EinstCrazy has joined #openstack-keystone10:18
*** jaosorior has quit IRC10:22
*** jaosorior has joined #openstack-keystone10:23
*** jaosorior has quit IRC10:29
*** jaosorior has joined #openstack-keystone10:34
*** tyagiprince has joined #openstack-keystone10:36
*** tyagiprince1 has joined #openstack-keystone10:43
*** tyagiprince has quit IRC10:43
*** tyagiprince1 is now known as tyagiprince10:43
*** tyagiprince1 has joined #openstack-keystone10:46
*** tyagiprince has quit IRC10:47
*** tyagiprince1 is now known as tyagiprince10:47
openstackgerritMorgan Fainberg proposed openstack/keystone: WIP/DNM: Use requst local caching  https://review.openstack.org/27188510:49
*** ajayaa has quit IRC10:49
openstackgerritMorgan Fainberg proposed openstack/keystone: WIP/DNM: Use requst local caching [full cache]  https://review.openstack.org/27200710:50
*** tyagiprince1 has joined #openstack-keystone10:50
*** tyagiprince has quit IRC10:52
*** tyagiprince1 has quit IRC10:54
notmorganarif-ali: because no one has stepped up to maintain it. Also we [upstream] afaik haven't had a team maintaining salt formulas10:55
*** shoutm has joined #openstack-keystone10:55
notmorganarif-ali: if someone wants to step up, i'm sure no one will be upset by it.10:56
*** bapalm has joined #openstack-keystone10:57
*** tjcocozz has joined #openstack-keystone10:57
*** tyagiprince has joined #openstack-keystone11:01
*** tyagiprince has quit IRC11:03
*** EinstCrazy has quit IRC11:22
*** EinstCrazy has joined #openstack-keystone11:23
arif-alinotmorgan, thanks, I am about to convert all our configs to use keystone v3 API, and noticed it wasn't there, and did some hackery that allowed me to convert a v2 site v3, but not able to provision a v3 from scratch11:29
arif-aliI will have a look, and see if I can do to help that along, and bring it to life again11:29
*** pnavarro is now known as pnavarro|lunch11:45
*** markvoelker has joined #openstack-keystone11:46
*** roxanagh_ has joined #openstack-keystone11:48
*** markvoelker has quit IRC11:51
*** roxanagh_ has quit IRC11:53
*** dims has joined #openstack-keystone11:57
*** ajayaa has joined #openstack-keystone12:07
openstackgerritMorgan Fainberg proposed openstack/keystone: WIP/DNM: Use requst local caching [full cache]  https://review.openstack.org/27200712:10
*** dims_ has joined #openstack-keystone12:22
*** dims has quit IRC12:23
*** raildo-afk is now known as raildo12:25
*** hogepodge has joined #openstack-keystone12:27
*** gordc has joined #openstack-keystone12:30
*** hogepodge has quit IRC12:32
openstackgerritDave Chen proposed openstack/keystone: test_credential.py work with python34  https://review.openstack.org/27196512:44
*** jdennis has joined #openstack-keystone12:44
*** ericksonsantos has quit IRC12:49
*** lhcheng has quit IRC12:53
*** pauloewerton has joined #openstack-keystone13:05
*** vgridnev has quit IRC13:05
*** vgridnev has joined #openstack-keystone13:08
*** markvoelker has joined #openstack-keystone13:16
*** eandersson has joined #openstack-keystone13:16
eanderssonMorning13:16
eanderssonI am having an odd issue. We have two sites, A and B... and on Site B everything is fine, but on Site A authentication is failing with Key length is > 250.13:17
eanderssonI see these warnings in Keystone13:19
eandersson> Fernet token created with length of 268 characters, which exceeds 255 characters13:20
*** Nirupama has quit IRC13:23
*** jsavak has joined #openstack-keystone13:25
*** dims_ has quit IRC13:28
*** bill_az has joined #openstack-keystone13:31
*** edmondsw has joined #openstack-keystone13:32
*** pnavarro|lunch has quit IRC13:32
*** dims has joined #openstack-keystone13:33
*** pnavarro has joined #openstack-keystone13:34
*** roxanagh_ has joined #openstack-keystone13:36
*** dstanek has quit IRC13:41
*** fesp has joined #openstack-keystone13:42
*** dstanek has joined #openstack-keystone13:42
*** ChanServ sets mode: +v dstanek13:42
*** ninag has joined #openstack-keystone13:42
*** roxanagh_ has quit IRC13:42
*** dslev has joined #openstack-keystone13:52
*** mattt has left #openstack-keystone13:52
*** dslev_ has joined #openstack-keystone13:53
*** dslev has quit IRC13:57
*** fesp has quit IRC13:58
eanderssonIt must be some sort of cache error. I disabled memcached in Nova and it worked.14:13
openstackgerritBrant Knudson proposed openstack/keystone: Parameter to return audit ids only in revocation list  https://review.openstack.org/26015314:14
*** vgridnev has quit IRC14:16
*** richm has joined #openstack-keystone14:16
*** vgridnev has joined #openstack-keystone14:18
*** davechen has joined #openstack-keystone14:19
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Remove Babel from requirements.txt  https://review.openstack.org/27211214:23
*** hogepodge has joined #openstack-keystone14:28
*** mdavidson has joined #openstack-keystone14:29
*** davechen1 has joined #openstack-keystone14:31
lbragstadeandersson are IDs in your deployment uuid4 format? Or are they non-uuid strings (maybe some from LDAP?)14:32
*** hogepodge has quit IRC14:33
*** davechen has quit IRC14:33
*** shoutm has quit IRC14:34
*** hogepodge has joined #openstack-keystone14:34
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Remove Babel from requirements.txt  https://review.openstack.org/27211414:34
eanderssonlbragstad: Yea, the user domain is using LDAP.14:34
lbragstadeandersson gotcha14:34
eanderssonThe odd thing is that if I change the region from A to B it works.14:35
eanderssonBoth are identical setups.14:35
lbragstadeandersson keystone will attempt to convert uuid.uuid4().hex (which is the format of our ID strings) to bytes - because they result in smaller tokens14:35
lbragstadwhen you have ID strings that are external - the result could be larger tokens because keystone isn't able to compress something non-uuid format to uuid.uuid4().bytes14:36
stevemaro/14:37
stevemarmorning14:37
eanderssonSo I did some debugging and the token at this stage is the same format (and length) token_ids, cached = self._token_cache.get(token)14:37
eanderssonin the keystonemiddleware14:37
lbragstadeandersson so your tokens from region B are larger than tokens from region A?14:37
eanderssonAs far as I can see they are both identical.14:47
eanderssonin length14:48
lbragstadeandersson ah - so tokens from one region aren't being validated properly?14:48
eanderssonYep14:48
eanderssonWe are actually testing Kilo to Liberty migration at the moment.14:48
lbragstadeandersson is there anything in the logs except the message about lenght/14:48
eanderssonhttp://paste.openstack.org/show/nvpQykrJU5KIFb4rOfYg/14:50
eanderssonI added a lot of additional logging, but nothing that stands out. Like I mentioned the "token" variable looks almost identical before _validate_token14:51
eanderssonhttps://github.com/openstack/keystonemiddleware/blob/stable/kilo/keystonemiddleware/auth_token/__init__.py#L72814:51
lbragstadeandersson ah - interesting. In keystone we don't actually fail the token creation if the length is greater than 250, we just emit a warning - https://github.com/openstack/keystone/blob/ce549fda8cadba4fa99dc800175a66e763adbb53/keystone/token/providers/fernet/token_formatters.py#L166-L17514:51
eanderssonYea, this is a warning from the memcached library14:51
eanderssonSo maybe the memcached version? but the again why fail on only one side :p14:51
lbragstadeandersson that seems pretty self explanatory14:52
lbragstadeandersson are the memcached versions the same in both regions?14:52
eanderssonYes.14:52
lbragstadand they are configured the exact same?14:52
eanderssonBoth the same memcached library and binaries.14:52
eanderssonYes.14:52
lbragstadhm14:52
lbragstadnotmorgan this is interesting ^14:53
eanderssonI even manually verified the code.14:53
lbragstadeandersson ok, and you did say that the tokens from both regions are the same length14:53
eanderssonRemoving the memcached line in Nova/Neutron fixed it :P14:53
eanderssonHoldon, I'll add a len() to verify.14:54
*** ngupta has joined #openstack-keystone14:54
eanderssonYep, both are 268 characters.14:56
*** pushkaru has joined #openstack-keystone14:57
lbragstadeandersson that's strange - both regions A and B issue tokens of the same length, but region A works fine with memcached and region B doesn't. And, removing memcached from the equation in region B fixes the problem.14:58
*** davechen1 has left #openstack-keystone15:03
lbragstadthat feels like a memcached issue?15:05
lbragstadwhere something is different between region A and region B15:05
bknudsonwe always used to hash the pki token when we put it in memcache.15:05
*** rbak has joined #openstack-keystone15:07
*** vivekd has joined #openstack-keystone15:11
*** erhudy has joined #openstack-keystone15:12
*** GB21 has joined #openstack-keystone15:13
*** rderose has joined #openstack-keystone15:13
*** vgridnev has quit IRC15:18
*** vgridnev has joined #openstack-keystone15:19
*** sigmavirus24_awa is now known as sigmavirus2415:20
eanderssonlbragstad, after debugging line by line I found the issue15:22
eanderssonNo clue how this happened15:22
eanderssonbut one side is running a slightly different version15:22
eanderssonaccording to rpm they are both running the same version15:23
bknudsonif fernet tokens can get larger than 250 chars we should hash those too15:23
lbragstadeandersson one region is running a slightly different version of memcached?15:23
eanderssonnope, it was missing this commit https://github.com/openstack/keystonemiddleware/commit/518e9c3a7f34f7f4b86d82da0f9f3a292335875315:23
eanderssonboth servers are showing python-keystonemiddleware-1.5.1-1.el7.noarch15:24
lbragstadbknudson looks like that is what https://github.com/openstack/keystonemiddleware/commit/518e9c3a7f34f7f4b86d82da0f9f3a2923358753 did15:24
eanderssonmust have been a bad upgrade/downgrae or something15:24
lbragstadeandersson so - if you fix the version of keystonemiddleware, both regions work fine, right?15:25
eanderssonyep15:25
lbragstadeandersson awesome15:26
*** timcline has joined #openstack-keystone15:26
*** chlong has joined #openstack-keystone15:27
*** phalmos has joined #openstack-keystone15:29
openstackgerritSteve Martinelli proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113515:34
openstackgerritSteve Martinelli proposed openstack/keystone: remove KVS backend for keystone.contrib.revoke  https://review.openstack.org/27213415:38
eanderssonlbragstad, so it looks like RDO does not have that patch for kilo yet.15:38
lbragstadeandersson ah15:39
*** aix_ has quit IRC15:39
lbragstadeandersson are you using RDO for one region and something else for the other?15:39
eanderssonI think someone might have used pip to upgrade it manually15:39
eanderssonwhich is why it didnt show up when checking rpm15:39
*** chlong has quit IRC15:40
*** chlong has joined #openstack-keystone15:40
*** chlong has quit IRC15:43
*** simondodsley has joined #openstack-keystone15:43
*** chlong has joined #openstack-keystone15:44
*** dslev_ has quit IRC15:45
*** timcline has quit IRC15:46
*** slberger has joined #openstack-keystone15:47
*** timcline has joined #openstack-keystone15:48
*** doug-fish has joined #openstack-keystone15:50
notmorganso what is going on with the validationy things?15:52
lbragstadnotmorgan eandersson was missing the backported patch you had to keystonemiddleware that hashed tokens, ensuring a 250 character length15:53
eanderssonRDO currently comes with keystonemiddleware 1.5.1 which is missing https://github.com/openstack/keystonemiddleware/commit/518e9c3a7f34f7f4b86d82da0f9f3a292335875315:53
notmorganlbragstad: ah15:53
notmorganyep15:53
notmorganthat would do it15:53
notmorganwas going to say there was a hashing backport15:53
notmorgan;)15:53
eanderssonA rogue pip upgrade caused a great deal of frustration :p15:53
notmorganlbragstad: https://review.openstack.org/#/c/272007/ ;)15:54
jorge_munoz@ayoung @stevemar When ever you guys have a chance, could you look at patch https://review.openstack.org/#/c/269824/. lbragstad told me your input would be good for these changes.15:54
lbragstadnotmorgan ah nice! i'll check that out today15:55
stevemarjorge_munoz: sure thing boss15:55
notmorganlbragstad: on rax vms unit tests were down to 200s runtime + setup15:55
notmorganlbragstad: local laptop ~20s saving15:56
notmorganlbragstad: some dsvms were as many at 10m savings15:56
notmorganlbragstad: if we like it (cc dolphm ^) i can un wip it and then there is a minor change needed to keystone common.config to make it a standard thing15:56
jorge_munozstevemar: thanks15:56
eanderssonbesides this issue, are there any known concerns with running Keystone/Liberty with everything else still running Kilo?15:57
*** henrynash has joined #openstack-keystone15:57
*** ChanServ sets mode: +v henrynash15:57
notmorganeandersson: not really afaik15:57
eanderssonawesome, been running great so far15:57
notmorgantypicaly keystone can be ahead of the rest of the services easily15:57
eanderssonwill make the upgrade to liberty a lot easier15:58
*** markvoelker_ has joined #openstack-keystone16:01
*** markvoelker has quit IRC16:02
openstackgerritLance Bragstad proposed openstack/keystone: Add checks for domain scoped data creep  https://review.openstack.org/25367116:02
notmorganstevemar: https://review.openstack.org/#/c/271948/ found another deprecation16:04
notmorganstevemar: needs minor massaging to pass16:05
*** markvoelker has joined #openstack-keystone16:05
*** markvoelker_ has quit IRC16:07
*** vgridnev has quit IRC16:12
*** chlong has quit IRC16:15
*** belmoreira has quit IRC16:15
*** vivekd_ has joined #openstack-keystone16:15
*** chlong has joined #openstack-keystone16:15
*** vivekd has quit IRC16:17
*** vivekd_ is now known as vivekd16:17
*** vgridnev has joined #openstack-keystone16:20
*** woodster_ has joined #openstack-keystone16:23
*** tonytan4ever has joined #openstack-keystone16:23
*** jorge_munoz_ has joined #openstack-keystone16:28
*** jorge_munoz has quit IRC16:28
*** jorge_munoz_ is now known as jorge_munoz16:28
*** pgbridge has joined #openstack-keystone16:29
*** vgridnev has quit IRC16:30
ayoungjorge_munoz, https://review.openstack.org/#/c/269824/9/keystone/token/providers/common.py  looks wrong16:31
*** su_zhang has joined #openstack-keystone16:31
ayoungwhy are we looking at the roles for the user if it is a trust?16:31
ayoungif r in trust_role_ids and r not in roles_id:16:31
*** rcernin has quit IRC16:31
*** jsavak has quit IRC16:31
ayoungwhy is the  and r not in roles_id in there?16:31
*** jsavak has joined #openstack-keystone16:32
bretonayoung: stevemar: https://review.openstack.org/#/c/258741/3 an easy one for you to re-approve16:33
*** spandhe has joined #openstack-keystone16:36
stevemarbreton: thanks for the heads up16:37
*** jsavak has quit IRC16:37
*** jsavak has joined #openstack-keystone16:39
*** spzala has joined #openstack-keystone16:41
*** freerunner has quit IRC16:44
jorge_munoz@ayoung A check to avoid adding duplicate roles16:44
*** freerunner has joined #openstack-keystone16:45
ayoungjorge_munoz, put them in a set.  DOn't compare them to the roles requested off the user.16:45
*** tsymanczyk has joined #openstack-keystone16:45
*** tsymanczyk is now known as Guest6705816:46
jorge_munoz@ayoung Ok, I’ll make the change.16:46
ayoungjorge_munoz, no.  I want to understand the rationale16:46
ayoungI might be wrong here16:46
*** peter-hamilton has joined #openstack-keystone16:46
ayoungwhy'd you do it that way?16:46
ayoungand if the tests pass there, it might be due to pure chance.  but they do pass16:47
*** mhickey has quit IRC16:48
jorge_munoz@ayoung I added it because a user could use a scope token with trust and wanted to avoid adding existing roles, but I might be wrong. When a user authenticates with trust keystone, is the new trust token rescoped?16:50
*** gyee has quit IRC16:52
*** gyee has joined #openstack-keystone16:56
*** ChanServ sets mode: +v gyee16:56
*** r-daneel has joined #openstack-keystone17:00
*** Madkiss has quit IRC17:00
*** su_zhang has quit IRC17:00
openstackgerritSteve Martinelli proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113517:01
openstackgerritMerged openstack/keystone: Removed deprecated revoke KVS backend  https://review.openstack.org/26777717:01
*** chlong has quit IRC17:02
*** chlong has joined #openstack-keystone17:03
*** chlong has quit IRC17:04
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/26947917:04
*** chlong has joined #openstack-keystone17:05
jorge_munoz@ayoung Just tested it, you are right there is no reason why to check the roles that could have come from a token_domain or token_project. The trusted scope token should only have the roles from the trust.17:06
*** amakarov has quit IRC17:08
ayoungjorge_munoz, team meeting right now...back after it is done17:10
notmorganstevemar: ugh... that moment you realize you stayed up till 3am cause insomnia... and code17:13
*** GB21 has quit IRC17:17
stevemarnotmorgan: i know that feel very well17:22
notmorganstevemar: but fun code out the other end17:22
*** su_zhang has joined #openstack-keystone17:22
stevemarnotmorgan: more clean up for kvs and revoke17:22
stevemardamn kvs crap17:22
notmorganno this17:22
notmorganhttps://review.openstack.org/#/c/272007/17:22
*** _cjones_ has joined #openstack-keystone17:23
notmorganand i could speed it up a bit more if i moved to json.17:23
notmorganvs. msgpack.17:23
notmorganbut msgpack was much much easier.17:24
*** lhcheng has joined #openstack-keystone17:24
*** ChanServ sets mode: +v lhcheng17:24
*** ajayaa has quit IRC17:24
*** su_zhang has quit IRC17:26
*** Ephur has joined #openstack-keystone17:27
*** spzala has quit IRC17:29
*** spzala has joined #openstack-keystone17:30
*** jsavak has quit IRC17:30
*** spzala_ has joined #openstack-keystone17:30
*** Ephur has quit IRC17:32
*** spzala has quit IRC17:34
eanderssonGood old Domain-tokens17:34
*** spzala_ has quit IRC17:35
*** vgridnev has joined #openstack-keystone17:35
openstackgerrithenry-nash proposed openstack/keystone: Enhance manager list_role_assignments to support group listing  https://review.openstack.org/26565017:35
eanderssonAs a domain admin I am currently getting the following when trying to modify users under my domain/project "You are not authorized to perform the requested action: identity:list_role_assignments"17:35
*** jsavak has joined #openstack-keystone17:35
eanderssonI modified the policy for list_role_assignments to take rule:admin_or_cloud_admin, but I assume that isn't best practices17:36
eanderssonis this an issue with the latest Horizon patch, or just some incompatibility with the default v3domain policy?17:38
*** jsavak has quit IRC17:39
*** jsavak has joined #openstack-keystone17:40
*** timcline has quit IRC17:42
*** jsavak has quit IRC17:45
*** jsavak has joined #openstack-keystone17:45
*** EinstCrazy has quit IRC17:46
*** agireud has quit IRC17:46
*** vgridnev has quit IRC17:47
*** vgridnev has joined #openstack-keystone17:47
*** agireud has joined #openstack-keystone17:48
*** Guest67058 has quit IRC17:49
*** ajayaa has joined #openstack-keystone17:50
*** jistr has quit IRC17:51
openstackgerritMerged openstack/python-keystoneclient: Replace TestResponse with requests_mock  https://review.openstack.org/25874117:52
*** vivekd has quit IRC17:56
*** tsymanczyk has joined #openstack-keystone18:00
*** tsymanczyk is now known as Guest8877218:00
*** henrynash has quit IRC18:01
*** timcline has joined #openstack-keystone18:01
*** browne has joined #openstack-keystone18:06
eanderssonSo looks like this issue https://review.openstack.org/#/c/180846/18:12
eanderssonAnyone aware of an alternative fix?18:13
*** vgridnev has quit IRC18:14
openstackgerritLance Bragstad proposed openstack/keystone: Add checks for project scoped data creep to tests  https://review.openstack.org/25367018:22
*** jaosorior has quit IRC18:23
*** su_zhang has joined #openstack-keystone18:23
openstackgerritLance Bragstad proposed openstack/keystone: Reuse project scoped token check for trusts  https://review.openstack.org/25367218:24
*** jaosorior has joined #openstack-keystone18:24
*** rderose has quit IRC18:25
stevemarnotmorgan: does nothing use the revoke model now?18:27
stevemaroh nvm, it's fine cause you kept the reference18:27
lbragstadjorge_munoz respun those ^ patches to have negative tests18:28
lbragstadfor the data creep18:28
*** chlong has quit IRC18:29
*** chlong has joined #openstack-keystone18:30
*** doug-fish has quit IRC18:30
openstackgerritMerged openstack/python-keystoneclient: Remove argparse from requirements  https://review.openstack.org/27038618:30
openstackgerritMerged openstack/keystonemiddleware: Remove Babel from requirements.txt  https://review.openstack.org/27211418:31
*** chlong has quit IRC18:32
*** chlong has joined #openstack-keystone18:32
*** daemontool has joined #openstack-keystone18:33
stevemarlbragstad: long live stevermar18:33
stevemarlbragstad: dolphm heads up, mgagne has fernet questions18:34
*** lhcheng_ has joined #openstack-keystone18:34
dolphmmgagne: o/18:34
stevemarsaw him on -operators18:34
lbragstadwhat's up?18:36
mgagnelbragstad dolphm: I'm currently profiling fernet token validation with artificial latency at the database. We expect at least 100ms but I'm testing with 1s to exaggerate the effect. I found that token validation now takes forever (+1m) so I suspect a lot of SQL queries are executed in the process.18:36
mgagnewhat I found with ngrep: https://gist.github.com/mgagne/a80ee892ed099d0bc4ef18:36
*** lhcheng has quit IRC18:36
lbragstadmgagne those are all the calls made on a single validate token call?18:37
mgagneeach single query takes at least 1s, there are ~75 of them, and ~30 for the connection pool: ping and rollback18:37
mgagnelbragstad a fresh never validated token18:37
lbragstadsql calls made on a single validate token call*18:37
mgagnelbragstad with all caching patches applied, it takes 0.04s with no query once token is validated once18:37
lbragstadoh - token create18:37
mgagneno create18:38
mgagnetoken validation18:38
mgagnecurl http://identity:35357/v3/auth/tokens?nocatalog -H "X-Subject-Token: XXX" -H "X-Auth-Token: XXX"18:38
lbragstadoh - a token that hasn't had anything cached yet18:38
mgagneyes18:38
lbragstadwow18:38
mgagnetoken is created on a different keystone node. I'm testing against a 2nd node which is freshly started18:39
mgagneso what I found about those SELECT 1: https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/engines.py#L53-L8218:39
mgagnethe behavior is hardcoded in oslo_db based on pessimistic recommendations from sqlalchemy http://docs.sqlalchemy.org/en/latest/core/pooling.html#disconnect-handling-pessimistic18:39
*** jsavak has quit IRC18:40
*** jsavak has joined #openstack-keystone18:40
mgagnerollback are issued due to connection pool engine rollbacking anything that *could* still be in progress although the application is done with the connection and is returning it to the connection pool18:41
dolphmmgagne: there's obviously some redundant queries in there, but have you compared against uuid?18:41
mgagnelbragstad with mentioned queries, validation takes ~1m18s18:41
mgagnedolphm I didn't, I'm not interested in using UUID due to token persistence18:42
dolphm(solution to redundant queries is to actually use our "auth context", which is not fully populated nor consistently utilized)18:42
mgagnedolphm we don't want to store them anymore18:42
dolphmmgagne: so what are you comparing this 1m8s benchmark against?18:42
mgagnedolphm there is no way for keystone to get those info from the context as there is none afaik18:42
mgagnedolphm nothing for now. We are currently using PKI and are planning to move away from it18:43
mgagnedolphm in fact18:43
dolphmmgagne: have you benchmarked against PKI?18:43
mgagnedolphm yes, we did compare PKI with fernet18:43
mgagnedolphm let me dig the numbers18:43
*** spzala has joined #openstack-keystone18:45
mgagnea coworker did the tests but we can't find those numbers :-/18:45
*** jasonsb has quit IRC18:45
mgagnewe only tested with nova list and fernet. One is with a local database, no latency. The other with latency.18:45
mgagneNova list: 2 sec vs 7 sec. Neutron net-list: 1.5 sec vs 6 sec. Keystone token-get: 0.6 sec vs 3 sec18:46
*** EinstCrazy has joined #openstack-keystone18:46
mgagneif we could have a way to only issue 1-2 queries, that would be great as I know we won't be able to not issue any queries at all18:50
stevemarlooks like we have a test failure in the gate, use of self.skip instead of self.skipTest18:50
lbragstadstevemar yeah - i just hit that locally I think?18:51
*** pcaruana has joined #openstack-keystone18:51
stevemarlbragstad: i got a patch up, 1 sec18:51
*** EinstCrazy has quit IRC18:52
openstackgerritSteve Martinelli proposed openstack/keystone: use self.skipTest instead of self.skip  https://review.openstack.org/27222318:52
stevemarlbragstad: ^18:52
lbragstadstevemar awesome - thanks18:53
lbragstadstevemar i thought i hosed my environment18:54
stevemarlbragstad: looks like it just started18:54
mgagnebut then you could have non-SQL backends for some resources so you can't really easily fetch all of them without checking which ones are SQL or not :-/18:54
lbragstadstevemar was that caused by a bump of something?18:54
lbragstadmgagne how are you introducing the latency again?18:56
mgagnetc18:56
mgagnelet me SSH into the node to get the command, forgot to remove latency so now SSH takes forever :-/18:56
mgagnetc qdisc change dev eth0 root netem delay 1000ms18:57
*** jaosorior has quit IRC18:57
lbragstadyou're adding a second worth of latency?18:57
mgagneyes, as mentioned above18:57
dolphmlbragstad: per query18:58
lbragstadhm ok18:58
dolphmi assume that includes SELECT 1; etc18:58
mgagneany packets I would say18:58
dolphmmgagne: is anything about your results surprising?18:58
mgagneso yea, side effects is 1s per query18:58
stevemarlbragstad: probably this: https://pypi.python.org/pypi/testtools18:58
mgagnedolphm the number of queries is surprising18:58
stevemarlbragstad: 1.9.0 released on 2016-01-2518:58
mgagnedolphm as close to half could be removed18:58
lbragstadstevemar oh - that would make sense18:58
dolphmmgagne: are you interested in helping to refactor our backends and usage thereof to work towards eliminating redundant queries?18:59
* dolphm runs to meeting18:59
lbragstadmgagne actually - dstanek has a pretty cool idea of how to do that18:59
mgagnedolphm I already identified the source of those queries. Some are hardcoded in oslo_db based on sqlalchemy recommendations and some are builtin to sqlalchemy.19:00
mgagnelow hanging fruit IMO are located close to sqlalchemy, not keystone itself19:00
mgagnebut keystone could greatly benefit from better settings/optimisations19:01
*** openstackgerrit has quit IRC19:02
*** openstackgerrit has joined #openstack-keystone19:02
openstackgerritJorge Munoz proposed openstack/keystone: Fix trust redelegation and associated test  https://review.openstack.org/26982419:04
*** pnavarro has quit IRC19:05
dstanekmgagne: i don't think we can get rid of the "ping" queries19:06
dstanekmgagne: i was working on some code that would reduce some of the redundant application queries though19:07
bknudsonwe could mock the db to always return success for the ping queries19:07
mgagnedstanek this means all keystone operations will take at least twice the time to complete.19:07
mgagnebknudson I think this could be a setting19:07
mgagneto oslo_db19:07
*** doug-fish has joined #openstack-keystone19:07
dstanekmgagne: aren't those queries necessary for the way pooling works?19:07
mgagnepessimist_connection_ping=True/False19:07
dstanekmgagne: probably a good thing to talk to zzzeek about19:08
mgagnedstanek read sqlalchemy, it's a pessimist recommendation. I believe there could be a better way to do it19:08
mgagnehttp://docs.sqlalchemy.org/en/latest/core/pooling.html#disconnect-handling-pessimistic19:08
mgagnethere is the optimistic way: issue the request anyway and hope for the best.19:09
*** jsavak has quit IRC19:10
*** doug-fis_ has joined #openstack-keystone19:11
mgagnebut I don't know how to implement it. I suspect it's done this way due to the complexity introduced by transactional queries19:11
*** jsavak has joined #openstack-keystone19:12
mgagnebut what I'm seeing is multiple readonly single-statement transactions19:12
*** doug-fish has quit IRC19:12
*** doug-fi__ has joined #openstack-keystone19:12
stevemardolphm: dstanek can one of y'all punt this through: https://review.openstack.org/#/c/272223/ it's busting le gate19:12
mgagneso I'm not sure all the overhead introduced to make sure the transaction is well rollbacked and all is necessary19:12
stevemari just looked at zuul, and it's passing py27 now19:12
dstanekstevemar: done19:13
stevemarty19:14
*** doug-fis_ has quit IRC19:15
*** doug-fish has joined #openstack-keystone19:16
*** doug-fi__ has quit IRC19:16
*** doug-fish has quit IRC19:17
*** doug-fish has joined #openstack-keystone19:17
openstackgerritJorge Munoz proposed openstack/keystone: Fix trust redelegation and associated test  https://review.openstack.org/26982419:18
notmorganlbragstad: ping.19:24
notmorganCan't reply in gerrit cause new gerrit is broken on phones :(19:24
*** dims has quit IRC19:28
notmorganmgagne: if we add in the role caching and I just proposed a fix that should effectively eliminate redundant queries per request via a thread.local cache.19:29
notmorganmgagne: you should see performance benefits.19:30
notmorganmgagne: we can also def use improvements on our drivers19:30
*** pcaruana has quit IRC19:32
*** pcaruana has joined #openstack-keystone19:36
*** ajayaa has quit IRC19:37
*** pcaruana has quit IRC19:40
*** mhickey has joined #openstack-keystone19:42
*** pcaruana has joined #openstack-keystone19:43
*** rcernin has joined #openstack-keystone19:44
*** EinstCrazy has joined #openstack-keystone19:49
stevemardoh, rechecked a patch but the fix isn't in yet19:50
*** dslevin1 has joined #openstack-keystone19:53
*** EinstCrazy has quit IRC19:54
notmorganlbragstad: responded to your comments now that i am home19:54
*** slberger1 has joined #openstack-keystone19:55
*** maxabidi has joined #openstack-keystone19:55
*** pcaruana has quit IRC19:56
*** slberger has quit IRC19:56
notmorganlbragstad: https://review.openstack.org/#/c/215715/ does the cross-worker cache invalidations20:01
notmorganlbragstad: fwiw20:01
*** jsavak has quit IRC20:02
*** jsavak has joined #openstack-keystone20:03
openstackgerritSteve Martinelli proposed openstack/python-keystoneclient: remove CLI from keystoneclient  https://review.openstack.org/25818120:22
*** doug-fish has quit IRC20:22
lbragstadnotmorgan awesome - thanks!20:28
notmorganlbragstad: the cross-process invalidates is ugly cause it patches internal interfaces20:29
notmorganlbragstad: on dogpile20:30
*** su_zhang has quit IRC20:30
*** su_zhang has joined #openstack-keystone20:31
*** su_zhang has quit IRC20:31
*** doug-fish has joined #openstack-keystone20:32
*** jsavak has quit IRC20:32
notmorganlbragstad: i expect to cover "do we want cross process invalidates" while i work on upstream fixes to dogpile20:33
notmorganat the midcycle20:34
*** pnavarro has joined #openstack-keystone20:36
openstackgerritSteve Martinelli proposed openstack/keystone: Remove eventlet support  https://review.openstack.org/24948620:36
lbragstadnotmorgan that sounds good to me20:36
notmorganand i'll seriously talk w/ zzzeek about co-maintaining dogpile after the midcycle20:37
notmorganso we have a few more active eyes on it20:38
*** timcline has quit IRC20:38
*** maxabidi has quit IRC20:45
*** timcline has joined #openstack-keystone20:45
*** pauloewerton has quit IRC20:49
*** jsavak has joined #openstack-keystone20:51
*** henrynash has joined #openstack-keystone20:52
*** ChanServ sets mode: +v henrynash20:52
*** jsavak has quit IRC20:54
*** jsavak has joined #openstack-keystone20:54
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Remove Babel from requirements.txt  https://review.openstack.org/27211220:55
openstackgerritMerged openstack/keystone: use self.skipTest instead of self.skip  https://review.openstack.org/27222321:00
*** raildo is now known as raildo-afk21:00
henrynashnotmorgan: hi21:01
notmorganhenrynash: heyya21:01
bknudsonwhat caused self.skip to stop working?21:01
notmorganbknudson: uhm. no idea, but .skipTest iirc is more correct21:01
*** su_zhang has joined #openstack-keystone21:02
notmorganmaybe .skip was deprecated21:02
henrynashnotorgan: on the FK issue…..we can certainly do as we discussed…although I realized that we will already have an FK integretity link for every project, since every project (except root domains) now has a parent link to it’s ancestor21:02
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/26947921:03
notmorganhenrynash: still have the issue of the unique() constraint where nulls [in mysql] are not considered unique21:03
notmorganwhich is debatable as to if it conforms to the ANSI standard21:03
bknudsonnew testtools?21:04
notmorganbknudson: perhaps?21:04
henrynashnotmorgan: agreed…we need a “special valus”  of some type (hidden within the driver layer), the only question is whetehr we make that speack value be21:04
henrynashoops21:04
notmorganright21:04
henrynashnotmorgan: ..be used as an FK link to a “root”, or is just a avlue21:04
notmorgani'd go with a FK since we can ensure you don't end up with non-special values21:05
notmorganand randomly orphaned/inweirdstate projects21:05
notmorganit just ensures [esp. if its a NOT NULL] it is always populated and sane.21:06
notmorganand i like enforcement on the schema where we can21:06
henrynashnotmorgan: that last point is true, it stops you have mutliple special values….I don;t think we get any extra integrity protection, since as I said, every non-domain project already has an FK to its parent21:07
notmorganexcept we rely on domain_id for other things21:07
notmorganif that was bogus it could result in strange behaviors21:07
notmorganand out-of-tree drivers i'm not going to argue too much about.21:07
*** chlong has quit IRC21:07
notmorgansince it's on them to write enforcement but we should do our best to avoid those weird cases21:08
*** su_zhang has quit IRC21:08
*** chlong has joined #openstack-keystone21:08
henrynashnotmorgan: indeed…ok, I think we have a plan…one slight issue is that we can’t add the FK we are suggesting until we add all the domains in as projects acting as domains, so I still may need to split up the “special value” part and the FK part, otherwise we end up with a v large patch21:09
notmorganhenrynash: unless we would rather chase up the tree to determine domain_id if domain_id is bogus. it seems like a FK is just easier21:09
*** EinstCrazy has joined #openstack-keystone21:09
henrynashnotmorgan: wherever possible, let’s let the more hardened SQL products do our work for us21:09
notmorgani'm ok with a migration being included in the patch that adds the new functionality21:10
notmorgandefer the move domains -> projects if at all possible until then?21:10
notmorganrest of the scaffolding can be added before the final move21:10
notmorganor make it a bigger patch?21:10
notmorgani mean at some point we will have big-ish patches for feature swings like this21:10
notmorganbut we can work hard to minimize them21:11
henrynashnotmorgan: yep. that has been the plan21:11
stevemarbknudson: yes, new testtools21:13
stevemarbknudson: released today21:13
bknudsonI guess they don't follow semver21:13
*** shaleh has joined #openstack-keystone21:13
stevemarbknudson: they follow keystonemiddleware method of releasing21:13
*** EinstCrazy has quit IRC21:14
bknudsonI assume stable is broken?21:14
bknudsonoh, this is our own problem.21:15
notmorganstevemar: break things and pray no one notices, screw version numbers?21:16
notmorganstevemar: gee, sounds like openstack21:17
bknudsonit's because we have the guard for calling deprecated function and that function is now deprecated.21:17
*** jsavak has quit IRC21:18
*** jsavak has joined #openstack-keystone21:19
bknudsonworking-as-designed21:20
notmorganoi21:20
notmorganc21:20
*** spzala has quit IRC21:21
*** lhcheng has joined #openstack-keystone21:21
*** ChanServ sets mode: +v lhcheng21:21
*** lhcheng_ has quit IRC21:24
*** dims has joined #openstack-keystone21:27
*** shaleh has quit IRC21:29
bknudsony, stable is broken too. I don't think we need the deprecated function call check in stable, but it's easy to just backport the change21:29
bknudsonboth liberty and kilo :(21:33
*** iurygregory has quit IRC21:33
*** iurygregory has joined #openstack-keystone21:34
notmorganfun21:37
mgagnenotmorgan reading your change now. I'm not sure what it changes, how I can test it or how it improves the scenario I mentioned earlier.21:38
openstackgerritLance Bragstad proposed openstack/keystone-specs: Add spec for multifactor authentication  https://review.openstack.org/27228721:38
*** chlong has quit IRC21:39
notmorganmgagne: so my change stores every query we can potentially cache after the first time21:39
mgagnenotmorgan I just tested again my scenario but I also tried to validate a 2nd new token for the same project/user and I know for sure service_provider and trusts aren't cached.21:39
notmorganmgagne: so in a given request we will ony look up for example domain_id once21:39
notmorgannow, you do need to enable caching to make it happen21:39
mgagneI didn't hit this use case21:39
*** chlong has joined #openstack-keystone21:39
mgagneI have cache enabled already21:40
notmorganok so this just means we don't duplicate any queries that are cached to the backend21:40
notmorganeven to memcache21:40
notmorganthere are systems we have not enabled caching on within keystone21:40
notmorganso it wont help there21:40
mgagneaccording to ngrep, cachable information are already cached whenever possible, except for trust and service_provider21:41
notmorgansomewhat21:41
mgagneand I'm not sure why ALL trusts are loaded, why is there not a more specific WHERE clause21:41
notmorganwhat this does it also isolates the data to in-process rather than needing to hit memcache, making the number of calls to memcache go down21:41
notmorganbecause of limited design on the trust backend21:42
mgagneI don't have any problem with memcached, memcached is local to our region and works very well21:42
openstackgerrithenry-nash proposed openstack/keystone: Projects acting as domains  https://review.openstack.org/23128921:42
mgagneand what a limit that is :O21:42
notmorganall fixable21:42
notmorganbut adding caching is difficult because there are very few people who understand caching and the caching libs21:43
*** Guest88772 has quit IRC21:43
mgagneis there any design limitations?21:43
notmorganmaybe i'd need to go look21:43
notmorganthe APIs may assume some broad things we pass down to the driver21:43
notmorganthat makes it hard to cache21:43
notmorgani am working on improving the cache-key generator as well in the upstream project so it is more flexible21:43
mgagnenotmorgan there is already cache in keystone. telling nobody/dev understands it mean I would have to disable it completely as it would be unreliable or badly coded.21:43
notmorganmgagne: there are very few people in openstack that understand caching21:44
notmorganand how to write it21:44
mgagneor you meant there is only 2 people in the team that knows how to code it21:44
notmorganmore like 3-521:44
notmorganit's why i try and spend a large amount of time reviewing any cache changes21:44
notmorgani'm trying to help folks understand it better21:45
notmorganso i'm not the only one who spends time adding it21:45
mgagnecool, thanks for that =)21:45
notmorganthere may be more but it's also limited in what folks are working on21:45
notmorganwriting code to manage caching is specialied and if you're not thinking about it regularly it takes longer to do21:45
dstaneknotmorgan: i think a lot of that is because we make it much harder than it needs to be21:46
notmorgancaching is one of the hardest things to get right in computer science. [specifically cache coherency]21:46
notmorgandstanek: part of it is that, part of it is people still don't understand how / when to invalidate21:46
notmorgandstanek: and using a raw memcache interface doesn't make that easier.21:46
notmorganand in most cases "eventual consistency" is a a disaster for how openstack is written21:47
bknudsonif it's hard then we're going to be constantly breaking it21:47
mgagnewhat have I started...21:47
bknudsonstop changing your catalog all the time.21:48
notmorganbknudson: we do a reasonable job of testing our invalidation code21:48
notmorgani think we've had 2-3 real bugs in caching21:48
*** tsymanczyk has joined #openstack-keystone21:48
notmorgannot inc. the keystonemiddleware "turn it off" type bug21:48
*** tsymanczyk is now known as Guest8329221:48
bknudsonwe don't have a gate job running multiple keystone instances with caching21:49
notmorganbknudson: soon21:49
notmorganbknudson: soon it'll be every dsvm21:49
notmorganhave a change up for that21:49
notmorganhttps://review.openstack.org/#/c/271892/21:50
notmorgansince we have a shared cache, it's trivial to enable it now21:50
notmorganbknudson: well every mitaka +21:51
notmorganbknudson: doesn't mean it'll be easier to write the caching code. though i think it's gotten much much better than the first pass that was done21:53
notmorganthe hard part are the invalidates tbh21:53
bknudsonsome caching is easier than others21:53
*** jsavak has quit IRC21:54
bknudsoncaching the catalog should be easy21:54
bknudson(but it's not)21:54
notmorganbknudson: yes. well part of that is poor design on our interfaces for the catalog21:54
notmorganbknudson: but we can start fixing that.21:54
*** jsavak has joined #openstack-keystone21:55
*** rderose has joined #openstack-keystone21:56
*** rderose has quit IRC21:58
*** jsavak has quit IRC22:00
*** ninag has quit IRC22:01
*** timcline has quit IRC22:01
*** aix_ has joined #openstack-keystone22:02
*** pnavarro has quit IRC22:07
*** su_zhang has joined #openstack-keystone22:07
*** mhickey has quit IRC22:10
*** Guest83292 has quit IRC22:15
*** dims has quit IRC22:16
*** dims has joined #openstack-keystone22:17
*** hongbin has joined #openstack-keystone22:17
*** tonytan4ever has quit IRC22:21
*** dims has quit IRC22:27
*** jsavak has joined #openstack-keystone22:30
*** gildub has joined #openstack-keystone22:31
*** rcernin has quit IRC22:31
*** tsymancz1k has joined #openstack-keystone22:35
stevemarnotmorgan: poke https://review.openstack.org/#/c/272134/22:48
stevemardstanek: poke for you too https://review.openstack.org/#/c/272134/22:48
*** jsavak has quit IRC22:49
dstanekstevemar: need a bp?22:49
stevemardstanek: it was left over from when you removed the main one :O22:49
stevemari could link it if you want22:49
openstackgerritSteve Martinelli proposed openstack/keystone: remove KVS backend for keystone.contrib.revoke  https://review.openstack.org/27213422:50
stevemardstanek: done22:50
dstanekstevemar: i mean in the commit message22:50
dstanekthx :-)22:50
*** jsavak has joined #openstack-keystone22:51
stevemarnp :)22:52
openstackgerrithenry-nash proposed openstack/keystone: Allow project domain_id to be nullable at the manager level  https://review.openstack.org/26453322:53
*** peter-hamilton has quit IRC22:53
openstackgerrithenry-nash proposed openstack/keystone: Verify project unique constraints for projects acting as domains  https://review.openstack.org/15837222:54
openstackgerrithenry-nash proposed openstack/keystone: Removes project.domain_id FK  https://review.openstack.org/23327422:55
*** doug-fish has quit IRC22:56
openstackgerrithenry-nash proposed openstack/keystone: Projects acting as domains  https://review.openstack.org/23128922:59
*** jsavak has quit IRC22:59
*** iurygregory has quit IRC22:59
stevemarnotmorgan: so, looking at https://review.openstack.org/#/c/27194823:00
*** iurygregory has joined #openstack-keystone23:00
stevemarnotmorgan: looks like it's conflicting with the deprecation checks i have for LDAP identity create/update/delete23:00
*** jsavak has joined #openstack-keystone23:00
stevemarnotmorgan: looks like it's failing here: https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_backend_ldap.py#L733-L74523:01
*** jsavak has quit IRC23:01
stevemarnotmorgan: because i emit a deprecation here: https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap.py#L171-L17323:01
notmorganstevemar: sure23:01
stevemarnotmorgan: i think you may be able to make the tests pass by checking whats in args and kwargs? args, _kwargs = mock_deprecator.call_args23:02
* notmorgan shrugs23:02
notmorgani haven't circled back to look at it23:02
notmorgansince i wrote it in like 15 mins23:02
stevemarnotmorgan: well i'm doing some circling for you :)23:02
notmorganhehe23:02
stevemarjust giving you a heads up!23:02
*** chlong has quit IRC23:02
stevemarbigger question is, why is it using that backend...23:03
notmorgani ... don't want to know tbh23:03
stevemarit means something in our tests is using keystone.common.kvs23:03
*** chlong has joined #openstack-keystone23:03
stevemarso either we untangle it now or later when we try to remove it :)23:03
notmorganwell yes23:04
notmorgancore is23:04
notmorgancause it needs to reset it23:04
notmorganand test_kvs is23:04
*** chlong has quit IRC23:04
*** phalmos has quit IRC23:05
notmorganand test_backend_kvs is23:05
notmorganthose are the only "kvs" strings in all of keystone's tests23:05
notmorganwell and test_kvs, which is expected23:05
*** chlong has joined #openstack-keystone23:05
*** sigmavirus24 is now known as sigmavirus24_awa23:07
*** pushkaru has quit IRC23:15
*** pushkaru has joined #openstack-keystone23:16
mgagnenotmorgan just to clarify, is the invalidation proxy only proposed to add invalidation support for in-memory cache? What I mean is: does someone using memcached need this patch or is .invalidate() doing what's expected in that context?23:19
notmorganmgagne: no that proxy does all the in-memory cache management23:20
*** pushkaru has quit IRC23:20
notmorganmgagne: so it's not just for invalidate it also does the cache store/retrieve from the in-memory locaiton and falls through to the normal backend if it's not in memory23:20
mgagnenotmorgan let me reword that question: with memcached, do I need this patch?23:20
notmorganmgagne: i've seen a benefit even with memcache, it depends on how loaded your memcache server is.23:21
mgagnenotmorgan I'm trying to read the function description and I have difficulties understanding its purpose (the one in dogpile.cache)23:22
notmorganmgagne: since this is all in-memory for the life of the request, there is less open-socket-ask-memcache-for-data-reconstruct-data-to-in-mem-object23:22
notmorganmgagne: basically this sits between the @memoize decorator and the memcache backend23:22
notmorganand it provies a second teir cache for the request itself23:22
*** hongbin has left #openstack-keystone23:23
openstackgerritSteve Martinelli proposed openstack/keystone: remove deprecated revoke_by_expiration function  https://review.openstack.org/27113523:23
notmorganthat only handles the data for that request at the end of the request the memory is freed and you're back at an empty cache. it has no bearing on memcache's caching (which happens as well)23:23
notmorganso what this is designed to do is move the cached data in-process for the request. meaning that subsequent calls should be faster for the same lookup23:23
mgagnenotmorgan alright, 2nd tier of cache. will someone only using memcached see staled cached entries?23:23
notmorganno.23:23
notmorganshould be the same, just a closer-to-the-processing cache23:24
notmorgansince it is in-python and doesn't require network transit23:24
mgagnenotmorgan makes perfect sense. A bit like the in-memory/per-request cache the Nova API introduced a couple of years ago to avoid round-trip to the database for extensions.23:25
notmorganit costs you a little more CPU, a little more memory (gc will free this eventually) and less network io, when scaling up to many many many keystone processes it should help keep the memcache server's network usage down23:25
mgagneagreed23:26
notmorganmgagne: sortof, though the nova cache is a little longer lived iirc than just the request23:26
notmorganbut not much23:26
mgagneit is only the request last time I checked23:26
mgagnesince I introduced the same to Cinder =)23:26
notmorgani thought thye used memorycache [in-mem dict]23:26
notmorganvs. a thread.local type thing23:26
mgagneI think it's in the request context or something23:26
notmorganthen it's the same as what i'm doing here, except that keystone already has a lot of cache hooks23:27
notmorganso the impact is potentially greater23:27
mgagnetrue23:27
notmorgansince it affects any place we already cache23:27
notmorganby design23:27
notmorgani did opt for a slightly more expensive serializer/deserializer for ease of code clarity23:28
notmorgani could move to a much faster (10x) serializer/deseralizer with a little work23:28
notmorganbut we're talking 7 usec on vs 60 usec on a i7 5660u23:28
mgagnetrying to cache service provider/federation (against kilo) https://git.dev.iweb.com/gist/mgagne/9ae6e8417dc95815a20123:28
*** chlong has quit IRC23:29
notmorganand i don't think 50 microseconds is worth battling over23:29
mgagneif the cost is only paid once per request and is not in the order of ms/s, I'm fine with it23:29
notmorganit washes out even more in xeons and even full desktop i7s23:29
mgagneI'm battling over seconds now =)23:29
notmorganwell the deserialize is paied every time23:29
notmorganbecause i didn't want to copy.deepcopy23:29
*** chlong has joined #openstack-keystone23:29
notmorganthat turned out to be nightmarishly hard to evaluate performance / benefit on23:30
notmorganso i stash it in the thread.local as a msgpack23:30
notmorganand deserialize on get23:30
mgagne=)23:30
notmorganthe reason is to avoid someone accidently doing .get_domain(id) ref['name'] = blah and now that cached value is "blah" named instead of "default"23:30
notmorganoops23:30
notmorgancost is about the same as the SQL-A object book-keeping or pickle (50% faster, but again 30 usec is "meh")23:31
*** EinstCrazy has joined #openstack-keystone23:31
notmorganand the general gate runs are showing a few minutes to 10 minutes savings on the fastest nodes23:31
notmorganand on the faster nodes making the keystone unit tests 200s runtime (real run - setup) vs 300 or 40023:32
notmorganit has a tangible benefit23:32
notmorganjust not ground breaking.23:32
*** slberger1 has left #openstack-keystone23:32
notmorganand that is layerd on top of an actual full-cache23:32
mgagneI got 99 problems and in-memory cache performance ain't one =)23:32
notmorganso anyway. will this help? likely will it help when i start applying this work to other openstack projects? yes even more so23:33
notmorganbut we will need to add more cache hooks into keystone for say trusts and fix the catalog one23:33
notmorganand finish the role_assignment one23:33
notmorgan[catalog and role assignment are pending some chatting this week @ the midcycle)23:33
mgagnenotmorgan unfortunately, it won't as all queries done by keystone are different when token is validated. You can see queries I captured with ngrep.23:33
*** rbak has quit IRC23:34
notmorganmgagne: the query might be different but we also do a lot of bookkeeping around similar calls23:34
mgagneI already applied catalog and assignment cache patches. It works very well when a 2nd token for the same user/project is validated. it doesn't change much when the user/project hits the API for the very first time in the last ~10m23:34
notmorgani would extend the resource cache to ~600s or 1200s tbh23:35
notmorganvs 30023:35
mgagnedoesn't change the 1st hit23:35
notmorganno23:35
notmorganbut first hit will always be a miss23:35
mgagneour users aren't super heavy users23:35
notmorganalways23:35
notmorganthen make the cache 86400 ;)23:35
mgagneso they don't hit the API every seconds/minutes23:35
mgagnenotmorgan this is a verrry short term solution IMO =)23:36
notmorganthe only case where that doesn't work is token validation23:36
mgagnenotmorgan we are talking about token validation here23:36
*** EinstCrazy has quit IRC23:36
notmorganyou should turn on middlewaretoken validation cache then23:36
mgagnenotmorgan token is created in a single centralized keystone endpoint with 0 latency to database23:36
mgagnealready done23:36
*** gordc has quit IRC23:36
notmorganthen you're doing it all 100% right23:37
notmorganthat cache should be ~300s23:37
mgagneI've done some homework first =)23:37
notmorganmax or so23:37
notmorganthe role_assignments and catalog cache can be very hight TTLs23:37
notmorganand will make many of the hits better23:37
notmorganlike those can probably be in the order of "days" for the TTL23:38
mgagnewill check on that side too23:38
mgagneI'm really looking into first that 1st hit performance issue23:38
notmorganwhich means you have few "first hit" misses [since i assume users use the APIs more often than days]23:38
mgagnethey don't use it often TBH23:38
notmorganfirst hit is always going to be slow(er), and honestly i'm not sure why you're seeing minutes23:39
notmorganfor validation23:39
notmorgansomething seems very broken if that is the case23:39
mgagnenotmorgan I tested with fake latency: 1s. we expect 100ms.23:39
notmorganoh23:39
notmorganooooh you're setting artificial latency23:39
notmorganthat can expand response time exponentially.23:40
mgagneyea, I explained it in my original question, might have forgot since or I was talking with someone else =)23:40
notmorgani didn't see all the convos23:40
mgagnenotmorgan yea and I find it unfortunate23:40
notmorgani expect if you're legitmately at 1s+ latency per query on a DB you need to increase the cache in the DB and/or expand the hardware23:41
mgagnenotmorgan story is: we use PKI with centralized keystones. We are evaluating Fernet with regional keystone nodes. Initial auth is still done from the central one but services will use regional nodes to validate tokens.23:41
notmorganwell good, cause PKI tokens are terribad23:41
mgagnenotmorgan cache in DB or hardware won't fix your transatlantic link latency23:41
notmorganactually >.>23:42
notmorganyou could solve this in a dirty way...23:42
mgagnenotmorgan so we are testing the effect of moving to fernet and with the expected 100ms latency. we see 4-6x performance hit to the API23:42
notmorganyou could implement a proxy like i did that pushes the validated data to the transatlantic cache server :P23:42
mgagnenotmorgan super expensive solution is with galera in all our regions.23:42
mgagnenotmorgan I don't have the time budget for it now =)23:42
notmorganso a design that we (some of us) are working on is a central galera23:42
notmorganand region nodes are big ram boxes that are read-only23:43
notmorganso queries are as fast as possible23:43
notmorganwrites are all central23:43
mgagnenotmorgan agreed, that's the final solution23:43
notmorgani'm planning on hacking in read-slave support into keystone in the next week or so23:43
notmorganto support this23:43
mgagnenotmorgan we are looking into it too23:43
mgagnenotmorgan but found writes to still occur when validating, maybe due to periodic_tasks or I don't know what23:44
*** david-lyle has quit IRC23:44
notmorganif someone signs out of horizon it'll write23:44
notmorganand with PKI you def. will see writes sinc ehte service user needs an active token23:45
notmorganso it'll issue/create a token23:45
mgagnewrites will occur to our centralized keystone server as we don't plan on hooking it to our regional nodes.23:45
notmorganas needed23:45
mgagnePKI is out once we fix the token validation issue we have23:45
notmorganrevocations need to be written to the central server if you want them at all23:45
notmorganotherwise you can just turn them off (effectively)23:46
notmorganbut tokens will always be valid23:46
notmorganuntil they expire23:46
mgagnethey should be unless services actively revoke tokens, maybe Heat23:46
notmorganif you issue a revoke at the regional keystone that revoke must be written to the central keystone23:46
notmorganif you want that token to be invalidated everywhere23:46
notmorganthat was the only sticking point we were running into with our design23:47
mgagnethe regional nodes are still hooked to the centralized database23:47
*** edmondsw has quit IRC23:47
notmorganright23:47
notmorganfor writes23:47
mgagneyou mean with slaves?23:47
notmorganyou can have a r/o slave23:47
notmorganbut any writes still need to go to the central cluster23:47
notmorganand the main source of writes from a regional node is "logout" or "password change"23:48
notmorganor some such23:48
openstackgerritSteve Martinelli proposed openstack/keystone: Reuse project scoped token check for trusts  https://review.openstack.org/25367223:48
notmorganwhere you need a event everywhere to revoke23:48
mgagneyes23:49
notmorganit's hard to explain via irc/text23:49
*** tsymancz1k has quit IRC23:50
mgagneonly "users" of regional nodes will be keystonemiddleware and services, we won't allow our API users to use it. So writes "should" go to central one23:51
*** spandhe has left #openstack-keystone23:51
mgagneonly issue I could see is cache invalidation in regional nodes which will all have their own memcached server.23:52
*** spandhe has joined #openstack-keystone23:54
spandhel23:54
*** su_zhang has quit IRC23:57
*** EinstCrazy has joined #openstack-keystone23:57
*** bknudson has left #openstack-keystone23:57
*** chlong has quit IRC23:58
*** chlong has joined #openstack-keystone23:59
*** shoutm has joined #openstack-keystone23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!