Tuesday, 2017-09-26

*** itlinux has quit IRC00:08
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000500:19
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013700:27
*** Shunli has joined #openstack-keystone00:31
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000500:35
*** zhurong has joined #openstack-keystone00:41
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013700:43
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000501:00
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013701:08
*** aselius has quit IRC01:14
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000501:16
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013701:24
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000502:30
*** jamesbenson has joined #openstack-keystone02:31
*** jamesbenson has quit IRC02:35
*** aojea has joined #openstack-keystone02:37
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013702:38
*** aojea has quit IRC02:42
*** erlon has quit IRC02:46
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000502:50
*** thorst has quit IRC02:51
*** thorst has joined #openstack-keystone02:51
*** Dinesh_Bhor has joined #openstack-keystone02:54
*** thorst has quit IRC02:56
*** Dinesh_Bhor has quit IRC02:57
openstackgerritMerged openstack/keystonemiddleware master: Fix gate error caused by mocked URLs  https://review.openstack.org/50448702:57
*** Dinesh_Bhor has joined #openstack-keystone02:57
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013702:58
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000503:06
*** dave-mcc_ has quit IRC03:09
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013703:14
*** itlinux has joined #openstack-keystone03:19
*** itlinux has quit IRC03:22
*** itlinux has joined #openstack-keystone03:23
*** Dinesh_Bhor has quit IRC03:24
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000503:27
*** Dinesh_Bhor has joined #openstack-keystone03:28
*** Dinesh_Bhor has quit IRC03:34
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013703:35
*** itlinux has quit IRC03:35
*** itlinux has joined #openstack-keystone03:37
*** Dinesh_Bhor has joined #openstack-keystone03:46
*** thorst has joined #openstack-keystone03:53
*** itlinux has quit IRC04:00
*** mtreinish has quit IRC04:24
*** cfriesen has quit IRC04:25
*** cfriesen_ has joined #openstack-keystone04:25
*** mtreinish has joined #openstack-keystone04:34
*** nkinder has quit IRC05:17
*** aojea has joined #openstack-keystone05:43
*** cfriesen_ has quit IRC06:02
*** thorst has quit IRC06:03
*** jamesbenson has joined #openstack-keystone06:07
*** jamesbenson has quit IRC06:11
*** jaosorior has quit IRC06:12
*** pcaruana has joined #openstack-keystone06:20
*** zhurong has quit IRC06:22
*** jaosorior has joined #openstack-keystone06:35
*** rcernin has joined #openstack-keystone06:47
*** thorst has joined #openstack-keystone06:59
*** belmoreira has joined #openstack-keystone07:11
*** tesseract has joined #openstack-keystone07:14
*** belmoreira has quit IRC07:19
*** ioggstream has joined #openstack-keystone07:19
*** belmoreira has joined #openstack-keystone07:26
*** belmoreira has quit IRC07:29
*** belmoreira has joined #openstack-keystone07:45
*** belmoreira has quit IRC07:59
*** aloga has quit IRC08:04
*** aloga has joined #openstack-keystone08:04
*** markvoelker has quit IRC08:06
*** zhurong has joined #openstack-keystone08:20
*** mvk has quit IRC08:26
*** Shunli has quit IRC08:27
*** Shunli has joined #openstack-keystone08:28
*** belmoreira has joined #openstack-keystone08:29
*** belmoreira has quit IRC08:30
*** mvk has joined #openstack-keystone08:54
*** belmoreira has joined #openstack-keystone08:59
*** aojea_ has joined #openstack-keystone09:02
*** aojea has quit IRC09:05
*** belmoreira has quit IRC09:12
*** mvk has quit IRC09:15
*** shengping has joined #openstack-keystone09:19
*** shengping has quit IRC09:20
*** shengping has joined #openstack-keystone09:21
*** mvk has joined #openstack-keystone09:28
*** Shunli has quit IRC09:31
*** shengping has quit IRC09:35
*** jamesbenson has joined #openstack-keystone09:43
*** jamesbenson has quit IRC09:48
*** zhurong has quit IRC09:52
*** markvoelker has joined #openstack-keystone10:07
*** breton has quit IRC10:10
*** breton has joined #openstack-keystone10:11
*** zhurong has joined #openstack-keystone10:35
*** markvoelker has quit IRC10:41
*** nicolasbock has joined #openstack-keystone11:07
*** thorst has quit IRC11:31
*** zhurong has quit IRC11:35
*** zhurong has joined #openstack-keystone11:39
*** markvoelker has joined #openstack-keystone11:39
*** ioggstream has quit IRC11:39
*** nkinder has joined #openstack-keystone12:03
*** dave-mccowan has joined #openstack-keystone12:07
*** nkinder has quit IRC12:09
*** dave-mcc_ has joined #openstack-keystone12:10
*** thorst has joined #openstack-keystone12:11
*** dave-mccowan has quit IRC12:12
*** markvoelker has quit IRC12:12
*** edmondsw has joined #openstack-keystone12:14
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000512:24
*** raildo has joined #openstack-keystone12:28
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013712:32
*** markvoelker has joined #openstack-keystone12:32
*** shewless has joined #openstack-keystone12:36
shewlessHello.  I'm trying to improve the performance of interacting with the openstack APIs.  For example I notice when I do a "openstack stack list" it takes 10 seconds to return12:37
shewlessMust of this time is spend in keystone12:37
shewlesswith fernet token auth "openstack stack list" takes 10 seconds12:37
shewlesswith user/pass auth (ldap) the same command takes 5 seconds12:37
shewlessI would have thought fernet tokens would have been faster12:37
shewlessfirst: even 5 seconds is too long. any recommendations on how I can make this subsecond?12:37
shewlesssecond: any hints to make fernet faster? I can play with lowering crypt_strength in keystone.conf perhaps..12:38
*** ioggstream has joined #openstack-keystone12:39
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000512:40
*** zhurong has quit IRC12:46
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013712:47
*** panbalag has joined #openstack-keystone12:50
*** panbalag has left #openstack-keystone12:50
*** panbalag has joined #openstack-keystone12:50
*** erlon has joined #openstack-keystone12:57
*** Dinesh_Bhor has quit IRC12:59
*** lucasxu has joined #openstack-keystone13:07
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000513:08
*** Dinesh_Bhor has joined #openstack-keystone13:08
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013713:16
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000513:24
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013713:32
openstackgerritDavanum Srinivas (dims) proposed openstack/oslo.policy master: http/https check rules as stevedore extensions  https://review.openstack.org/50709813:39
*** cfriesen_ has joined #openstack-keystone13:53
*** belmoreira has joined #openstack-keystone13:55
*** belmoreira has quit IRC14:01
*** belmoreira has joined #openstack-keystone14:04
*** raildo has quit IRC14:06
knikollao/14:09
*** raildo has joined #openstack-keystone14:09
*** jamesbenson has joined #openstack-keystone14:25
*** belmoreira has quit IRC14:28
*** lucasxu has quit IRC14:30
*** lbragstad has quit IRC14:44
*** lbragstad has joined #openstack-keystone14:54
*** ChanServ sets mode: +o lbragstad14:54
lbragstadshewless: crypt_strength will certainly haven an impact on performance, but that would be independent of the token provider14:55
lbragstadshewless: what does your caching configuration look like?14:55
*** gyee has joined #openstack-keystone14:57
*** gyee has quit IRC14:58
*** gyee has joined #openstack-keystone14:58
samueldmqo/15:12
*** lucasxu has joined #openstack-keystone15:13
lbragstadmorning!15:13
*** jamesbenson has quit IRC15:14
*** Suramya__ has joined #openstack-keystone15:15
*** jamesbenson has joined #openstack-keystone15:15
gagehugoo/15:15
samueldmqlbragstad: Suramya__ : hey ! o/15:15
samueldmqlbragstad: so... Suramya__ is interested to work with us during next Outreachy internship15:16
samueldmqfor documentation15:16
samueldmqshe even went ahead and submitted a first patch https://review.openstack.org/#/c/505135/15:16
samueldmqwhich is great :)15:16
lbragstadSuramya__: o/ welcome!15:16
kmalloclbragstad: o/15:17
lbragstadkmalloc: o/15:17
lbragstadgagehugo: o/15:17
gagehugowelcome Suramya__ o/15:17
samueldmqlbragstad: Suramya__: just quick introductions :-) I have to go now, have a talk in 10 minutes15:17
kmalloclbragstad: and expect bcrypt to be slower than sha512_crypt.15:17
kmallocshewless: ^cc15:17
kmallocif you're using pike15:17
Suramya__hello everyone :).I am a potential outreachy applicant for this round interested to contribute to keystone project for documentation.I am in final year and will be available full time after dec. to work on the project :)15:20
shewless@lbragstad: do you mean the "memcached" section?15:21
shewless@lbragstad: I'm using fernet tokens.. would 1000 be noticably faster than 10000?  Also I would like to ensure I have caching enabled and optimized but I'm not sure how to do that15:22
lbragstadshewless: 1000 or 10000 users? projects?15:23
shewless@lbragstad: I meant the crypt_strength value15:23
lbragstadoh - yes, i would expect that to make a signifiant difference, but kmalloc is more familiar with the different hashing algorithms and the impact of performance with respect to rounds15:23
kmallocshewless: what release of openstack are you using?15:24
shewless@lbragstad, kmalloc: mitaka15:24
lbragstad(i believe he did document some of that in the configuration options when we updated keystone to support better hashing techniques)15:24
kmallocok, then my advice for a lot of advanced tuning isn't useful15:24
shewlesskmalloc: doh15:24
kmallocsince i've been focused on bcrypt,scrypt, and pbkdf2 (changes that came in pike and have more performance impact than the algo used in mitaka and before, possibly much slower)15:25
shewlessin keystone.conf I have my memcache servers set.. but the rest of the config is default15:25
kmallocshewless: the default hashing rounds (crypt_strength) should be mostly ok for almost any environment in mitaka15:25
shewlesskmalloc: it it common that fernet token auth would take twice as long as ldap auth?15:26
shewlessalso, I'm running a private cloud and I can sacrifice some security for performance15:26
kmallocthat seems like something weird is going on15:27
kmalloclbragstad: didn't we have some massive performance fixes in newton and ocata?15:27
kmalloclbragstad: for fernet15:27
lbragstadshewless: yes15:27
lbragstadkmalloc: yes15:27
kmallocthats what i thought15:27
lbragstadshewless: if you switch to uuid tokens, do you see the same performance footpritn?15:28
lbragstadfootprint*15:28
shewless@lbragstad: I haven't tried that. are uuid tokens stored in the database?15:28
lbragstadshewless: yes15:28
lbragstadshewless: it would point out if the performance impact you're seeing is directly associated to fernet tokens or not15:29
lbragstadif not - then tinkering with crypt strength might be more useful, if it is attributable to fernet tokens, we need to look at caching15:29
shewless@lbragstad: can we look at caching now? Do you mean the [cache] section in keystone.conf?15:30
kmallocshewless: ok so caching can help a lot15:30
kmallocyou'll also want to make sure caching is enabled for the other services [nova, neutron, etc] in the authtoken config15:30
lbragstad++15:30
kmallocand typically you'll want to make sure the non-keystone services share a memcache pool15:31
lbragstadyou need to make sure caching is configured is a few different areas15:31
kmalloc[same memcache servers] as caching the token in nova will impact glance that way15:31
lbragstadkeystone implements caching on a per-subsystem basis15:31
kmallockeystone always uses it's own hash-key for caching, so.... you benefit only in keystone for that15:31
shewlessokay. I do have my services sharing a memcache pool.15:31
kmallocshewless: good!15:31
lbragstad(e.g. you can turn caching on for users and tokens but leave caching of catalogs off)15:31
kmalloclbragstad: by default if you turn on caching in keystone, you get it for everything15:32
kmallocthankfully.15:32
shewlesshow do I turn on caching in keystone?15:32
lbragstadkmalloc: yep15:32
shewlessin the [cache] section?15:32
kmallocshewless: in the [cache] section i think.15:32
lbragstadshewless: look in the [cache] section15:32
* lbragstad finds a link15:32
* kmalloc admits it has been a while since configuring this15:32
shewlessokay.. the "enabled = false" section I assume has to be changed :)15:32
kmalloclbragstad: can we talk about making memcache a hard-requirement (or at least some-kind-of-caching) sometime soon (like... Rocky?)15:32
kmallocshewless: yep15:33
kmallocenabled = True15:33
shewlessand then I can set the memcache_servers in the [cache] section as well15:33
kmallocif you have the memcache servers configured, it should be significantly faster.15:33
kmallocyeah.15:33
kmallochm. hold on15:33
kmalloclets make sure that is right15:33
shewlesssure.15:33
shewlessto clarify in keystone.conf there is a [memcache] section where I have my servers = set to my memcache servers15:34
lbragstadhttps://github.com/openstack/keystone/blob/fdb6adf055d72db17be76bd59a71e159116f3b96/etc/keystone.conf.sample#L518]15:34
lbragstadhttps://github.com/openstack/keystone/blob/fdb6adf055d72db17be76bd59a71e159116f3b96/etc/keystone.conf.sample#L51815:34
shewlessbut I don't have anything set in the [cache] section15:34
kmallochttps://www.irccloud.com/pastebin/vqTxGxrs/15:34
kmallocthe memcache section is old15:34
kmallocand it really shouldn't be used.15:34
kmallocyou *can* use it, but it is there for backwards compat only15:34
shewlesseven on mitaka?15:35
kmallocsince we moved to dogpile.15:35
kmallocwhich was... icehouse?15:35
kmallocor juno, or kilo or something15:35
kmallocit's been quite a while15:35
kmallocif you were running something old enough that required the [memcache] section, you couldn't cache user data, etc15:36
shewlessokay cool. So I just need to focus on configuring the [cache] section and I should see amazing stuff happen!15:36
kmallocthat is our general plan15:36
kmallocsince you're using LDAP auth --- here is a warning**15:36
lbragstadunicorns and rainbows around!15:36
kmallocThe cache will not reflect (assuming read only ldap) user changes15:36
*** Suramya__ has quit IRC15:36
shewlessmaybe getting ahead of myself here... but do I need to change my nova, neutron configs?15:36
shewlesskmalloc: what is a "user change" i nthis context?15:37
kmallocif you change it. i tmight lag by ~5m or so15:37
kmallocupdate any user data15:37
kmallocif ldap is read-only, since keystone doens't manage it15:37
kmallocit can't invalidate on user changes15:37
kmallocso the cache will potentially persist for _cache_ttl_ [not the option] before the change is reflected15:38
kmallocwe can work on nova/neutron/cinder/etc once keystone is happily caching15:38
shewlesskmalloc: okay that's probably not a big deal15:38
kmallocit usually isn't15:38
kmallocbut just be aware15:38
kmallocit's the typical cache caveat for non-managed data within an app.15:39
kmalloc:)15:39
shewlesskmalloc: give me a moment and I'll try that keystone change. Do I need to set the memcache_servers variable in the [cache] section?15:39
kmalloclet me confirm the change is correct for mitaka15:39
kmallocsec15:39
shewlesskmalloc: thanks the default args I see are different from the snippet I think15:39
kmallocok mitaka uses oslo_cache15:40
kmallocso the snippet should be correct.15:40
kmallocyou'll need to change the "backend_argumenbt" to reflect your memcache server(s)15:40
kmallocif you want15:41
kmallocyou can use memcache_servers15:41
kmallocthere too it looks like.15:41
kmallocso15:41
kmallochttps://www.irccloud.com/pastebin/CJTO72Vz/15:42
kmallocalso, are you running keystone in mod_wsgi? or something else?15:42
shewlessmod_wsgi15:42
kmallocok15:43
kmalloccool15:43
kmallocyou're 100% fine then, no other tweaks really needed15:43
shewlessso.. don't set memcache_servers at all in [cache]?15:44
kmallocyou *can*15:44
shewlessalso.. the backend_argument url.. shoudl that be localhost or my memcached servers?15:44
kmallocuse memcache_servers, sorry we have it for compat and i gave bad advice15:44
kmallocit's easier to use than backend_url15:44
kmallocsee my second snippet, and use your memcache server15:45
kmallocnot localhost15:45
kmallocor 127.0.0.115:45
shewlessI only see 1 snippet15:45
kmallochttps://www.irccloud.com/pastebin/CJTO72Vz/15:46
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/50000515:47
kmallocthe reason is you can use list args. backend_arg is ... mostly so you can pass things to say REDIS instead of memcache backends15:47
shewlesskmalloc: cool. Let me try this15:47
kmallocif you only have a single memcache, obviously you wont have multiple servers in the list15:48
shewlesskmalloc: yes I only have a single one ATM.. Okay I tried the change, restarted apache, and am running my "openstack stack list" as a test. so far I don't see the improvement15:49
shewlesshmm.. actually I think it shaved about 3 seconds total off of my 10 second request (for the token case)15:50
kmallocthat is a big improvement15:50
shewlessyup15:50
kmallocalso you're hitting non-keystone things15:50
shewlessand I think "heat" is a slightly bigger contributor now.. hard to tell for sure though15:50
kmallocyeah heat is probably most of that now15:51
kmallocbut we can make sure you're caching keystone things (tokens) in heat, nova, etc as well15:51
kmallocok so in heat/nova/neutron/cinder/etc configs, where auth_token is configured15:53
kmallocadd memcache_servers=<memcache>15:55
kmallocand you should see benefits (make sure the memcache is shared between non-keystone services)15:56
kmallocand the order of servers in tha tlist is the same15:56
kmallocthat should help w/ non-keystone services15:56
shewlesskmalloc: hmm. so in heat.conf I have memcache_servers already set15:57
shewlessin this section: rom keystonemiddleware.auth_token15:58
kmallocyeah15:58
kmallocthen you should already be benefitting there15:59
kmallocit just forces caching of the keystone tokens for ~5m15:59
kmallocsaves extra round-trips to keystone, and it adds up15:59
*** sbezverk has quit IRC16:00
shewlesskmalloc: thanks for the help so far. My "openstack stack list" takes about 7 seconds now for token. I'll try ldap now.. I bet it's faster..  Is there anything else I can do to speed it up before I through another curve ball at you?16:00
kmallocupgrade to newton16:01
kmallocor ocata16:01
* kmalloc is serious16:01
*** jistr is now known as jistr|mtg16:01
kmallocthere are some large speed improvements for keystone around fernet16:01
shewlesskmalloc: working on it..16:01
kmalloci recommend ocata,16:01
shewlessokay.. so ldap is now 3 seconds16:01
kmallockeep in mind you can [usually] upgrade keystone before other services16:01
shewlesskmalloc: interesting idea16:02
kmallocwe are mostly isolated from other services behind the rest api, some cases it is wonky, but 1-2 releases has historically be fine16:02
shewlessso no other tricks to make fernet tokens faster? even at the risk of security? :)16:02
kmallocnot really16:02
kmallocinternal to keystone we added a lot of improvements in later releases16:02
kmallocwell... i mean you could hand-code a token provider that forgoes encryption and hmac...16:03
kmallocit would be faster16:03
kmalloc>.>16:03
kmalloc<.<16:03
lbragstadso - did caching help?16:03
shewlesskmalloc: I know some people that would think that is a good idea :)16:03
kmallocwe're trying to eliminate the myriad of config options for tuning (that doesn't benefit most deploys).16:04
kmallocthe goal is to have sane behavior that doesn't need tuning16:04
shewless@lbragstad: caching did help. shaved 2-3 seconds off of my openstack stack list command16:04
kmalloclbragstad: i'll take a 30% improvement16:04
*** rcernin has quit IRC16:05
shewlessso..I also have another region running.. using the same keystone. So the keystone benefits are there.. but the other regions heat won't be using the same shared memcache pool. any ideas?16:05
lbragstadshewless: do you have a lot of revocation events in the revocation_event table?16:05
kmalloclbragstad: ah good point16:06
shewlessalso: are there any tweaks to be made in horizon to leverage caching?16:06
shewless@lbragstad: Let me look.16:06
lbragstadthat made a huge difference in performance when we fixed that16:06
kmallocnot really on hoprizon16:06
kmallocand as long as heat in the other region has it's own memcache it's fine16:06
lbragstadwe did make changes to horizon so that it didn't revoke tokens on projects switches16:06
lbragstadwhich bloated the revocation event table and slowed token validation down...16:06
kmalloclbragstad: yeah, that is mostly just a "deploy a later openstack" solution though16:06
lbragstadyeah - that's a newton improvement i think16:07
lbragstadi'd have to double check with robcresswell16:07
shewless@lbragstad: there are 12,000 rows in revocation_event16:07
lbragstadoooof16:07
lbragstadouch16:07
shewlesswill clearing that make things faster?16:07
lbragstadthat's probably contributing to slow performance16:07
shewlessor is it the thing adding the entries that's causing the problem?16:08
lbragstadwe've since indexed that table and stopped writing unnecessary events to it16:08
* lbragstad fetches another link16:08
lbragstadhttps://review.openstack.org/#/c/382107/16:08
lbragstad^ was a newton thing, too16:08
lbragstadperformance numbers are in the commit message16:09
shewlesshmm16:09
lbragstadthe gist of it is that keystone persists a revocation event when a token is invalidate (e.g. password reset or deleting a specific token)16:09
shewlesshow do you even delete a token?16:10
lbragstadwe used to pull all revocation events out of sql and compare them in python16:10
lbragstadDELETE /v3/auth/tokens with the token in the X-Subject-Token header16:10
lbragstadcomparing in python was super slow and it used a tree structure16:10
shewless@lbragstad: I doubt my users are doing that.. is there something that grants/revokes in horizon?16:10
lbragstadshewless: whenever a user switches projecst16:10
shewless@lbragstad: I see16:11
lbragstadthe previous project token is revoked by horizon16:11
*** mvk has quit IRC16:11
lbragstador it was - until we fixed that in horizon16:11
shewlessSo.. can I delete all rows in there without causing a problem?16:11
*** jamesbenson has quit IRC16:11
lbragstadwell - it will mean that tokens that were invalid might be valid again16:11
shewlessI suppose I could index the table as well manually16:11
lbragstadshewless: yes - which is another thing we did upstream16:11
lbragstadhttps://review.openstack.org/#/q/topic:bug/1524030+(status:open+OR+status:merged)16:11
lbragstadhttps://review.openstack.org/#/c/376523/16:12
shewless@lbragstad: thanks.. I'm just trying to think of a way to fix this quickly for Mitaka so we can benefit before we upgrade16:12
lbragstadwe indexed the revocation_event table and we made a smarted sql query to give us revocation events directly instead of handling all the comparisons in python16:12
lbragstadsmarter*16:12
lbragstadshewless: ack - you could go through and attempt to remove old revocation events16:13
lbragstadthat would help to some extent16:13
lbragstadthe worst possible case would be that a token that was previously invalid is now valid again until it expires16:13
shewless@lbragstad: okay I don't think that would be a big deal in my case16:13
shewless@lbragstad: do you think https://review.openstack.org/#/c/376523/ would apply relatively cleanly in mitaka?16:14
kmalloclbragstad: truncate <revocation table> :P16:14
shewlesskmalloc, @lbragstad: thank you for the help. the 30% improvement is a great start. I'd like to explore this revocation_event table thing a bit further. I need to go AFK at the moment but I'm really hoping there is a patch I can apply to improve the revocation_event interaction in mitaka16:16
cfriesen_lbragstad:  I spoke with you at the PTG about optionally restricting the service catalog when authenticating...here's the spec: https://review.openstack.org/#/c/505345/16:17
shewlessI'd love to know if I can safely truncate that table16:17
shewlessI don't really have a security problem if there are some revoked tokens that are valid... but I'm not sure if there are functionality problems if I do that16:17
*** jistr|mtg is now known as jistr16:18
kmallocshewless: be super careful with backports, if we didn't backport it to the release there may be edge cases you run into in future upgrades16:19
kmallocespecially if it affects the schema16:19
lbragstadshewless: ack - that sounds good, i'm unsure if that patch would be backportable16:24
lbragstadshewless: but you could manually manage the revocation event table if needed until you upgrade to Newton, which would contain all of those improvements16:25
lbragstadcfriesen_: awesome - thanks for posting the spec16:25
lbragstadcc kmalloc ^ you'll probably have opinions/suggestions there16:25
*** r-daneel has joined #openstack-keystone16:27
kmalloclbragstad: oh that.17:00
kmalloclbragstad: i have a lot of views on that17:00
kmalloclbragstad: ah. that isn't what i thought it was.17:01
kmalloclbragstad: it might actually be more compute intensive to limit the response fwiw17:01
kmallocon the server side17:01
kmallocon the client side, it might be less.17:01
kmalloccfriesen_: ^cc17:01
kmalloclbragstad: i'll do some more in depth review shortly17:02
*** rcernin has joined #openstack-keystone17:11
*** nkinder has joined #openstack-keystone17:15
*** ayoung has quit IRC17:24
*** raildo has quit IRC17:25
*** spilla has joined #openstack-keystone17:29
*** ioggstream has quit IRC17:36
shewlesskmalloc: seriously can I truncate <revocation table> without killing my openstack? Worst case is my revoked tokens are no longer revoked?17:37
*** raildo has joined #openstack-keystone17:37
*** tesseract has quit IRC17:37
kmallocshewless: you can. it means any tokens that were revoked that were still valid are no longer revoked17:40
kmallocshewless: be very careful you're only truncating the revocation table17:40
openstackgerritKristi Nikolla proposed openstack/keystonemiddleware master: Document endpoint interface and region behavior  https://review.openstack.org/50539617:45
*** jmlowe has quit IRC17:46
*** lbragstad has quit IRC17:47
shewlesskmalloc: just revocation_event right?17:50
* cmurphy will miss the meeting today17:51
*** lbragstad has joined #openstack-keystone17:51
*** ChanServ sets mode: +o lbragstad17:51
*** panbalag has quit IRC17:53
kmallocshewless: uhm... i *think* so17:56
kmallocshewless: sorry a little distracted atm17:56
kmallocbut that should be the right table17:57
lbragstadkmalloc: shewless they will be unrevoked until they expire17:57
lbragstadso if you token expiration is set to 1 hour and you have a token that was revoked 30 minutes ago17:57
lbragstadit will be valid for 30 minutes until it is expired if you truncate the revocation event table17:57
lbragstadkeystone checks token expiration separately from revocation event comparisons17:58
*** jamesbenson has joined #openstack-keystone18:00
*** jamesbenson has quit IRC18:04
*** aselius has joined #openstack-keystone18:07
*** ayoung has joined #openstack-keystone18:10
*** lucasxu has quit IRC18:11
*** dave-mcc_ is now known as dave-mccowan18:12
*** jmlowe has joined #openstack-keystone18:19
gagehugoI have a meeting but I'll be back for office hours in about an hour18:19
-openstackstatus- NOTICE: The infra team is continuing work to bring Zuul v3 online; expect service disruptions and please see https://docs.openstack.org/infra/manual/zuulv3.html for more information.18:24
*** lucasxu has joined #openstack-keystone18:52
*** ayoung has quit IRC18:55
*** jamesbenson has joined #openstack-keystone18:55
lbragstad#startmeeting keystone-office-hours18:58
openstackMeeting started Tue Sep 26 18:58:04 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.18:58
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:58
*** openstack changes topic to " (Meeting topic: keystone-office-hours)"18:58
*** ChanServ changes topic to "Queens release schedule: https://releases.openstack.org/queens/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h"18:58
openstackThe meeting name has been set to 'keystone_office_hours'18:58
gagehugoI think the gerrit changes broke the office hours bookmark19:00
shewlessHOLY CRAP: truncate revocation_event19:01
shewlessopenstack stack list now takes <1s19:01
shewlesstoken or ldap19:01
shewlessTHANK you kmalloc and @lbragstad19:01
shewlessso good19:01
shewlessmuch better than 10 seconds19:01
gagehugohttps://review.openstack.org/#/c/504084/ stable/pike doc change that closes 2 bugs19:01
*** ianw|pto is now known as ianw19:01
*** spilla has quit IRC19:03
lbragstadshewless: awesome - that should be much more consistent once you have Newton deployed19:04
lbragstadsince the index will be in place and we write a *lot* less events to that table19:04
*** mvk has joined #openstack-keystone19:06
*** jaosorior has quit IRC19:09
hrybackihttps://review.openstack.org/#/c/507434/1 stable/octa backport that also closes bug19:19
shewlessyes looking forward to newton/ocata. Almost done upgrading in our staging environment19:22
*** rcernin has quit IRC19:34
*** d0ugal has joined #openstack-keystone19:41
*** d0ugal has quit IRC19:41
*** d0ugal has joined #openstack-keystone19:41
lbragstadshewless: each revocation event has an attribute called 'revoked_at'19:44
lbragstadyou could programmatically remove revocation events based on that attribute19:44
lbragstadif the revoked_at time is older than time.now() - CONF.token.expiration_time, then you should be good to safely remove the revocation event19:45
shewless@lbragstad: thanks!19:52
*** jmlowe has quit IRC19:56
*** lucasxu has quit IRC19:57
*** pcaruana has quit IRC20:05
*** dave-mcc_ has joined #openstack-keystone20:10
*** ayoung has joined #openstack-keystone20:11
*** dave-mccowan has quit IRC20:12
*** dave-mccowan has joined #openstack-keystone20:23
*** belmoreira has joined #openstack-keystone20:25
*** dave-mcc_ has quit IRC20:25
*** jmlowe has joined #openstack-keystone20:30
kmalloclbragstad: or we could publish the driver that disables rev events20:45
kmalloc:P20:45
lbragstadkmalloc: driver that disabled revocation events?20:47
kmalloclbragstad: we talked about it in the past20:51
kmallocbasically just didn't store rev events at all20:51
kmallocfor deployments that don't want it20:51
*** itlinux has joined #openstack-keystone20:53
*** Suramya has joined #openstack-keystone21:04
*** jmlowe has quit IRC21:07
*** jmlowe has joined #openstack-keystone21:09
*** belmoreira has quit IRC21:12
*** thorst has quit IRC21:16
*** thorst has joined #openstack-keystone21:16
*** raildo has quit IRC21:17
*** jmlowe has quit IRC21:18
*** belmoreira has joined #openstack-keystone21:19
*** thorst has quit IRC21:21
*** belmoreira has quit IRC21:22
*** raildo has joined #openstack-keystone21:23
lbragstadedmondsw: updated https://review.openstack.org/#/c/500141/421:32
edmondswlbragstad ack21:33
lbragstadi tried bending my head around the best way to document the use cases21:33
lbragstadi ended up using examples to illustrate the point21:33
*** r-daneel has quit IRC21:43
*** d0ugal has quit IRC21:44
*** edmondsw has quit IRC21:46
*** edmondsw_ has joined #openstack-keystone21:49
lbragstadedmondsw_: done with https://review.openstack.org/#/c/500207/1 too21:53
*** edmondsw_ has quit IRC21:54
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Clarify backlog instructions and add ideas dir  https://review.openstack.org/50505722:00
*** raildo has quit IRC22:01
*** jamesbenson has quit IRC22:02
*** Suramya has quit IRC22:08
openstackgerritGage Hugo proposed openstack/keystone master: Refactor test_backend_ldap tests  https://review.openstack.org/50769422:11
*** aojea_ has quit IRC22:16
*** jmlowe has joined #openstack-keystone22:24
*** dave-mccowan has quit IRC22:36
*** itlinux has quit IRC22:37
*** lbragstad has quit IRC22:40
*** panbalag has joined #openstack-keystone22:41
*** thorst has joined #openstack-keystone23:04
*** thorst has quit IRC23:08
openstackgerritGage Hugo proposed openstack/keystone master: WIP - Refactor test_backend_ldap tests  https://review.openstack.org/50769423:14
*** panbalag has quit IRC23:26
*** jamesbenson has joined #openstack-keystone23:43
*** jamesbenson has quit IRC23:47

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