Monday, 2016-05-16

*** chlong has joined #openstack-keystone00:19
*** jorge_munoz has joined #openstack-keystone00:50
* jamielennox hates when I discover notmorgan might be right00:50
notmorganjamielennox: might be right about?00:51
notmorganalso... why is it a problem when I might be right?00:51
jamielennoxnotmorgan: only cause i disagreed with you for ages00:51
notmorganjamielennox: ok what did you disagree with me on this time?00:51
jamielennoxnotmorgan: i'm looking at keystone and the user/service token validation stuff00:51
jamielennoxabout passing only user_id, project_id etc as headers00:51
jamielennoxand - it's going to be super painful00:52
*** jorge_munoz has quit IRC00:52
notmorganheh00:52
jamielennoxi forgot how messy the actual auth layers are00:52
notmorganyah00:52
jamielennoxbut i'm currently looking at having to do a new provider00:52
jamielennoxanyway - you're right in that if i just pass everything that auth_token passes as headers from service->service then i don't need to validate any of it via keystone00:53
jamielennoxand it can all be done as auth_token middleware00:53
jamielennoxand it feels.. icky but there is so much pain doing it the other way00:53
notmorganjamielennox: i might have been thinking about this for a long time :(00:54
jamielennoxyea, it's nice to have a purist point of view when discussing stuff, but at some point sucumb to the practical00:55
jamielennoxwhich to be clear - does not mean i'm agreeing with the oslo.messaging thread local stuff yet00:55
notmorganjamielennox: oslo.messaging thread local?00:56
notmorganjamielennox: oslo_context you mean?00:56
jamielennoxyea, kinda, we discussed how to make sure all services send the right stuff via rpc and your idea was to just make oslo.messaging look at the thread local data and do it without the services input00:57
notmorganoh yeah00:57
notmorgani still think that is the right answer00:57
jamielennoxit might be the only practical answer unfortunately00:57
jamielennoxbut one revelation at a time00:57
*** itlinux has quit IRC01:08
*** itlinux has joined #openstack-keystone01:18
*** itlinux has quit IRC01:23
*** itlinux has joined #openstack-keystone01:25
*** jamielennox is now known as jamielennox|away01:26
*** itlinux has quit IRC01:26
*** jamielennox|away is now known as jamielennox01:28
*** itlinux has joined #openstack-keystone01:35
*** EinstCrazy has joined #openstack-keystone01:48
*** clenimar_ has joined #openstack-keystone01:49
*** clenimar_ has quit IRC01:49
*** clenimar_ has joined #openstack-keystone01:52
*** chlong has quit IRC01:56
clenimar_maybe it's time to remove the block on https://review.openstack.org/#/c/282377/01:58
patchbotclenimar_: patch 282377 - keystoneauth - Add is_domain to keystoneauth token01:58
clenimar_as the server side got merged :)01:58
clenimar_jamielennox ^01:59
jamielennoxclenimar_: block removed, i'll try and get to the review today01:59
clenimar_jamielennox: thank you sir :)01:59
jamielennoxsorry about putting the -2 on originally, it caught me the first time when it had 2 +As and wasn't merging02:00
*** EinstCrazy has quit IRC02:03
clenimar_no problem, it was the right thing to do02:03
*** itlinux has quit IRC02:04
*** EinstCrazy has joined #openstack-keystone02:04
*** itlinux has joined #openstack-keystone02:05
*** clenimar_ has quit IRC02:10
*** itlinux has quit IRC02:10
*** dave-mccowan has joined #openstack-keystone02:20
*** EinstCrazy has quit IRC02:26
*** EinstCrazy has joined #openstack-keystone02:28
*** EinstCrazy has quit IRC02:34
*** EinstCrazy has joined #openstack-keystone02:36
*** EinstCra_ has joined #openstack-keystone02:40
*** EinstCrazy has quit IRC02:43
*** itlinux has joined #openstack-keystone03:03
*** jamielennox is now known as jamielennox|away03:06
*** hoonetorg has quit IRC03:35
*** jamielennox|away is now known as jamielennox03:36
*** darren-wang has joined #openstack-keystone03:39
darren-wangHi, I'm recently research the access control of openstack, I wonder can we get 'domain_id' from project-scoped token?03:42
darren-wangwhen we use 'domain_id' in policy.v3cloudsample.json, does it specifically mean 'a  domain-scoped user' ?03:43
darren-wangAnd more accurate, I think I want to know, when we use the 'domain_id' in policy.v3cloudsample.json, are we saying that this user 'BELONGS to this domain' or 'SCOPES to this domain'?03:47
*** links has joined #openstack-keystone03:49
*** hoonetorg has joined #openstack-keystone03:51
darren-wangSo this is confusing because each user has attribute domain_id, meaning this user belongs to this domain, but when it comes to access control, 'domain_id' in policy language meaning the user is scoping to this domain04:01
darren-wangAm I correct?04:01
*** fangxu has quit IRC04:57
*** fangxu has joined #openstack-keystone04:58
*** hoonetorg has quit IRC05:11
*** rcernin has joined #openstack-keystone05:16
*** rcernin has quit IRC05:21
*** hoonetorg has joined #openstack-keystone05:24
*** TxGVNN has joined #openstack-keystone05:32
*** rcernin has joined #openstack-keystone05:38
*** GB21 has joined #openstack-keystone05:43
darren-wangAny body could help me with my questions about 'domain_id' in policy file?05:46
*** naresht has joined #openstack-keystone06:09
nareshtHi stevemar06:10
nareshtStevemar: Hi06:10
*** sheel has joined #openstack-keystone06:12
*** furface has quit IRC06:15
*** jaosorior has joined #openstack-keystone06:18
*** fangxu has quit IRC06:33
*** fangxu has joined #openstack-keystone06:34
nareshtI am trying to do Keystone Google Federation. I got this error http://paste.openstack.org/show/497176/06:44
nareshtAny help is highly appreciated06:44
*** josecastroleon has joined #openstack-keystone06:44
*** jaosorior has quit IRC06:55
*** jaosorior_ has joined #openstack-keystone06:55
*** jaosorior_ is now known as jaosorior07:00
*** GB21 has quit IRC07:03
*** josecastroleon has quit IRC07:14
*** GB21 has joined #openstack-keystone07:19
nareshtI am trying to do Keystone Google Federation.07:21
nareshtI getting this error oidc_authenticate_user: the URL hostname (federation.dams.com) of the configured OIDCRedirectURI does not match the URL hostname of the URL being accessed (xxx.xx.x.xxx): the "state" and "session" cookies will not be shared between the two!07:22
nareshtAny one tried this before ?07:22
nareshtAny help is highly appreciated07:23
*** GB21 has quit IRC07:35
*** vnogin has quit IRC07:43
*** vnogin has joined #openstack-keystone07:45
*** GB21 has joined #openstack-keystone07:52
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** jaosorior has quit IRC08:03
*** jaosorior has joined #openstack-keystone08:03
*** GB21 has quit IRC08:03
*** henrynash has quit IRC08:03
*** markvoelker has joined #openstack-keystone08:15
*** GB21 has joined #openstack-keystone08:16
*** markvoelker has quit IRC08:23
*** markvoelker has joined #openstack-keystone08:24
*** jistr has joined #openstack-keystone08:30
*** dmk0202 has joined #openstack-keystone08:32
*** zzzeek has quit IRC08:56
*** zzzeek has joined #openstack-keystone08:58
*** yiorgos_272 has quit IRC09:15
*** mvk has quit IRC09:28
*** mvk has joined #openstack-keystone09:57
*** daemontool has joined #openstack-keystone10:01
*** GB21 has quit IRC10:20
*** GB21 has joined #openstack-keystone10:33
*** fangxu has quit IRC10:33
*** fangxu has joined #openstack-keystone10:33
*** EinstCra_ has quit IRC10:36
*** rodrigods has quit IRC10:48
*** rodrigods has joined #openstack-keystone10:48
samueldmqmorning keystone10:56
*** markvoelker has quit IRC11:06
*** _fortis has quit IRC11:13
*** pnavarro has joined #openstack-keystone11:15
*** GB21 has quit IRC11:24
*** pnavarro has quit IRC11:27
*** pnavarro has joined #openstack-keystone11:36
*** GB21 has joined #openstack-keystone11:37
*** sdake has joined #openstack-keystone11:55
*** raildo-afk is now known as raildo12:06
*** markvoelker has joined #openstack-keystone12:08
*** sdake has quit IRC12:10
*** fangxu has quit IRC12:11
*** fangxu has joined #openstack-keystone12:12
*** markvoelker has quit IRC12:13
*** harbor has joined #openstack-keystone12:15
*** harbor has quit IRC12:16
*** harbor has joined #openstack-keystone12:17
*** harbor is now known as heyhty12:19
*** heyhty has quit IRC12:19
*** heyhty has joined #openstack-keystone12:19
*** heyhty has left #openstack-keystone12:19
*** GB21 has quit IRC12:20
*** heyhty has joined #openstack-keystone12:20
*** heyhty is now known as harbor212:20
*** iurygregory has joined #openstack-keystone12:29
*** pnavarro has quit IRC12:32
*** edmondsw has joined #openstack-keystone12:32
*** zqfan has quit IRC12:33
*** julim has joined #openstack-keystone12:40
*** notmorgan has quit IRC12:53
*** ninag has joined #openstack-keystone12:54
*** links has quit IRC12:55
*** markvoelker has joined #openstack-keystone13:00
*** pauloewerton has joined #openstack-keystone13:01
dstaneksamueldmq: morning13:03
*** markvoelker has quit IRC13:04
*** markvoelker has joined #openstack-keystone13:04
*** josecastroleon has joined #openstack-keystone13:16
*** ramishra has joined #openstack-keystone13:17
ramishraayoung: hi13:20
ayoungramishra, hey, you had a policy quesiont?13:20
ramishrayep, I'm trying to use is_admin_project thing13:20
ramishraNot sure why this policy is working.13:21
ramishrahttps://review.openstack.org/#/c/316627/1/etc/heat/policy.json13:21
patchbotramishra: patch 316627 - heat - Allow admin super user across projects13:21
ramishraI thought https://review.openstack.org/#/c/312443/ is the problem, but after changing that loally it does not seem to work either13:25
patchbotramishra: patch 312443 - openstack-dev/devstack - Change the domain name in keystone.conf13:25
ramishraany idea what's wrong?13:25
ayoungramishra, so it turns out that most of the services use oslo-context to enforce policy, and we would need a couple other patches to pass on that info13:25
ayoungI'll get you the patches13:25
ayounghttps://review.openstack.org/#/c/295870/13:27
patchbotayoung: patch 295870 - oslo.context - Add is_admin_project check13:27
ramishraah! thanks ayoung!13:28
ayoungramishra, I'm not certain if you only need that patch, or one to middleware to populate it yet.13:28
*** markvoelker has quit IRC13:28
ayoungramishra, jamielennox (who should be asleep right now) was taking this and running with it13:28
ramishrayeah, I realised that I don't need that13:29
ramishraI'm not using is_admin_projct from the context13:29
ayoungramishra, is the token object available?13:29
*** darosale has joined #openstack-keystone13:29
ramishraI don't see that attribute in the token13:31
ayoungramishra, then the config options in keystone are not properly set13:32
ayoungramishra, you need admin_project_domain_name and admin_project_name13:32
ayoungramishra, check me on the exact names...and make sure they are in the right subsection of the file.  Also, make sure you are a running Mitaka13:32
ramishrayeah, it's there [resource]13:33
ramishraadmin_project_name = admin13:33
ramishraadmin_project_domain_name = default13:33
ramishradriver = sql13:33
ramishraThat's the correct subsection I assume?13:34
*** tonytan4ever has joined #openstack-keystone13:35
ayoungramishra, I could say yes, but I'd be lying.   I don't remember.  Always check everything I say13:35
*** rderose has joined #openstack-keystone13:37
dstanekayoung: ++13:37
*** gordc has joined #openstack-keystone13:40
*** edmondsw has quit IRC13:43
*** sheel has quit IRC13:45
*** spzala has joined #openstack-keystone13:50
*** TxGVNN has quit IRC13:52
openstackgerritVictor Stinner proposed openstack/keystone: Port test_v2 unit test to Python 3  https://review.openstack.org/31206013:54
openstackgerritVictor Stinner proposed openstack/keystone: Port test_v3_auth unit test to Python 3  https://review.openstack.org/31206113:54
*** zzzeek has quit IRC13:56
*** ametts has joined #openstack-keystone13:57
*** zzzeek has joined #openstack-keystone13:58
*** josecastroleon has quit IRC13:59
*** sigmavirus24_awa is now known as sigmavirus2414:04
*** josecastroleon has joined #openstack-keystone14:05
*** sdake has joined #openstack-keystone14:08
*** doug-fish has joined #openstack-keystone14:08
*** pushkaru has joined #openstack-keystone14:10
lbragstadsamueldmq morning14:11
lbragstadsamueldmq re: calling the revocation api directly instead of using notifications. Don't we do this already?14:14
*** links has joined #openstack-keystone14:15
*** rbridgeman has quit IRC14:18
*** rbridgeman has joined #openstack-keystone14:18
*** phalmos has joined #openstack-keystone14:18
*** wxy has quit IRC14:20
*** stingaci has quit IRC14:24
*** markvoelker has joined #openstack-keystone14:25
*** edtubill has joined #openstack-keystone14:27
*** markvoelker has quit IRC14:30
*** woodburn1 has quit IRC14:30
*** jorge_munoz has joined #openstack-keystone14:32
*** rbridgeman_ has joined #openstack-keystone14:34
*** josecastroleon has quit IRC14:35
*** edmondsw has joined #openstack-keystone14:35
*** rbridgeman has quit IRC14:38
*** slberger has joined #openstack-keystone14:38
*** stingaci has joined #openstack-keystone14:43
*** raddaoui has joined #openstack-keystone14:46
ayounglbragstad, no14:47
ayoungwe want that to die14:47
lbragstadayoung yeah, we need to sync on what samueldmq and I found out over the weekend14:48
lbragstadsamueldmq around?14:48
ayounglbragstad, what did you find?14:48
lbragstadcc dstanek also wants to be a part of that conversation14:48
lbragstadayoung wrapping up a meeting quick14:48
lbragstadayoung are you available in 10 - 15 minutes?14:48
dimshas anyone tried pyldap? https://review.openstack.org/#/c/315793/14:48
patchbotdims: patch 315793 - requirements - Add pyldap to g-r14:48
*** stingaci_ has joined #openstack-keystone14:49
ayounglbragstad, I'll be here14:49
ayoungdims, stevemar was working on it14:49
ayoungdims, the issue he found was that ldappool was not ported14:49
ayoungand we were discussing whether we could kill LDAP pool now that we are out from evently14:50
ayoungeventlet14:50
ayoungdims, but he has a WIP patch up for it14:50
*** stingaci has quit IRC14:52
*** josecastroleon has joined #openstack-keystone14:52
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add policy registration  https://review.openstack.org/31314114:52
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add authorize method to Enforcer  https://review.openstack.org/31314214:52
*** henrynash has joined #openstack-keystone14:53
*** ChanServ sets mode: +v henrynash14:53
*** notmorgan has joined #openstack-keystone14:53
dimsayoung : thanks14:53
notmorgan.14:54
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add sample file generation script  https://review.openstack.org/31424414:55
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add helper methods for generating policy info  https://review.openstack.org/31477414:55
openstackgerritAndrew Laski proposed openstack/oslo.policy: Add __str__ to PolicyOpt  https://review.openstack.org/31571214:55
*** jaosorior has quit IRC14:55
*** stingaci has joined #openstack-keystone14:55
lbragstadping dolphm dstanek ayoung samueldmq jorge_munoz i'm going to reload coffee quick and then I'll come brain dump what samueldmq and i found last week14:55
*** jaosorior has joined #openstack-keystone14:55
*** timcline has joined #openstack-keystone14:56
*** stingaci_ has quit IRC14:57
*** mou has quit IRC15:00
*** naresht has quit IRC15:00
*** mou has joined #openstack-keystone15:01
*** ninag has quit IRC15:01
*** julim has quit IRC15:01
*** jaosorior has quit IRC15:01
*** jaosorior has joined #openstack-keystone15:02
*** itlinux has quit IRC15:02
*** gordc has quit IRC15:03
lbragstadayoung ok - so samueldmq submitted a patch to keystone to add logging to the revocation API https://review.openstack.org/#/q/topic:token-revocation-issue15:03
*** julim has joined #openstack-keystone15:03
*** ninag has joined #openstack-keystone15:03
lbragstadthere are duplicates so that we would hopefully get a better failure rate15:03
ayoungWhat?15:03
lbragstadayoung for some reason - no one has been able to recreate this locally15:04
lbragstaddespite using the same devstack configs15:04
*** ninag_ has joined #openstack-keystone15:04
*** tonytan4ever has quit IRC15:04
lbragstadsome patches were added to tempest to log the x-auth-token and some patches were added to keystone to log the revocation api15:05
notmorganstevemar, lbragstad, dstanek, ayoung: https://review.openstack.org/#/c/315793/15:05
patchbotnotmorgan: patch 315793 - requirements - Add pyldap to g-r15:05
*** yarkot has quit IRC15:05
notmorganthis needs your eyes to land.15:05
*** ninag__ has joined #openstack-keystone15:05
lbragstadayoung here is one of the failures15:06
lbragstadhttp://logs.openstack.org/56/316256/4/check/gate-tempest-dsvm-postgres-full/6956621/console.html#_2016-05-13_23_39_15_61815:06
ayoungFile Not Found15:06
ayounglbragstad, one sec15:07
*** yarkot has joined #openstack-keystone15:07
ayounghttp://logs.openstack.org/56/316256/4/check/gate-tempest-dsvm-postgres-full/6956621/console.html.gz#_2016-05-13_23_39_15_61815:07
lbragstadayoung yep - so this is the test that is failing https://github.com/openstack/tempest/blob/master/tempest/api/identity/admin/v2/test_roles_negative.py#L64-L7315:08
ayoungraise mismatch_error15:08
*** ninag has quit IRC15:08
lbragstadyep - we get a token, delete that token, and then try to assert that we can't create a role with that token15:08
ayoungself.assertRaises(lib_exc.Unauthorized,15:08
lbragstadthe assertion is failing because keystone still thinks that token is valid15:08
ayoungand that mismatches with the actual value15:09
*** ninag_ has quit IRC15:09
lbragstaddespite the fact that keystone returns a 204 when the token is deleted15:09
ayounglbragstad, I wonder if it has to do with the delete call15:09
lbragstadthe delete call returns a 204 as expected15:09
ayoungsome sort of interaction with the previous test15:09
*** ninag__ has quit IRC15:10
*** pushkaru has quit IRC15:10
lbragstadthis is the request ID of the call that should have failed the role create (because the token was deleted)15:10
ayounglbragstad, um,   wouldn't the client be smart enough to request a new token?15:10
lbragstadhttp://pastebin.com/tRdTUA6n15:10
*** jorge_munoz has quit IRC15:10
lbragstadayoung that's why we added logging using the x-auth-token in temepst15:11
ayounglbragstad, please just merge my "replace tree with list"15:11
ayoungits not worth debugging the tree code15:11
*** haplo37 has joined #openstack-keystone15:11
lbragstadwe wanted to make sure the clients weren't being smart about token15:11
*** jorge_munoz has joined #openstack-keystone15:11
ayounghttps://review.openstack.org/#/c/311652/15:11
patchbotayoung: patch 311652 - keystone - Replace revoke tree with linear search15:11
ayoungseriously,  madness will ensure.  We are talkin Lovecraftian stuff here, if you pursue the Tree.15:11
lbragstadayoung one sec15:11
*** rbridgeman_ has quit IRC15:12
lbragstadif you look at http://pastebin.com/tRdTUA6n you see that the revocation event that should have been persisted isn't in the revocation backend15:12
*** rbridgeman_ has joined #openstack-keystone15:12
lbragstad^ that logging is the logging of the request ID for the create role call15:12
*** itlinux has joined #openstack-keystone15:18
lbragstadthe revocation tree in that log should have an event that matches the token (either the user_id 4e5920ae32c048c3acc9e567cd116480 or audit_id 0sZ2HIxOSJGJw7oPC6zt6w )15:18
*** zqfan has joined #openstack-keystone15:19
lbragstadayoung will switching to a list still be prone to that ^ problem?15:20
lbragstadproblem/race condition?15:20
samueldmqlbragstad: hi15:21
lbragstadsamueldmq o/15:21
samueldmqo/15:21
*** josecastroleon has quit IRC15:21
lbragstadsamueldmq I did some poking over the weekend15:22
samueldmqlbragstad: I think I have a strategy to debug this issue ... let's see what you think about it15:22
samueldmqlbragstad: nice15:22
samueldmqlbragstad: a good strategy*15:22
ayounglbragstad, no idea, but it will be a heckofalot easier to debug15:22
openstackgerritayoung proposed openstack/keystone: Replace revoke tree with linear search  https://review.openstack.org/31165215:22
lbragstadsamueldmq the only thing I can come up with is that the revocation event isn't persisted when we go to validate the token15:22
lbragstad* when we go to validate the "invalid" token*15:23
samueldmqlbragstad: what if we logged all the trace between request arriving in keystone (token delete) -> reaching the managers etc -> emitting revocation event -> registering in the tree15:23
ayoungsamueldmq, lbragstad lets please use ^^ before we spend anymore cycles on the tree15:23
*** richm has joined #openstack-keystone15:24
samueldmqayoung: issue is not just the tree ... it's not even reaching the tree we think15:24
notmorganbknudson: ping looks like i found a bug in bandit.15:24
notmorganbknudson: https://review.openstack.org/#/c/311133/10/keystoneauth1/fixture/hooks.py not detected as a mutable default.15:24
patchbotnotmorgan: patch 311133 - keystoneauth - Use betamax hooks to mask fixture results15:24
ayoungsamueldmq, maybe the revoke event cache needs to be invalidated?15:25
samueldmqayoung: not sure ... event the call to add_event is delayed15:25
samueldmqayoung: looks like it happens seconds later15:25
bknudsonnotmorgan: I thought we had a pep8 check for that?15:26
notmorganbknudson: i thought it was bandit :P15:26
samueldmqayoung: what I was suggesting to lbragstad was to LOG all the trace of the request (DELETE token) within keystone, so we will see where it stops/fails/whatevers15:26
notmorganbknudson: in either case.. mutable default check fails there.15:26
bknudsonnotmorgan: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/hacking/checks.py#n6815:27
ayoungsamueldmq, what if delete token ran a check to ensure the token was deleted?15:27
ayounginternally?15:27
bknudsonnotmorgan: not sure if bandit would have a check for that... is it a security issue?15:28
samueldmqayoung: not true for fernet15:28
samueldmqayoung: we can't do that15:28
bknudsonI guess it could lead to a security problem, but then so could most coding issues.15:28
notmorganbknudson: mutable defaults lead that way iirc.15:28
ayoungsamueldmq, it better be true for Fernet.15:29
*** stingaci has quit IRC15:29
samueldmqayoung: tokens be deleted ? fernet tokens aren't stored, right?15:29
lbragstadright15:30
openstackgerritRon De Rose proposed openstack/keystone: Add password table columns to meet PCI-DSS change password requirements  https://review.openstack.org/31428415:30
notmorganbknudson: or we ned to fix pep8 :)15:30
notmorganeither wfm15:30
*** doug-fish has quit IRC15:30
lbragstadwe would have to ensure the token that was deleted has the proper/matching revocation event stored in the revocation api15:30
samueldmqexactly15:32
lbragstadthis isn't an issue with uuid because even though a revocation event is stored when we use uuid - we delete the token15:32
lbragstadso when we go to validate a uuid token, we fail on the backend/sql look up before comparing the uuid token context to the revocation api15:33
bknudsonnotmorgan: that check is only on keystone and not on keystoneauth. Might want to move it upstream.15:33
notmorganbknudson: ah.15:34
samueldmqlbragstad: ++ so even if our revocation API code was failing, the result was the same15:34
*** diazjf has joined #openstack-keystone15:37
*** pushkaru has joined #openstack-keystone15:38
lbragstadayoung you're proposing that when we do a DELETE token in keystone, we do something like: http://cdn.pasteraw.com/8a9z6lrebclm2y5jdvm9a1fe7e31tq115:39
lbragstadessentially we would be polling the revocation api until we can confirm that the revocation event is stored15:41
lbragstadbefore returning the 204 of the DELETE token call15:41
*** fangxu has quit IRC15:41
ayounglbragstad, nope15:42
ayoungin the controller for delete tokens15:42
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/controllers.py#n54715:42
lbragstadayoung ok - but same pattern right?15:42
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/routers.py#n3115:43
ayounglbragstad, yep15:43
ayounglbragstad, and if it fails...what should we do?15:43
lbragstadayoung  if what fails?15:44
lbragstadthe validate call?15:44
ayounglbragstad, yes15:44
*** dmk0202 has quit IRC15:44
samueldmqHTTP 5000 dump the world15:44
ayoungsamueldmq, nope15:44
lbragstadso - we get a token id and say revoke this token, then we validate the token and it comes back as valid15:44
ayoungsamueldmq, it might be legit to fail.15:44
ayounglbragstad, yeah...sleep (1) ?15:45
samueldmqayoung: fail to delete a token?15:45
ayoungwe probably build a DOS mech in to Keystione if we do that, though15:45
lbragstadyeah15:45
samueldmqwe just need to figure out where the workflow is broken15:45
samueldmqI will try to get a change to LOG all the DELETE token workflow15:45
samueldmqand we'll see where is the issue15:46
lbragstadtechnically - keystone returns a 204 on the DELETE token call15:46
samueldmqmakes sense?15:46
lbragstadso why isn't the revocation event being stored?15:46
samueldmqlbragstad: yes, so it emits the token revocation event sucessfully15:46
samueldmqlbragstad: looks like the issue is in the revocation logic15:46
lbragstadsamueldmq another thing15:47
lbragstadit could be getting stored - but maybe it isn't being pulled out properly?15:47
*** josecastroleon has joined #openstack-keystone15:47
* lbragstad is grabbing at straw15:47
lbragstads15:47
samueldmqlbragstad: I don't think so, the logs don't show a consistent 'Persisting event .. ' thing15:48
lbragstadoh - good point15:48
*** rbridgeman_ has quit IRC15:50
samueldmqlbragstad: ayoung: hmmmm, I found something interesting15:51
*** gordc has joined #openstack-keystone15:51
samueldmqlbragstad: ayoung https://github.com/openstack/keystone/search?utf8=%E2%9C%93&q=invalidate_individual_token_cache15:52
samueldmqthe call to invalidate_individual_token_cache in the token provider only happens in the persist layer15:53
samueldmqwhich is something that isn't called for fernet, so invalidate_individual_token_cache is never called for fernet ?15:53
samueldmqdoes this make sense? ^15:54
lbragstadsamueldmq that's strange15:54
lbragstadcc notmorgan ^15:54
*** henrynash has quit IRC15:54
lbragstadI thought I remember seeing that last week15:54
*** sheel has joined #openstack-keystone15:56
samueldmqlbragstad: you agree a cache issue may be the cause?16:00
*** furface has joined #openstack-keystone16:00
lbragstadsamueldmq it could be16:01
lbragstadsamueldmq but if the cache was never being invalidated for fernet - how would it work sometimes but not others?16:01
samueldmqlbragstad: does fernet need token/persistence/core.py at all?16:01
lbragstadsamueldmq no16:02
*** henrynash has joined #openstack-keystone16:02
*** ChanServ sets mode: +v henrynash16:02
lbragstadsamueldmq we have logic in the token provider to explicitly ignore persistence if using fernet16:03
samueldmqlbragstad: could you point me to the code where a fernet token is "deleted"? i.e the revocation notification is sent?16:04
samueldmqlbragstad: also to where a fernet tken is validated ?16:04
*** julim has quit IRC16:04
lbragstadsamueldmq this is where a token is revoked - https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/provider.py#L43116:04
lbragstadsamueldmq that *all* happens in the keystone.token.provider.py module16:05
lbragstadand a revoke token call doesn't go down to the provider in the fernet case16:05
*** stingaci has joined #openstack-keystone16:05
*** julim has joined #openstack-keystone16:06
samueldmqlbragstad: so what I said is true, invalidate_individual_token_cache is never called in fernet case16:07
samueldmqlbragstad: https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/provider.py#L223 and16:08
samueldmqlbragstad: https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/provider.py#L26716:08
samueldmqlbragstad: validate fernet tokens right ?16:08
lbragstadsamueldmq yes - but there is also a validate_token method16:08
*** gyee has joined #openstack-keystone16:09
*** ChanServ sets mode: +v gyee16:09
lbragstadsamueldmq https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/provider.py#L20416:09
*** rderose has quit IRC16:09
lbragstadwhich attempts to figure out which version token you have16:09
lbragstadand validates it accordingly16:09
samueldmqlbragstad: will take a look, thx16:10
*** ninag has joined #openstack-keystone16:12
*** ninag has quit IRC16:12
*** henrynash has quit IRC16:13
*** josecastroleon has quit IRC16:16
*** ninag has joined #openstack-keystone16:17
*** ninag has quit IRC16:18
lbragstadsamueldmq should we move https://github.com/openstack/keystone/blob/f7b33213f1cb8313d2cb81225e8530ebbc37ce18/keystone/token/persistence/core.py#L193 in to the token_provider?16:21
samueldmqlbragstad: I can't find where the fernet token is checked against the revocation tree at all16:21
samueldmqlbragstad: I think so16:22
*** rderose has joined #openstack-keystone16:22
*** julim has quit IRC16:23
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth: Updated from global requirements  https://review.openstack.org/31697816:25
*** agrebennikov has joined #openstack-keystone16:26
*** lhcheng has joined #openstack-keystone16:27
*** ChanServ sets mode: +v lhcheng16:27
lbragstadsamueldmq it is in keystone/token/provider.py16:29
lbragstadsamueldmq https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/provider.py#L260-L26516:30
samueldmqlbragstad: oh I think that is the issue16:30
*** josecastroleon has joined #openstack-keystone16:30
samueldmqlbragstad: https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/provider.py#L204 is the starting point to validate tokens16:30
samueldmqlbragstad: and it calls self._validate_token, which is cached!16:31
*** darosale has quit IRC16:31
samueldmqlbragstad: but _is_valid_token16:31
samueldmqlbragstad: is the part that cehcks against the revoction tree...16:32
lbragstadeyah16:32
notmorganYeah. For best caching we had to split the two things.16:34
*** julim has joined #openstack-keystone16:34
*** TxGVNN has joined #openstack-keystone16:38
lbragstadnotmorgan for best caching?16:39
notmorganYes, so we didn't need to invalidate as much.16:40
notmorganInvalidations get expensive the more you need to do them since they force cache misses.16:40
lbragstadsamueldmq I could see the issue we're seeing a cache invalidation problem over a revocation event persistence problem16:40
*** timcline_ has joined #openstack-keystone16:41
notmorganSo checking the revoke tree is independent of looking up the token data.16:41
notmorganAnd it should be.16:41
*** fangxu has joined #openstack-keystone16:41
*** mou has quit IRC16:42
*** timcline has quit IRC16:42
amakarovhi! Can anybody explain why keystone rewrites project ID on creation for v3 and does not for v2.0?16:43
agrebennikovI'd even ask it in a bit different way - v2 allows to specify project ID upon creation, while v3 strictly generates it16:44
agrebennikovis there a reason behind it?16:44
openstackgerritOpenStack Proposal Bot proposed openstack/ldappool: Updated from global requirements  https://review.openstack.org/31698516:45
*** links has quit IRC16:47
*** dan_nguyen has joined #openstack-keystone16:51
*** diazjf has quit IRC16:53
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Invalidate token cache after token delete  https://review.openstack.org/31699116:55
samueldmqlbragstad: ^16:55
lbragstadsamueldmq sweet16:57
lbragstadsamueldmq I wonder if we should base all the other changes on that to see if we see *less* occurrences of bug 157886616:57
openstackbug 1578866 in OpenStack Identity (keystone) "test_user_update_own_password failing intermittently" [High,In progress] https://launchpad.net/bugs/1578866 - Assigned to Lance Bragstad (lbragstad)16:57
samueldmqlbragstad: ++17:00
samueldmqlbragstad: I will put depends-on on the temepst patches17:01
samueldmqlbragstad: they're failing more often17:01
lbragstadsamueldmq awesome17:01
ayoungamakarov, "rewrites?"17:01
amakarovayoung, unconditionally generates new ID17:02
*** jistr has quit IRC17:02
ayoungamakarov, V2 wsas not doing that, or just the driver was not?17:02
amakarovayoung, https://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L87 vs https://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L24017:03
*** furface has quit IRC17:03
*** josecastroleon has quit IRC17:03
ayoungamakarov, that is in the controller, hidden from the end user of the web api, though17:04
ayoungamakarov, for v2 we generate the id on line 10217:04
ayounghttps://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L10217:05
amakarovayoung, right but only if it isn't in tenant_ref17:05
ayoungamakarov, that might be a bug17:06
amakarovon line 240 existing id is just ignored17:06
amakarovayoung, or a feature )17:06
ayoungamakarov, well, I would consider it a feature.  I filed a feature request for it.17:06
*** stingaci has quit IRC17:06
ayoungamakarov, https://review.openstack.org/#/c/203852/17:07
patchbotayoung: patch 203852 - keystone - Specify ID for Project or domain creation (ABANDONED)17:07
*** pnavarro has joined #openstack-keystone17:07
ayoungaas you can see, It was denied17:07
*** stingaci has joined #openstack-keystone17:07
amakarovagrebennikov, ^^17:07
*** doug-fish has joined #openstack-keystone17:08
*** ninag has joined #openstack-keystone17:10
*** doug-fis_ has joined #openstack-keystone17:10
amakarovayoung, as I see all the objections was about spec absence17:10
ayoungamakarov, not quite17:10
ayounghis point was that he wanted it as a service admin type operations17:10
*** ninag_ has joined #openstack-keystone17:11
*** ninag_ has quit IRC17:11
amakarovayoung, looks like a thing to discuss tomorrow17:12
*** doug-fi__ has joined #openstack-keystone17:12
ayoungamakarov, please.17:12
agrebennikovayoung, so technically if I apply your patch to my current deployment it will not be a dirty hack then? ;)17:12
*** david-lyle_ has quit IRC17:12
agrebennikovif you guys negotiated on pushing it forward17:13
*** doug-fish has quit IRC17:13
*** david-lyle has joined #openstack-keystone17:13
*** doug-fis_ has quit IRC17:14
*** ninag has quit IRC17:15
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS 8.2.4: User must change their password requirements  https://review.openstack.org/31700717:15
*** doug-fi__ has quit IRC17:16
*** real56 has joined #openstack-keystone17:17
*** tonytan4ever has joined #openstack-keystone17:21
*** ninag has joined #openstack-keystone17:23
notmorganayoung: meeting invite thing you forwarded didn't end up on my calendar :( sorry17:24
*** josecastroleon has joined #openstack-keystone17:24
notmorganayoung: it got lost somewhere in the zimbra -> google move.17:24
ayoungnotmorgan, not a big deal.  We just touched on the CI issue for a minute at the end, but there is other Keystone issues we discussed that you are full aware of.17:25
*** dims_ has joined #openstack-keystone17:25
ayoungFernet, revoke events, python3/ldap etc17:25
notmorganokie17:25
notmorganayoung: did you see my ping re the review to add pyldap to g-r?17:26
ayoungnotmorgan, yes, and dims came by earlier askin about it17:26
*** dims has quit IRC17:26
notmorganayoung: ok, so that is going to hold up ldappool py3 stuff.17:26
ayoungnotmorgan, I think we can kill ldappool and just drive on with pyldap17:26
notmorganayoung: lets just do a release of ldapool that is py3 compat and look at extricating it from keystone down the line.17:27
notmorganreally review if we can remove it.17:27
dstanekuggg...it looks like dogpile doesn't allow expiration to be provided to the set() :-(17:28
notmorganbut it will be a lot shorter to do pyldap+ldappool in keystone ot hit py317:28
notmorgandstanek: nope, configured at the region level17:28
stevemarnotmorgan: yes it will17:28
notmorganayoung: and we need to land pyldap in g-r *anyway*17:28
notmorganunless we're only going with ldap3.17:28
notmorganand the feeling i got was... that is going to be a lot of discussion17:29
notmorganeven though i'd much prefer it.17:29
dstaneknotmorgan: super not cool!17:29
*** anush has joined #openstack-keystone17:30
*** anush has quit IRC17:32
*** doug-fish has joined #openstack-keystone17:32
*** anush has joined #openstack-keystone17:33
*** mvk has quit IRC17:33
ayoungnotmorgan, I thought we were going for pyldap short term, ldap3 longer term.17:33
*** TxGVNN has quit IRC17:33
notmorganayoung: doesn't matter what way we go17:33
notmorganayoung: justsaying we need to land pyldap in g-r unless we only did ldap317:33
ayoungnotmorgan, agreed, and I did add a note to that effect in the review just now17:34
ayoungstevemar, did you test pyldap with ldappool removed?17:34
dstaneknotmorgan: once i get this capstone stuff pushed i'll be looking at the reviews you posted17:34
notmorganayoung: ldappool has a fix to use pyldap and pending a release as soon as the g-r lands fwiw17:35
notmorganayoung: since we had it transferred to us.17:36
*** doug-fish has quit IRC17:38
*** anush has quit IRC17:43
ayoungnotmorgan, that works, too, but I wonder if we need it?17:43
*** anush has joined #openstack-keystone17:45
*** rcernin has quit IRC17:47
*** pnavarro has quit IRC17:48
*** doug-fish has joined #openstack-keystone17:53
*** anush has quit IRC17:55
*** doug-fish has quit IRC17:58
*** josecastroleon has quit IRC17:58
*** doug-fish has joined #openstack-keystone17:59
*** josecastroleon has joined #openstack-keystone18:01
*** roxanaghe has quit IRC18:02
*** anush has joined #openstack-keystone18:03
*** julim has quit IRC18:07
*** roxanaghe has joined #openstack-keystone18:07
*** julim has joined #openstack-keystone18:08
*** diazjf has joined #openstack-keystone18:10
*** ninag has quit IRC18:13
*** ninag has joined #openstack-keystone18:13
*** ninag has quit IRC18:14
*** ninag has joined #openstack-keystone18:14
*** doug-fis_ has joined #openstack-keystone18:15
*** doug-fish has quit IRC18:18
*** doug-fis_ has quit IRC18:21
*** doug-fish has joined #openstack-keystone18:21
*** real56 has quit IRC18:23
*** ninag has quit IRC18:24
*** doug-fish has quit IRC18:26
*** josecastroleon has quit IRC18:30
*** ninag has joined #openstack-keystone18:36
*** ninag has quit IRC18:36
*** ninag has joined #openstack-keystone18:37
openstackgerritRon De Rose proposed openstack/keystone: Move the oauth1 abstract base class out of core  https://review.openstack.org/31704518:38
*** josecastroleon has joined #openstack-keystone18:41
*** ninag has quit IRC18:42
openstackgerritRon De Rose proposed openstack/keystone: Move the oauth1 abstract base class out of core  https://review.openstack.org/31704518:44
*** stingaci has quit IRC18:47
lbragstadnotmorgan i think i missed it, but was there a reason for not doing https://github.com/openstack/keystone/blob/f7b33213f1cb8313d2cb81225e8530ebbc37ce18/keystone/token/persistence/core.py#L193 in the provider.py module?18:53
notmorganlbragstad: it was in persistence already -- why are you needing to explicitly invalidate on revoke?18:54
lbragstadnotmorgan just thinking about the race condition we're seeing in the gate and trying to rule that out as a possibility18:54
notmorganthe race is "token validates, but revoke event has been issued"?18:55
notmorganand is the race against the keystone api?18:55
notmorganor against a service api18:55
lbragstadnotmorgan a revocation event has been issued and tempest goes to validate the token against keystone, expecting a 401, but gets a valid authentication response instead18:55
notmorganlbragstad: if you validate that "successful" token again, does it still stay valid?18:56
notmorganlike does a sleep(1) after the revoke is issued solve it18:56
*** rbridgeman has joined #openstack-keystone18:56
lbragstadnotmorgan this workflow https://github.com/openstack/tempest/blob/c69d06dbb4c14eec305ed6f0db947af77427c04c/tempest/api/identity/admin/v2/test_roles_negative.py#L66-L7318:56
notmorgan[i am assuming not]18:56
lbragstadat line 69 tempest does a DELETE token18:57
notmorganand it intermittantly still validates18:57
lbragstadand at line 72 they attempt to do something with the token they just deleted and that operation is successful18:57
lbragstadyes18:57
lbragstadnotmorgan that led us to adding the logging for the revocation api18:58
lbragstadwe hit the same failure with the logs (which logs the entire revocation tree)18:58
lbragstadand noticed that when the request comes in to do some operation that should be invalid - the revocation isn't matching anything because the revocation event isn't ther e18:59
lbragstadnotmorgan I have an example18:59
*** anush has quit IRC18:59
lbragstadnotmorgan here we have a failure http://logs.openstack.org/56/316256/4/check/gate-tempest-dsvm-postgres-full/6956621/console.html.gz#_2016-05-13_23_39_15_61818:59
*** ninag has joined #openstack-keystone18:59
lbragstadkeystone should have returned a 401 for that token18:59
*** ninag has quit IRC18:59
lbragstadbecause it has been revoked19:00
*** doug-fis_ has joined #openstack-keystone19:00
*** ninag has joined #openstack-keystone19:00
notmorganbut the revoke event for that token doesn't exist?19:00
lbragstadthis is the logging of the request ID of the create role call http://pastebin.com/tRdTUA6n19:00
lbragstadif you search for the audit_id or user_id of the token that should be revoked, you don't see it in the revocation tree19:00
notmorganoh wow19:02
notmorganthat is a bug.19:02
lbragstadnotmorgan absolutely - but it's also a race condition19:02
notmorgani think.19:02
*** edmondsw has quit IRC19:02
lbragstadso - how is it that it sometimes passes and sometimes fails?19:02
*** doug-fis_ has quit IRC19:02
notmorganso i think i know exactly why19:02
notmorgani'm looking to try and chase it down though.19:03
lbragstadwe return a 204 on the DELETE token call, which should mean that we successfully stored a revocation event19:03
notmorgandoesn't mean we saved a revoke event.19:03
notmorganmeans we claim we have ;)19:03
lbragstadnotmorgan do we cache revocation events?19:03
*** woodster_ has joined #openstack-keystone19:03
notmorganwe do19:03
lbragstadwe also cache tokens.19:03
notmorganwhich should be fine19:04
lbragstadwhich is what I think samueldmq was getting to with https://github.com/openstack/keystone/blob/f7b33213f1cb8313d2cb81225e8530ebbc37ce18/keystone/token/persistence/core.py#L193 ?19:04
notmorgancaching a token is 100% ok. in fact, not caching the token would have no impact but to make it a bit slower to validate19:04
notmorganbecause with fernet -- we would rebuild the token19:04
*** tqtran has joined #openstack-keystone19:04
notmorganinvalidating the token cache isn't super relevant, with UUID/PKI we *have* to invalidate the token validate because we lean on the revocation_list (a column in the token table) as a way to check validity19:05
lbragstadnotmorgan it seems we could be hitting one of two things. We are caching the revocation events and not invalidating that cache when a new revocation event is added. Or we are caching tokens and not invalidating that cache when a new revocation event is added (but I doubt that case).19:07
*** josecastroleon has quit IRC19:13
*** rderose has quit IRC19:19
*** mdurrant has joined #openstack-keystone19:23
mdurrantI'm trying to find an outstanding bug on the current devstack-killing oslo.config 3.9.0 issue...19:25
mdurrantkeystone-middleware 4.4.0 installation bombs and complains that it can't find oslo.config 3.9.019:26
*** tonytan4ever has quit IRC19:27
*** josecastroleon has joined #openstack-keystone19:31
*** rderose has joined #openstack-keystone19:33
lbragstadnotmorgan it sounded like you had a suggestion but I don't think I got it?19:34
notmorganlbragstad: still looking at code19:34
*** rcernin has joined #openstack-keystone19:42
samueldmqlbragstad: we came to a conclusion that, as persisted tokens were effectivelly deleted, everything was fine for UUID19:43
notmorganthis is almost 100% sure to be an issue with revocation events19:44
samueldmqlbragstad: but ... the error was also happening in password change19:44
notmorganeither the storing or caching of them.19:44
samueldmqnotmorgan: agreed19:44
notmorganso lets not look at token caching unless we eliminate rev. event issues 100%19:44
*** edmondsw has joined #openstack-keystone19:44
samueldmqnotmorgan: we were loggingthe calls to add_event in the manager19:44
samueldmqnotmorgan: and even them were delayed19:44
*** roxanaghe has quit IRC19:44
samueldmqnotmorgan: maybe it's something wrong in the notification system?19:45
notmorganunlikely19:45
*** sheel has quit IRC19:45
notmorganbecause you can't return 204 unless the notification passes internally19:45
notmorganit's a blocking call19:45
notmorganthe whole delete process is a blocking call19:45
notmorganunless tempest isn't waiting for the delete to finish - which would be a bigger issue.19:46
notmorganand the SQL backends wont ACK until it's been stored19:46
*** doug-fish has joined #openstack-keystone19:46
notmorganthe other question19:46
notmorganwith https://review.openstack.org/#/c/311652/ does this continue to fail19:47
patchbotnotmorgan: patch 311652 - keystone - Replace revoke tree with linear search19:47
lbragstadwe have seen this issue with revocation events that have been sent via the notification system as well as using the revoke api directly19:47
samueldmqnotmorgan: maybe not ... this is what ayoung was talking earlier, maybe he fixed it with his refactoring ?19:47
ayoungnotmorgan, could it be a cache issue?19:47
lbragstadi'm not sure that https://review.openstack.org/#/c/311652/ does anything with the storing of the event19:47
patchbotlbragstad: patch 311652 - keystone - Replace revoke tree with linear search19:47
notmorganayoung: possibly it is also just as likely to be an issue with the whole magic bundle of things in the tree19:48
lbragstadit removes the caching though19:48
ayoungcan we just merge that, you know, because it is sane, as compared to the tree, which is clown posse levels of not sane?19:48
notmorganayoung: where the tree somewhere identifies two events to be the same when thehy aren't19:48
notmorganayoung: that patch should still cache the events coming out of the backend fwiw.19:50
notmorganjust not the whole built tree19:50
ayoungnotmorgan, I thought the backend cached it already19:50
notmorganno19:50
notmorgancaching is at the manager layer19:50
ayoungcalling through the driver does not cache?19:50
notmorganalways19:50
ayounger, manager19:50
notmorganunless you have @memoize, nope19:50
notmorganand you call self.driver.list_events()19:51
lbragstadthe @MEMOIZE decorator is removed19:51
notmorganso you're explicitly circumventing the manager19:51
notmorganand eliminating caching19:51
ayoungI don't think that is different than what was doing before, which again leads me to think it is a cache problem19:52
ayoungwe were memo-izing the tree19:53
notmorganand the tree did magic matching on events19:53
notmorganto see if they were duplicated19:53
*** tonytan4ever has joined #openstack-keystone19:53
notmorganvs a strict run through, iirc.19:53
notmorganthis new code does a strict run through the event list19:53
lbragstadthat would make sense - because the new revocation event wasn't in the tree19:54
lbragstadin the failures we've been seeing19:54
ayoungnotmorgan, OK, so need a memoize, with the cache invalidation on each revoke call again19:54
notmorganyep19:54
notmorganbasically create .list_events on the manader that just calls driver.list_events()19:54
notmorgan@memoize it19:54
notmorganand make the invalidate happen on revoke but for self.list_events19:54
notmorganinstead of self._get_revoke_tree19:55
notmorganthere is future optimizations to be done there.19:55
*** stingaci has joined #openstack-keystone19:56
*** jaosorior has quit IRC19:56
notmorganbut that is the first step in the right direction, eventually we'll just push the "is_revoked" down to the driver. and the SQL driver will lean on the RDBMS to search if the token values match.19:56
lbragstadwhen we list events in the revocation api - is it possible to index on user id or something like that?19:56
notmorganlbragstad: the next step is to not need to pull the event list into ram19:57
lbragstadnotmorgan that's pretty much what you just described ^19:57
notmorganlbragstad: but we'll need to index the columns19:57
lbragstadnotmorgan so making it so that we can ask the backend for a specific set of events19:57
lbragstadinstead of "get me all the haystacks so I can look for a one needle"19:58
notmorganpretty much don't even ask for "certain" events19:58
ayoungnotmorgan, easy enough.  Testing now19:58
notmorganjust ask RDBMS "hey does an event match any of these things?!"19:58
ayoungTypeError: No serialization handler registered for type 'RevokeEvent19:58
ayoungnotmorgan, we need to do that as JSON, right...some other patch you had?19:58
notmorganayoung: well, sortof.. we can't strictly do that because we assume everyting is datetime objects not strs19:59
notmorganayoung: and json does datetime->str19:59
*** doug-fis_ has joined #openstack-keystone20:00
ayoungdforget caching. Who needs caching?20:00
*** BjoernT has joined #openstack-keystone20:00
notmorganayoung: see https://review.openstack.org/#/c/314188/ errors20:00
patchbotnotmorgan: patch 314188 - keystone - Change to use json instead of msgpack in request_l...20:00
ayoungnotmorgan, so, back to msgpack?20:01
dolphmdstanek: you don't have a review up for your pysaml work, do you?20:01
notmorganbasically you'll need to kep w/ msgpack for now.20:01
*** doug-fi__ has joined #openstack-keystone20:01
*** josecastroleon has quit IRC20:01
*** phalmos has quit IRC20:01
*** doug-f___ has joined #openstack-keystone20:02
*** ninag has quit IRC20:03
*** phalmos has joined #openstack-keystone20:04
*** doug-fish has quit IRC20:04
notmorganayoung: i'll bet fixing http://logs.openstack.org/88/314188/1/check/gate-keystone-python27-db/b5e6607/console.html.gz#_2016-05-09_16_18_45_242 is all that is needed to make the move to json20:04
*** doug-fis_ has quit IRC20:05
*** doug-fi__ has quit IRC20:05
ayoung  File "/home/jenkins/workspace/gate-keystone-python27-db/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/timeutils.py", line 102, in normalize_time20:06
ayoung2016-05-09 16:17:44.477 |         offset = timestamp.utcoffset()20:06
ayoungoslo issue?20:06
notmorganno, we assume the thing is a DATETIME object20:06
notmorganjson serialization makes the datetime object into a string20:06
*** ninag_ has joined #openstack-keystone20:08
*** max__ has joined #openstack-keystone20:08
*** max__ is now known as Guest5328920:09
*** ninag_ has quit IRC20:09
ayoungnotmorgan, where does the fix need to go?20:09
notmorganin _is_valid i think20:10
notmorganmake sure expires is a DATETIME object20:10
notmorgan(for now) - future looking, fix keystone to not expect everything is a datetime object20:10
*** ninag has joined #openstack-keystone20:11
openstackgerritMerged openstack/keystoneauth: Updated from global requirements  https://review.openstack.org/31697820:11
samueldmqayoung: so you basically put the revocation events in a list, and see if any element in the list match with the info from the token?20:12
ayoungsamueldmq, yes20:12
samueldmqayoung: nice, and the idea is to (in the future) make the match in the database query right?20:12
ayoungsamueldmq, no.20:13
notmorgansamueldmq: yes20:13
*** ninag has quit IRC20:13
samueldmq?20:13
samueldmq:)20:13
ayoungI don't want to hit the database20:13
notmorganayoung: this should hit the database instead.20:13
notmorganit will be *WAY* faster20:13
notmorganthis is the kind of thing DBs are good at20:13
ayoungnotmorgan, hmmm20:13
notmorganbut i figured we'd iterate on that next20:14
notmorgansince it was an interface change for the driver20:14
lbragstadif it's a db read it should be pretty quick20:14
samueldmqI tend to agree with notmorgan, and the code will also be even easier to understand20:14
*** dmk0202 has joined #openstack-keystone20:14
ayounglet me mull it over20:14
samueldmqbasically, store revocations and, when a token arrives, check against the db20:14
samueldmqthat means much less logic in the managers ,etc20:15
notmorganayoung: select event from db where user_id=($USER_ID) or audit_it=($AUDIT_ID)20:15
ayoungbefore we tackle that, we should reduce the spurious events20:15
lbragstadayoung ++ agree20:15
notmorganwith a few other permutations20:15
notmorganthe way i see it is: liniar search, reduce event types, ask DB directly20:15
samueldmqI could test ayoung's patch against my tempest changes20:15
samueldmqbut looks like some people don't agree with how I am trying to reproduce the race condition20:16
samueldmq:B20:16
*** roxanaghe has joined #openstack-keystone20:16
ayoungnotmorgan, so, my gut says that, with fewer revoke events, it is not going to be worth hitting the DB.  We can try it, but I'd suspect that in process would beat out of process, especially for really short list, and mfisch's data was that, already, we don't have many revoke events20:16
*** ninag has joined #openstack-keystone20:16
mfischjust keep them in memory?20:16
mfischmemcache?20:17
notmorganayoung: i'm going to go a step further and say it will be because we don't have to do things in memory/python20:17
notmorganwhich will be slower20:17
mfischhow would you distribute them?20:17
ayoungmfisch, cached on each server20:17
mfischanyway I need to drive to the mechanic I will catch up when I get back20:17
ayoungchanges still write trhough to the datqabase20:17
ayoungbut...then we have the issue of cache revocation20:17
notmorganbeing able to ask quickly on an indexed table if a token is valid is going to win over caching in most cases.20:18
ayoungnotmorgan, I'm wondering then if we should do that now20:18
notmorganayoung: we could, it's a lot more work with the volume of types we have20:18
samueldmqayoung: you addressing morgan's comment on patch 311652 already?20:18
patchbotsamueldmq: https://review.openstack.org/#/c/311652/ - keystone - Replace revoke tree with linear search20:18
lbragstadayoung testing your patch with http://cdn.pasteraw.com/enp4yjepsw08lgf5kzfuq5zg0qteyl6 locally20:18
notmorganand i wasn't sure we'd land it in newton.20:18
ayoungbut it would be a pain with the larger set of events20:18
ayounglbragstad, cool20:19
samueldmqayoung: I will take a look at it now too ... let's get that merged and see if it makes things easier20:19
lbragstadsamueldmq ayoung http://cdn.pasteraw.com/enp4yjepsw08lgf5kzfuq5zg0qteyl6 is addresses some of notmorgan's comments20:19
notmorganayoung: i mean, i already know what the SQL driver ends up looking like. it's just a bunch of filter ors for the different columns20:19
ayounglbragstad, necessary but not sufficient20:19
samueldmqlbragstad: could you post it as a new patchset?20:20
notmorganand if anyone column matches - AND the rev. time matches, boom20:20
ayoung I also need to code I wriopped out of _cointexct_cache but modified for the events instead of the map20:20
lbragstadsamueldmq i think ayoung has some changes locally too - i don't want to stomp on them20:20
ayounglbragstad, samueldmq yeah, don't post.  I'm working on it20:20
*** ninag has quit IRC20:20
*** josecastroleon has joined #openstack-keystone20:20
notmorganbut basically we could just *delete* the revoke model.20:20
*** rderose has quit IRC20:21
notmorganand lean on SQL.20:21
notmorganrequires a migration to index the table20:21
*** ninag has joined #openstack-keystone20:21
lbragstadnotmorgan that would make sense if we didn't have many revocation cases20:21
lbragstadi.e. once we remove all the extra events we get for free from the fernet format20:21
notmorganlbragstad: pretty easy to do even now.20:21
notmorganlbragstad: just would rather make the .is_revoked() change be smarter20:22
notmorganand just ask for the values it needs rather than **kwargs20:22
notmorganand two interface changes is ickier than 120:22
ayoungOK, think I've got it.20:22
dstanekdolphm: no, but i can pretty soon20:23
openstackgerritayoung proposed openstack/keystone: Replace revoke tree with linear search  https://review.openstack.org/31165220:24
lbragstaddstanek o/20:24
*** rderose has joined #openstack-keystone20:24
ayoungstill a net reduction in code20:24
notmorganyeh20:25
ayoungnotmorgan, so....if we don't do the "reduce spuriours revoke events"  it might actually be faster20:26
ayoungwe'll have more events, but we won't rebuild the token ever time, and just read them from cache20:26
lbragstaddstanek we're all iterating on https://review.openstack.org/#/c/311652/1020:26
patchbotlbragstad: patch 311652 - keystone - Replace revoke tree with linear search20:26
ayoungif possilble20:26
* notmorgan taps foot waiting for inspection folks to arrive.20:27
dstaneklbragstad: to figure out the bug?20:28
notmorganoh. well crap they are doing the inspection between 2 and 5pm... damn it. means i screwed up my lunch plans :(20:28
lbragstaddstanek I think we've narrowed it down to a revocation event cache bug20:28
dstaneklbragstad: neato20:29
*** ninag has quit IRC20:29
*** doug-f___ has quit IRC20:29
*** rbridgeman has quit IRC20:29
*** iurygregory has quit IRC20:30
*** ericksonsantos has quit IRC20:30
*** clenimar has quit IRC20:30
*** pauloewerton has quit IRC20:30
*** doug-fish has joined #openstack-keystone20:31
notmorganlbragstad: i think it's not even cache20:31
*** Guest53289 has quit IRC20:31
notmorganlbragstad: i think it's the .add_event logic mis-matching duplicated events20:32
notmorgan(.add_event on the tree)20:32
notmorgannot ... yah anyway20:32
*** clenimar has joined #openstack-keystone20:32
*** raildo is now known as raildo-afk20:33
*** raildo-afk is now known as raildo20:33
*** iurygregory has joined #openstack-keystone20:34
*** ericksonsantos has joined #openstack-keystone20:34
*** pauloewerton has joined #openstack-keystone20:34
lbragstadnotmorgan oh - here? https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L14220:34
knikollado we want separate devstack plugins for the k2k idp and k2k sp? or only one and have  a bool value to distinguish which is which?20:36
notmorganlbragstad: i think so.20:37
*** sdake has quit IRC20:37
*** sdake has joined #openstack-keystone20:37
notmorganlbragstad: or somewhere in the tree logic itself.20:37
samueldmqnotmorgan: hmm, if that's the case, ayoung patch will fix it20:38
*** rbridgeman has joined #openstack-keystone20:38
*** pauloewerton has quit IRC20:41
*** ericksonsantos has quit IRC20:41
*** pauloewerton has joined #openstack-keystone20:42
*** ericksonsantos has joined #openstack-keystone20:42
*** ninag has joined #openstack-keystone20:46
*** ninag has quit IRC20:46
*** ninag has joined #openstack-keystone20:47
*** tonytan4ever has quit IRC20:47
*** tonytan4ever has joined #openstack-keystone20:47
*** jorge_munoz has quit IRC20:48
*** roxanaghe has quit IRC20:49
*** josecastroleon has quit IRC20:50
*** CIA has quit IRC20:51
*** fangxu has quit IRC20:51
*** ninag has quit IRC20:51
*** doug-fis_ has joined #openstack-keystone20:51
*** stingaci has quit IRC20:52
*** josecastroleon has joined #openstack-keystone20:52
*** doug-fish has quit IRC20:54
samueldmqayoung: you still around ?20:55
ayoungsamueldmq, would you believe me if I said "no?"20:55
samueldmqayoung: I just have two comments I need to confirm they're valid in patch 31165220:55
patchbotsamueldmq: https://review.openstack.org/#/c/311652/ - keystone - Replace revoke tree with linear search20:55
*** julim has quit IRC20:55
samueldmqayoung: maybe, cuz you're ayoung :-)20:55
samueldmqayoung: it's looking pretty good imo20:56
ayoungsamueldmq, so I hate comments20:56
ayoungI think we spend way too much time quibbling over comments, and in doing so break the flow20:56
ayoungso, to your second question, no, I won;'t put a comment there20:56
ayoung"I assume all these attributes are mandatory in the token data. Is this right?"  Yep20:56
ayoungsamueldmq, :)20:57
samueldmqayoung: you added comments everywhere else lol20:57
ayoungsamueldmq, all of the rules are "fall through"20:57
ayoungand the return false20:57
ayoungis the way of short circuiting the logic.20:58
samueldmqayoung: I could understand it, looks clear as it is20:58
ayoungthe fact that the date comes at the end is not really relevant, no specific order in thei code.  In the Tree code, it was important that it be last20:58
*** chrisshattuck has joined #openstack-keystone20:58
samueldmqayoung: ah, got it21:00
*** anush has joined #openstack-keystone21:01
samueldmqayoung: how are events removed from that list?21:02
ayoungsamueldmq, they aren't21:02
samueldmqayoung: never ? wow21:02
ayoungsamueldmq, the query just returns all that are relevant21:02
notmorganon new event being issued old events are pruned from the db21:03
samueldmqayoung: ah ok so the manager only gets relevant data21:03
ayoungoh, right, that21:03
notmorgans/old/expired21:03
samueldmqnotmorgan: nice21:03
samueldmqayoung: notmorgan: I am a +2 on that, looking good enough for me21:03
ayounglets see if it passes tempest etc with the caching turned on before we get too optimisitc21:04
samueldmqI don't see a reason it wouldn't pass because of that caching, since it's how we do it everywhere else21:04
samueldmqbut ok21:05
ayoungsamueldmq, feel free to +2 it.  It won't go in if it fails tests anyway21:05
samueldmqayoung: again?21:06
samueldmq:)21:06
*** roxanaghe has joined #openstack-keystone21:09
*** haplo37 has quit IRC21:11
samueldmqayoung: TypeError: can't compare datetime.datetime to str21:12
samueldmqayoung: http://logs.openstack.org/52/311652/10/check/gate-keystone-python27-db/01f7702/console.html#_2016-05-16_21_00_10_78821:12
*** doug-fis_ has quit IRC21:17
*** doug-fish has joined #openstack-keystone21:18
*** fangxu has joined #openstack-keystone21:21
*** josecastroleon has quit IRC21:22
*** doug-fish has quit IRC21:22
*** raildo is now known as raildo-afk21:22
ayoungsamueldmq, OK, I think I have that.  Running unit tests now21:23
*** stingaci has joined #openstack-keystone21:24
*** doug-fish has joined #openstack-keystone21:25
*** doug-fish has quit IRC21:26
*** doug-fish has joined #openstack-keystone21:27
*** doug-fish has quit IRC21:32
*** doug-fish has joined #openstack-keystone21:33
*** doug-fish has quit IRC21:37
*** doug-fish has joined #openstack-keystone21:38
*** doug-fish has quit IRC21:38
*** doug-fish has joined #openstack-keystone21:38
*** josecastroleon has joined #openstack-keystone21:42
*** spzala has quit IRC21:46
*** roxanaghe has quit IRC21:51
openstackgerritDolph Mathews proposed openstack/keystonemiddleware: Fix D202: No blank lines allowed after function docstring (PEP257)  https://review.openstack.org/31710221:52
notmorganlbragstad: https://review.openstack.org/#/c/311886/5 is incorrect btw21:53
patchbotnotmorgan: patch 311886 - keystone - Fix fernet audit ids for v2.0 (MERGED)21:53
*** pauloewerton has quit IRC21:54
notmorganlbragstad: basically you end up with a non-unique set of audit ids on rescope in v221:54
notmorganstevemar: ^ cc21:54
*** phalmos has quit IRC21:54
notmorgancc dolphm ^21:55
notmorganlbragstad: i'm worried you totally fixed the wrong thing.21:56
openstackgerritDolph Mathews proposed openstack/keystonemiddleware: Fix D200: One-line docstring should fit on one line with quotes (PEP257)  https://review.openstack.org/31710321:56
*** roxanaghe has joined #openstack-keystone21:57
*** markvoelker has joined #openstack-keystone21:57
*** edmondsw has quit IRC21:58
*** edtubill has quit IRC21:58
*** rderose has quit IRC22:00
lbragstadnotmorgan what happened?22:00
notmorganlbragstad: basically you fixed the issue by maintaining the same audit ids across rescopes22:01
*** markvoelker has quit IRC22:01
notmorganlbragstad: which is incorrect.22:01
*** tonytan4ever has quit IRC22:01
notmorgant leas that is what it looks like22:01
*** markvoelker has joined #openstack-keystone22:01
notmorganthe main audit_id should be unique per token.22:01
notmorganthe parent id stays the same or is empty22:01
notmorganlbragstad: at least that is what it looks like is happening now.22:02
notmorganthis is a problem with the split code paths, it's *really* hard to be sure we don't mess one of these up22:03
lbragstadnotmorgan isn't that what these tested?22:04
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_auth.py#L52422:04
notmorganlbragstad: should be, but as you know fernet is only partially tested22:04
*** anush has quit IRC22:04
lbragstadnotmorgan I inherited that class and ran it with fernet https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_auth.py#L67522:05
*** timcline_ has quit IRC22:06
*** doug-fish has quit IRC22:07
*** sigmavirus24 is now known as sigmavirus24_awa22:09
*** rderose has joined #openstack-keystone22:10
notmorganlbragstad: hmm/22:10
*** dmk0202 has quit IRC22:10
notmorganlbragstad: something still looks really wrong here.22:10
*** josecastroleon has quit IRC22:12
openstackgerritDolph Mathews proposed openstack/keystonemiddleware: Fix D105: Missing docstring in magic method (PEP257)  https://review.openstack.org/31711022:12
*** doug-fis_ has joined #openstack-keystone22:13
lbragstadnotmorgan http://cdn.pasteraw.com/gbofv598z0penydq22js3wx52f8mwtf22:14
lbragstad^ inspecting the audit ids in that test22:14
lbragstadwith fernet22:14
*** doug-fi__ has joined #openstack-keystone22:16
notmorganlbragstad: does this not impact liberty or kilo?22:17
*** doug-fis_ has quit IRC22:18
lbragstadnotmorgan i'd have to check but liberty and kilo didn't have the consolidation of the code path22:19
notmorganok22:19
ayoungnotmorgan, we got rid of "revoked_at" didn't we?22:19
lbragstadnotmorgan this was the piece that was broken https://github.com/openstack/keystone/blob/996b0c7e1019235d384648f74de24542b0a736d7/keystone/token/providers/fernet/core.py#L159-L17222:20
*** diazjf has quit IRC22:20
notmorganayoung: uh22:20
lbragstadnotmorgan which is something we did as a hook to get data from the request in order to create the token22:20
notmorganayoung: don't think os?22:20
*** ninag has joined #openstack-keystone22:20
lbragstadayoung on the revocation event?22:20
notmorganlbragstad: yeah22:20
lbragstadno - revoked_at should still be there22:21
lbragstada revocation event has three datetime entries22:21
lbragstadissued_before, revoked_at, and expires_at22:21
*** doug-fi__ has quit IRC22:21
lbragstador at least it did the last time I checked22:21
*** edtubill has joined #openstack-keystone22:22
*** ninag_ has joined #openstack-keystone22:22
notmorganissued_before was the important one22:22
notmorganrevoked_at was important for (i think) expiring the event?22:22
lbragstadyeah - that's what we use in the comparison22:22
lbragstadwe compare the token's issued_at time to the revocation events issued_before time22:23
notmorganlbragstad: also did this bad audit_id just mean we didn't maintain the parent_audit_id? or did we fail to rescope the token? or ...22:23
notmorganlbragstad: or we just couldn't revoke the entire chain?22:23
notmorganit *looks* like we still put an audit_id into the token22:24
lbragstadnotmorgan yes - i believe the issue was that we didn't carry over the audit id from the parent token when rescoping the token22:24
notmorganok so we just couldn't revoke the chain22:24
notmorganwhihc... i don't think we every actually use in keystone22:24
lbragstadso when you got an unscoped token you'd get ['<audit_id>']22:24
notmorganyeah ok22:24
notmorganthat is not the worst thing.22:25
*** ninag has quit IRC22:25
lbragstadand then when you rescoped you'd get ['<new_audit_id>', '<newer_audit_id>']22:25
notmorganthats still fine22:25
notmorganbecause revoke by audit_id would still work22:25
notmorganjust can't revoke by chain22:25
lbragstadright22:26
lbragstadthat makes sense22:26
*** ninag_ has quit IRC22:26
ayoungso the to_dict() function was not ever setting the revoked_at value22:27
lbragstadnice22:28
lbragstad"this is not the revoked_at you're looking for"22:28
ayoungsee http://git.openstack.org/cgit/openstack/keystone/tree/keystone/models/revoke_model.py#n9722:28
ayoungand...22:28
ayoungdoes anything else check that?  It is not in the tree, I think22:28
ayoungyeah, that is what we use to prune22:30
ayoungguessing pruning is broke22:30
lbragstadlol22:30
ayoungso that means I have a few more unit tests to fix, too22:31
ayounglbragstad, but that is not supposed to be a nullable column22:31
ayoungshould have blown up all over the place22:31
ayoungMaybe to_dict was not used22:32
lbragstadayoung revoked_at isn't suppose to be a nullable column?22:33
notmorganayoung: it was not used in the tree afaik22:34
ayoungjust for cleanup22:34
*** ninag has joined #openstack-keystone22:34
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/revoke/backends/sql.py#n3422:35
lbragstadah22:36
lbragstadayoung I assume issued_before is nullable since it is conditional depending on the revocation event?22:36
lbragstador is issued_before something that should always be set?22:36
ayounglbragstad, no idea.  Brain now fried from revokcatiojanjiasd22:38
lbragstadayoung i know right?22:38
*** ninag has quit IRC22:39
lbragstadstaring at that code last week made me question my life choices22:39
*** ninag has joined #openstack-keystone22:40
*** doug-fish has joined #openstack-keystone22:40
lbragstadayoung if i remember right - the revoke model populated both the revoked_at and issued_before fields22:41
*** ametts has quit IRC22:41
lbragstadayoung actually - not revoked_at just expires22:41
lbragstadhttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/models/revoke_model.py#n11422:41
edtubillHi, I was just wondering if anyone here knew off the bat if horizon sends a request to keystone to invalidate a token when a user logs out?22:43
david-lyleedtubill: on logout, yes22:44
notmorganedtubill: what david-lyle said22:44
*** doug-fish has quit IRC22:44
notmorganedtubill: he'd know.22:44
*** ninag has quit IRC22:44
edtubilldavid-lyle: thx!22:44
*** rderose has quit IRC22:45
*** pushkaru has quit IRC22:46
*** tmcpeak has joined #openstack-keystone22:51
tmcpeako/ edtubill22:51
edtubilltmcpeak: hey, so I'm trying to figure out if https://wiki.openstack.org/wiki/OSSN/OSSN-0017 is still valid.22:53
tmcpeakso in the note it says: "It should be noted that Horizon does request that Keystone invalidate the token upon user logout, but this has not been implemented for the Identity API v3. Token invalidation may also fail if the Keystone service is unavailable."22:54
tmcpeakbut if an attacker is able to copy the token, either via MITM or local access, I still don't see how the server can tell whether it's valid or not without maintaining some state on the server side22:55
*** BjoernT has quit IRC22:56
tmcpeakthe problem seems to be that without a way to revoke tokens server side there is no way to guarantee a token is revoked22:57
edtubilltmcpeak: wouldn't keystone store if a token is valid or not? But I guess if keystone is unreachable for a few seconds and the user logs out, the attacker could use the token because it wasn't invalidated?22:57
tmcpeakok yeah, I'm trying to untangle what of this is a Horizon behavior and what's Keystone22:58
tmcpeakso Keystone is going to maintain a token independent of Horizon22:58
tmcpeakKeystone tokens can be revoked22:59
tmcpeakso the note says that token invalidation on user logout hasn't been implemented in Identity V3 API22:59
tmcpeakI guess we need to confirm if it was implemented sometime between Juno-Mitaka22:59
tmcpeakthere is this: http://developer.openstack.org/api-ref-identity-v3.html#revokeTokens23:01
*** doug-fish has joined #openstack-keystone23:02
*** lhcheng has quit IRC23:02
*** lhcheng has joined #openstack-keystone23:02
*** ChanServ sets mode: +v lhcheng23:02
tmcpeakif Horizon is calling that it might work… Keystone experts, any thoughts?23:02
david-lylesupport for v3 token revoke in horizon was added in 201423:02
david-lylehttps://github.com/openstack/django_openstack_auth/commit/cad8def073222618857bebf9a18bb4d8dd098bfc23:02
david-lyleDec 201423:03
*** pushkaru has joined #openstack-keystone23:03
david-lyleversion 1.1.9 of django_openstack_auth and forward23:03
david-lylehttps://bugs.launchpad.net/django-openstack-auth/+bug/1331978 is the closed bug link23:05
openstackLaunchpad bug 1331978 in django-openstack-auth "Revoke v3 token on logout" [Medium,Fix released] - Assigned to Lin Hua Cheng (lin-hua-cheng)23:05
tmcpeakdavid-lyle: ok awesome, thank you!23:05
*** markvoelker has quit IRC23:06
edtubilldavid-lyle: yes thx again!23:06
david-lyleno problem, hope that helps23:07
*** rcernin has quit IRC23:08
*** pushkaru has quit IRC23:10
*** gordc has quit IRC23:16
*** edtubill has quit IRC23:22
*** edtubill has joined #openstack-keystone23:25
*** tqtran has quit IRC23:26
*** ninag has joined #openstack-keystone23:30
*** edtubill has quit IRC23:31
*** ninag has quit IRC23:35
*** roxanaghe has quit IRC23:39
*** spandhe has joined #openstack-keystone23:41
*** jamielennox is now known as jamielennox|away23:51
*** rdo has quit IRC23:53

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