Thursday, 2015-01-29

jodahtrying one more time to reproduce this..00:01
morganfainbergbknudson, gyee, we should introduce, if anything, a window beyond expiry to maintain the cache00:01
jodahthe last time i hit it a few months ago was on a new devstack setup on a new VM. installing ntp resolves it.00:02
morganfainbergvs. relying on strict LRU00:02
gyeemorganfainberg, a window beyond expiry?00:08
jodahOk - reproducing again. just stopped ntp, forced clock back, restarted keystone, grabbed new token.00:08
morganfainberggyee, cache, and expire from cache after X window assume it's safe to remove from cache00:08
morganfainbergvs. just waiting for cache timeout00:08
morganfainbergor LRU00:08
jodahalso resatrted Trove, which houses the middleware I'm hitting00:08
jodahShould I file something for this?00:09
gyeejodah, no crime scene, no crime :D00:09
*** chrisshattuck has quit IRC00:09
jodahwhat do you mean - i can reproduce it now? haha00:09
gyeelet see00:10
*** jell has joined #openstack-keystone00:10
*** jell is now known as Guest1852400:10
gyeemorganfainberg, bknudson just verified it, expiry time has no effect on cache00:11
gyeewe always use cache_time00:11
morganfainbergright00:11
*** Guest18524 is now known as jell00:12
*** dims has quit IRC00:13
bknudsonwe also have a cache entry for invalid tokens. potential dos.00:15
bknudsonnot sure what we could do about it except limit the number of invalid tokens stored. or rate limiting.00:16
morganfainbergbknudson, limiting the number of cached tokens is [short of more housekeeping code] kind of ugly00:17
morganfainbergratlimiting is probably better00:17
gyee++00:17
jodahFiled this: https://bugs.launchpad.net/keystonemiddleware/+bug/141568700:18
TempLPBugBotLaunchpad bug 1415687 in keystonemiddleware "Keystone middleware intermittently rejects a token based on expiration" (affected: 1, heat: 6) [Undecided,New]00:18
gyeejodah, only way I think you can reproduce that bug is that your keystone and trove instances are completely out of sync00:18
jodahhope it helps00:18
jodahin terms of system clocks?00:19
gyeeyes, and the trove instances are not sharing the same cache00:19
jodahthe services are started at separate times... potentially00:19
jodahi only have 1 trove API instance00:19
jodahin this case00:19
gyeeonly 1 trove instance?00:20
jodahapi instance, yes00:20
jodahOn a different system than the rest of devstack/keystone00:20
gyeein that case, I can't explain how it would flopping between valid and invalid00:20
gyeefor the same token00:20
*** openstackgerrit has quit IRC00:21
jodahThe middleware log i attached is coming from a single trove instance, with auth flapping back and forth for the same token00:21
*** openstackgerrit has joined #openstack-keystone00:21
*** packet has quit IRC00:21
bknudsonif it was cached as valid in one thread and cached as invalid in another thread then you'd see the flopping.00:21
jodahjeez - is that bug you mentioned?00:21
gyeebknudson, can't happen like that, its the same cache00:21
bknudsonwhen using the in-memory cache there's one cache per thread.00:22
gyeeoh, this is inmemory?00:22
*** dims has joined #openstack-keystone00:22
bknudsonthe default is in-memory00:22
gyeebut two different threads can have two different system time though00:22
gyeecan't00:22
bknudsonI think it would require the token becoming invalid during the cache time00:23
bknudsonbut then that could happen even if the clocks were out of sync00:23
bknudsonI mean even if the clocks are in sync00:24
jodahAnything else I can provide with my bug report before I restart ntp and move on for now? :)00:24
gyeeright, but for a single instance, I would expect the token to stay invalid once it is invalid00:24
gyeenot flopping back and forth00:24
bknudsonbut if the clocks were in sync then that would require the token is invalidated.00:24
bknudsongyee: the problem is that there's one cache per thread... most of the api servers are multi-threaded.00:25
bknudsonI don't know about trove but nova-api is multi-threaded.00:25
gyeeright, but isn't all the thread share the system clock?00:26
bknudsona request could get a thread that cached it as valid , or a request could get a thread that cached it as invalid00:26
jodahso is there a cache per thread?00:26
bknudsonjodah: yes.00:26
gyeethat still does not explain the flopping00:26
bknudsona request could get a thread that cached it as valid , next one gets a thread where it's invalid, next one gets a thread where it's valid00:27
bknudsonso it looks like flopping.00:27
gyeehow does it cache as invalid to begin with?00:27
bknudsonit hits a thread that doesn't have the token cached so it talks to keystone server and it's invalid.00:28
*** david-lyle is now known as david-lyle_afk00:28
bknudsonit's easy to try with nova. use a valid token, then invalidate it.00:29
morganfainbergand the clock skew forces keystone to indicate a token is invalid outside of the window you'd expect with a long cache comparitively00:29
gyeebknudson, ok, I see what you mean00:29
gyeebknudson, so in theory, when the threads are saturated, all the subsequent calls will become invalid00:30
bknudsongyee: they'll all be correct once the cache time has passed.00:31
jodahbknudson: Is it difficult to just share a cache across threasd?00:31
bknudsonit's an artifact of caching. The weird thing is that a single server can have multiple caches.00:31
jodahwould seem ideal00:32
bknudsonjodah: I actually don't know why it works the way it does. Seems like a waste of resources.00:32
bknudsonwe get the in-memory cache from oslo.00:32
jodahThat, and just exposes things to these kinds of errors, among other possible races00:32
gyee1) use memcache; and 2) use ntpd; 3) spend more time at the beach00:33
jodahI'll work on #300:33
jodah:) thanks gents00:33
bknudsonhttp://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/openstack/common/memorycache.py -- it's pretty small00:34
bknudsonit doesn't do anything on purpose to have a separate cache per thread... I think it just winds up that way.00:34
bknudsonsince there will be multiple instances of the pipeline and thus multiple instances of auth_token ?00:34
gyeewe run keystone with apache2, and configure multiple process rather than multiple threads00:35
jodahmaybe the oslo folks can be poked to provide caches that are not thread local00:37
gyeememecache00:38
morganfainbergjodah, memcache is the only real option on that front00:38
morganfainbergor redis00:38
jodahis this a python limitation?00:38
gyeenot a python thing00:39
morganfainbergit's more of a introducing a lot of locking and other issues within eventlet running systems. in short, we shouldn't be doing that00:39
morganfainbergif we want caching that isn't threadlocal we should be looking at tools that do it better00:39
gyeedon't mess with the GIL man :)00:39
jodahpssh, yea00:40
jodahi think the native data structures are all threadsafe though00:40
jodahso memcache seems no diff from just using a dict00:40
morganfainbergeventlet means it's *not* really threads00:40
jodahsure, but if it's 1 or more threads, reading/writing from the same dict should be fine afaik00:41
morganfainbergthis is solving the problem in the wrong place. local in-memory cache is a bad idea00:41
jodahfor a clustered service, yea :)00:41
morganfainbergno in general00:41
morganfainbergthink of the housekeeping logic needed for dicrt00:41
morganfainbergin python00:41
jodahin general... for python?00:42
jodahnot familiar with the housekeeping00:42
morganfainbergpython dicts do not auto expire, there is a lot of extra code needed to make it work00:42
jodahah.. tea00:42
jodahyea00:42
morganfainbergif you put something in a dict, when does that go away?00:42
jodahmemcache is a convenience then00:42
morganfainbergnot just a convenience.00:42
morganfainbergbetter at solving the task00:42
morganfainberghonestly i recommend redis00:43
jodahi don't know if there are expiring dict-like things in python? i assumed there were00:44
morganfainbergnot really00:44
morganfainbergi mean i can program them.00:44
morganfainbergand i've seen people do it.00:44
morganfainbergbut it's always goign to be a lot of extra and relatively fragile code00:44
jodahthere are a few for the JVM and other platforms. one i wrote uses a single thread to expire entries00:44
jodahwhy fragile?00:45
morganfainbergbecause if you *dont* expire properly - it opens the door for a dos00:45
morganfainbergor worse a memory leak00:45
jodahdon't know if i'd say fragile, just important :)00:45
morganfainbergdeveloping an in-process-space cache is the wrong place for this.00:46
morganfainbergmemcache, redis, etc have solved a lot of this [especially when you're talking about sharing cache across threads]00:46
morganfainbergwe already have memory issues and performance issues with the thread.local in-memory cache people use from oslo-incubator00:47
jodahsure - was just curious about this problem in general in the python ecosystem00:47
morganfainbergtypically the solution is use tools that do it better in python :)00:47
jodahhaha00:47
morganfainbergin this case - memcache is waaaaaaay better at it00:47
morganfainbergand not a high barrier to entry00:47
*** markvoelker has quit IRC00:48
morganfainbergespecially since it already does LRU, automatic timeouts, etc00:48
morganfainberg:)00:48
lhchenghello, got an ldap backend related question..00:52
lhchengso.. I am working on this bug: https://bugs.launchpad.net/keystone/+bug/141147800:52
TempLPBugBotLaunchpad bug 1411478 in Keystone "Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean by LDAP drivers" (affected: 1, heat: 12) [High,New] - Assigned to Lin Hua Cheng (lin-hua-cheng)00:52
morganfainbergjodah, we use dogpile.cache for this - i expect oslo will help move to that as well for other caching cases, which should make it easier to use in-memory, memcache, redis, etc for all the differing use-cases - meaning you could do a non-thread.local driver trivially if you wanted00:52
jodahcool00:53
morganfainbergjodah, in keystone we use dogpile.cache that is. and there is a spec to make oslo.cache available that does config/wrapper for it in openstack00:53
lhchengI finish adding the user/group schema, and added the validation to the controller classes. Where else do I need to add the validation to solve the bug for ldap backend?00:53
morganfainberglhcheng, didn't... we already solve this? or is that another bug. some of these are blurring together :P00:53
morganfainberglhcheng, so that aside.00:55
morganfainberglhcheng, the issue is we aren't sure the data is converted to <type> when going to the backend or being retrieved? or both?00:56
lhchengmorganfainberg: hmm I think the bug is actually  asking for two things :P 1. add the schema 2. fix the ldap backend retrieve00:57
morganfainberglhcheng, so both00:58
morganfainberglhcheng, hm.00:58
lhchengmorganfainberg: so the data will be rejected if it doesn't match the schema00:58
lhchengmorganfainberg: yeah00:58
morganfainbergi don't think we have something that does the validate at the schema level *from* the backend00:58
morganfainbergand this doesn't really seem like an issue with the controller.00:58
morganfainbergthis looks, based on the bug, to be something in how we do py2ldap or ldap2py00:58
*** markvoelker has joined #openstack-keystone00:59
*** oomichi has joined #openstack-keystone01:00
*** tqtran is now known as tqtran_afk01:00
lhchengmorganfainberg: argh.. yeah..01:00
lhchengmorganfainberg: been working on the user/group schema and test today since it was mentioned on the bug :P01:01
morganfainbergright01:01
morganfainbergi think there are really 2 bugs here01:01
morganfainberg1: we don't have schema for user/group01:01
morganfainbergbuuuut.. that isn't this bug01:01
morganfainberg2: py2ldap and ldap2py01:01
lhchengmorganfainberg: I can open the bug for #1, I already have the code. :P01:02
morganfainbergsounds good01:02
lhchengmorganfainberg: yeah, that clarifies things now01:02
morganfainbergglad to help :P wish it was better help thought01:02
morganfainbergthough*01:02
lhchengmorganfainberg: I'll dig into that py2ldap and ldap2py thing later then01:03
lhchengmorganfainberg:  thanks! :D01:03
*** openstackgerrit has quit IRC01:05
*** openstackgerrit has joined #openstack-keystone01:05
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate LDAP Assignment Backend  https://review.openstack.org/15097001:06
*** dims has quit IRC01:10
openstackgerritLin Hua Cheng proposed openstack/keystone: Add schema for user and group  https://review.openstack.org/15106401:11
*** gyee has quit IRC01:12
openstackgerritLin Hua Cheng proposed openstack/keystone: Add schema for endpoint group  https://review.openstack.org/15029201:12
*** samueldmq_ has joined #openstack-keystone01:14
openstackgerritDavid J Hu proposed openstack/keystone: Version independent token issuance pipeline  https://review.openstack.org/15062901:14
*** tellesnobrega_ has quit IRC01:15
*** jodah has left #openstack-keystone01:18
davechen_bknudson: Hi Brant,01:26
*** markvoelker has quit IRC01:57
*** markvoelker has joined #openstack-keystone01:58
*** markvoelker has quit IRC02:02
*** junhongl has quit IRC02:06
*** tqtran_afk has quit IRC02:09
*** marg7175 has quit IRC02:11
*** rwsu is now known as rwsu-afk02:13
*** samueldmq_ has quit IRC02:18
*** junhongl has joined #openstack-keystone02:20
*** openstackgerrit has quit IRC02:20
*** openstackgerrit has joined #openstack-keystone02:20
*** erkules_ has joined #openstack-keystone02:21
*** erkules has quit IRC02:23
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617702:36
stevemarlhcheng, ^^ thanks for the review :)02:36
*** wpf has quit IRC02:36
*** wpf has joined #openstack-keystone02:37
lhchengstevemar: looking good, it's almost ready :D02:37
stevemarlhcheng, when that lands i will do a happy dance02:38
lhchenglol02:38
stevemarlhcheng, i need to think about tests for it though...02:38
stevemarat least ones that exercise the config options, and route02:39
lhchengstevemar: writing test is the hardest part of coding :)02:40
*** tellesnobrega_ has joined #openstack-keystone02:43
*** dims has joined #openstack-keystone02:45
*** lhcheng has quit IRC02:59
*** jodah has joined #openstack-keystone03:04
*** radez_g0n3 is now known as radez03:04
*** rushiagr_away is now known as rushiagr03:06
*** openstackgerrit has quit IRC03:20
*** openstackgerrit has joined #openstack-keystone03:20
*** avozza is now known as zz_avozza03:24
openstackgerritMerged openstack/keystone: Remove list_user_projects method from assignment  https://review.openstack.org/15057403:31
*** xxj has quit IRC03:43
*** junhongl has quit IRC03:43
*** wpf has quit IRC03:43
*** rushiagr is now known as rushiagr_away03:45
*** jimbaker has quit IRC03:51
*** richm has quit IRC03:52
*** jimbaker has joined #openstack-keystone03:52
*** jimbaker has quit IRC03:52
*** jimbaker has joined #openstack-keystone03:52
*** wpf has joined #openstack-keystone03:59
*** junhongl has joined #openstack-keystone04:00
*** xxj has joined #openstack-keystone04:00
*** oomichi has quit IRC04:01
*** gordc has joined #openstack-keystone04:02
*** radez is now known as radez_g0n304:04
*** dims has quit IRC04:08
*** dims has joined #openstack-keystone04:09
*** junhongl has quit IRC04:09
*** wpf has quit IRC04:10
*** xxj has quit IRC04:10
*** boris-42 has quit IRC04:13
*** markvoelker has joined #openstack-keystone04:21
*** junhongl has joined #openstack-keystone04:22
*** wpf has joined #openstack-keystone04:23
*** xxj has joined #openstack-keystone04:23
*** dims has quit IRC04:23
*** lhcheng has joined #openstack-keystone04:29
*** marg7175 has joined #openstack-keystone04:42
*** stevemar has quit IRC04:43
*** stevemar has joined #openstack-keystone04:44
*** ChanServ sets mode: +v stevemar04:44
*** tellesnobrega_ has quit IRC04:46
*** gordc has quit IRC04:47
*** gordc has joined #openstack-keystone04:47
*** harlowja is now known as harlowja_away04:48
*** rushiagr_away is now known as rushiagr04:49
*** markvoelker has quit IRC04:53
*** markvoelker_ has joined #openstack-keystone04:53
*** andreaf has quit IRC04:56
*** andreaf has joined #openstack-keystone04:56
*** f13o has quit IRC05:00
openstackgerritLin Hua Cheng proposed openstack/keystone: Add schema for endpoint group  https://review.openstack.org/15029205:00
*** zzzeek has quit IRC05:12
*** f13o has joined #openstack-keystone05:13
*** markvoelker_ has quit IRC05:16
*** markvoelker has joined #openstack-keystone05:16
*** markvoelker has quit IRC05:22
*** dims has joined #openstack-keystone05:24
*** marg7175 has quit IRC05:25
*** dims has quit IRC05:28
openstackgerritZhiyuan Cai proposed openstack/keystone: Fix evaluation logic of federation mapping rules  https://review.openstack.org/15110905:29
*** markvoelker has joined #openstack-keystone05:47
*** markvoelker has quit IRC05:52
*** oomichi_ has joined #openstack-keystone05:57
*** oomichi_ has quit IRC05:57
*** josecastroleon_ has joined #openstack-keystone06:00
*** josecastroleon has quit IRC06:03
*** josecastroleon__ has joined #openstack-keystone06:05
*** gordc has quit IRC06:08
*** josecastroleon_ has quit IRC06:09
*** jaosorior has joined #openstack-keystone06:17
openstackgerritMerged openstack/keystone: Remove unnecessary code block of exception handling  https://review.openstack.org/14995606:18
*** wpf has quit IRC06:19
*** wpf has joined #openstack-keystone06:21
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/14915806:23
*** gtt116__ has joined #openstack-keystone06:44
gtt116__morganfainberg, Hi, around?06:44
gtt116__morganfainberg, does dogpile just a cache for token, we still need some real storage backend (mysql). Can I just use redis for a storage backend, without MySQL or memcache?06:45
*** markvoelker has joined #openstack-keystone06:48
*** afazekas has joined #openstack-keystone06:51
*** markvoelker has quit IRC06:52
*** xxj has quit IRC06:54
*** xxj has joined #openstack-keystone06:54
*** stevemar has quit IRC06:55
*** stevemar has joined #openstack-keystone06:55
*** ChanServ sets mode: +v stevemar06:55
morganfainberggtt116__, so you can use dogpile + memcache for a store07:03
morganfainberggtt116__, but i recommend using redis instead07:03
morganfainberggtt116__, but you can def. avoid using mysql for tokens07:04
*** ksavich_ has quit IRC07:05
*** markvoelker has joined #openstack-keystone07:21
*** markvoelker has quit IRC07:27
*** oomichi has joined #openstack-keystone07:33
*** henrynash has joined #openstack-keystone07:45
*** ChanServ sets mode: +v henrynash07:45
*** lhcheng has quit IRC07:48
*** lhcheng has joined #openstack-keystone07:48
*** pnavarro has joined #openstack-keystone07:52
*** lhcheng has quit IRC07:53
*** andreaf has quit IRC07:56
*** andreaf has joined #openstack-keystone07:56
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113707:58
*** f13o has quit IRC07:58
*** stevemar has quit IRC08:12
*** f13o has joined #openstack-keystone08:16
*** markvoelker has joined #openstack-keystone08:25
*** gtt116__ has quit IRC08:29
*** gtt116__ has joined #openstack-keystone08:29
*** markvoelker has quit IRC08:31
marekdhenrynash: hi. Do you fancy looking at: https://review.openstack.org/#/c/110858/ ?08:35
*** nellysmitt has joined #openstack-keystone08:35
henrynashmarekd: sure…will do in a bit08:36
*** chlong has quit IRC08:36
*** zz_avozza is now known as avozza08:36
marekdhenrynash: whenever you can :-)08:46
openstackgerritMarek Denis proposed openstack/keystone: Implements whitelist and blacklist mapping rules  https://review.openstack.org/14257308:51
marekdhenrynash: thanks.08:53
henrynashmarked: np….see my comment on adding something to the docs….could be done in a follow on patch, if needed08:54
marekdhenrynash: answered in the patch. I agree.08:55
henrynashmarked: ok08:55
*** avozza is now known as zz_avozza09:05
*** rushiagr is now known as rushiagr_away09:07
*** rushiagr_away is now known as rushiagr09:10
openstackgerritMerged openstack/keystone-specs: Improve list role assignments filters performance  https://review.openstack.org/14870009:12
*** jistr has joined #openstack-keystone09:16
*** erkules_ is now known as erkules09:24
*** zz_avozza is now known as avozza09:25
*** markvoelker has joined #openstack-keystone09:28
openstackgerrithenry-nash proposed openstack/keystone: Support data-driven backend assignment testing  https://review.openstack.org/14917809:30
*** markvoelker has quit IRC09:34
openstackgerrithenry-nash proposed openstack/keystone: Support data-driven backend assignment testing  https://review.openstack.org/14917809:39
*** andreaf has quit IRC09:51
*** andreaf has joined #openstack-keystone09:51
*** breton has joined #openstack-keystone10:04
*** chlong has joined #openstack-keystone10:13
*** tellesnobrega_ has joined #openstack-keystone10:17
*** chlong has quit IRC10:27
*** markvoelker has joined #openstack-keystone10:30
*** markvoelker has quit IRC10:34
*** harlowja_away has quit IRC10:36
*** tellesnobrega_ has quit IRC10:43
*** andreaf has quit IRC10:44
*** chlong has joined #openstack-keystone10:44
*** andreaf has joined #openstack-keystone10:44
openstackgerrithenry-nash proposed openstack/keystone: Support data-driven backend assignment testing  https://review.openstack.org/14917810:52
*** ajayaa has joined #openstack-keystone10:53
openstackgerritIgor Milovanovic proposed openstack/python-keystoneclient: Updated oslo import namespace to remove deprecation message  https://review.openstack.org/15117410:55
samueldmqmorning10:55
samueldmqhenrynash, hi10:55
henrynashsamueldmq: hi10:55
samueldmqhenrynash, just saw your comment on that patch ... can't we filter inherited and effective?10:56
samueldmqhenrynash, I just made it possible few patches ago, since inherited info *is in* entities in the returned list when we use effective10:56
samueldmqhenrynash, that should mean get *only* assignments from inheritance10:57
samueldmqhenrynash, if you only wanna get assignment that *will* be inherited, apply inherited filter without effective10:57
henrynashsamueldmq: well, it’s kind of a weird filter….maybe…thinking10:58
*** tellesnobrega_ has joined #openstack-keystone11:00
henrynashsamueldmq: ok, so I guess it makes sense….but probably give a coconut to the first customer who works out what the results are meant to be :-)11:00
samueldmqhenrynash, haha :-)11:01
samueldmqhenrynash, after all this work, I intend to read all inherited roles documentation to make sure everything is up to date11:01
samueldmqhenrynash, we changed *a lot* with hierarchical projects :-)11:02
henrynashsamueldmq: and if you said effective=True AND inherited=False……what woudl that mean, I think that would mean all direct roles and all expand group roles?11:02
samueldmqhenrynash, exactly11:02
samueldmqhenrynash, we should have a test for those as well ... could you please add on your patch11:03
henrynashsamueldmq: ok, I’ll order the coconuts…this is going to be interesting…11:03
samueldmqhenrynash, haha, one for me please sir :-)11:03
henrynashsamueldmq: yes…I’m going to add some dependant patches which add more and mroe tests11:03
henrynashsamueldmq: I’ll work on that today11:03
samueldmqhenrynash, great! so now it looks we have things working properly11:04
samueldmqhenrynash, thanks for your last comments, but as I said yesterday, I'll go through that chain and improve docs, check for nits (as I do for other people patches)11:04
henrynashsamueldmq: yep, just posted a new version of my tests that just clearned the docstring errors - but have run it locally and it all passed11:04
henrynashsamueldmq: sure, np11:04
samueldmqhenrynash, I just needed to have some time away from this patch .. needed to cleanup my cache, the missrate was high in it :-)11:05
henrynashsamueldmq: :-)11:06
*** tellesnobrega_ has quit IRC11:06
samueldmqhenrynash, I plan to get a  blog up to next week, my first interesting post will be a benchmark of this refactoring (:11:06
henrynashsamueldmq: nice!11:07
*** tellesnobrega_ has joined #openstack-keystone11:07
samueldmqhenrynash, if I added you as co-author on that patch, was I revoking your right to do reviews?11:08
*** oomichi has quit IRC11:08
henrynashsamueldmq: well, it would probably revoke my right to +2 it11:09
samueldmqhenrynash, but +2s will come from others, once they see your +1 :)11:09
henrynashsamueldmq: sure, ho head11:09
henrynashgo ahead11:09
samueldmqhenrynash, will add you, no need to explain, you just did things work, thx11:10
henrynash(can’t type this morning)11:10
henrynashthx11:10
samueldmqnp, so busy?11:10
*** tellesnobrega_ has quit IRC11:11
*** oomichi_ has joined #openstack-keystone11:27
*** markvoelker has joined #openstack-keystone11:31
*** KanagarajM2 has joined #openstack-keystone11:34
*** markvoelker has quit IRC11:35
*** chlong has quit IRC11:39
*** aix has joined #openstack-keystone11:40
*** breton has quit IRC11:50
*** breton has joined #openstack-keystone11:50
*** oomichi_ has quit IRC11:59
*** chlong has joined #openstack-keystone12:05
*** radez_g0n3 is now known as radez12:08
*** raildo has joined #openstack-keystone12:14
*** oomichi_ has joined #openstack-keystone12:16
*** KanagarajM2 has quit IRC12:25
*** markvoelker has joined #openstack-keystone12:31
*** markvoelker has quit IRC12:36
*** avozza is now known as zz_avozza12:46
*** zz_avozza is now known as avozza12:53
*** adam_g is now known as adam_g_out12:57
openstackgerritRodrigo Duarte proposed openstack/keystone: Remove extra semicolon from mapping fixtures  https://review.openstack.org/14808013:01
*** BobBall has joined #openstack-keystone13:13
*** oomichi_ has quit IRC13:14
*** EmilienM|afk is now known as EmilienM13:14
*** radez is now known as radez_g0n313:19
*** bknudson has quit IRC13:26
*** boris-42 has joined #openstack-keystone13:31
rodrigods-13:32
*** markvoelker has joined #openstack-keystone13:33
*** markvoelker has quit IRC13:35
*** markvoelker_ has joined #openstack-keystone13:35
dstanek+13:35
rodrigodsdstanek, haha13:36
dstanekrodrigods: room felt unbalanced13:36
rodrigodsdstanek, lots of ++ need --13:38
*** rushiagr is now known as rushiagr_away13:40
*** gordc has joined #openstack-keystone13:46
*** bknudson has joined #openstack-keystone13:48
*** ChanServ sets mode: +v bknudson13:48
*** marg7175 has joined #openstack-keystone13:53
*** Ctina__ has joined #openstack-keystone13:55
*** jistr has quit IRC13:58
*** jistr has joined #openstack-keystone14:00
*** avozza is now known as zz_avozza14:04
*** Ctina___ has joined #openstack-keystone14:08
*** Ctina___ has quit IRC14:09
*** Ctina__ has quit IRC14:09
*** dims has joined #openstack-keystone14:10
*** sriram has joined #openstack-keystone14:13
*** marg7175 has quit IRC14:14
*** dims has quit IRC14:14
*** nkinder has quit IRC14:21
*** zzzeek has joined #openstack-keystone14:22
openstackgerritAlexander Makarov proposed openstack/keystone: Chain a trust with a role specified by name  https://review.openstack.org/14864214:27
openstackgerrithenry-nash proposed openstack/keystone: My First ABAC: An example alternative assignment engine  https://review.openstack.org/14355714:28
rodrigodshenrynash, thx for the review in the reseller spec, replied your comments there :) sorry if with more questions than solutions hehe14:29
henrynashrodigods: ok, will check…:-)14:29
*** bdossant has joined #openstack-keystone14:32
*** mattfarina has joined #openstack-keystone14:33
*** rushiagr_away is now known as rushiagr14:33
*** richm has joined #openstack-keystone14:33
*** jasondot_ has joined #openstack-keystone14:34
*** gordc has quit IRC14:34
*** zzzeek has quit IRC14:39
*** dims has joined #openstack-keystone14:41
*** jasondot_ has quit IRC14:45
openstackgerrithenry-nash proposed openstack/keystone: Move projects and domains to their own backend  https://review.openstack.org/14482414:45
openstackgerrithenry-nash proposed openstack/keystone: Remove unused pointer to assignment in identity driver  https://review.openstack.org/14502214:47
openstackgerrithenry-nash proposed openstack/keystone: Make controllers and managers reference new resource manager  https://review.openstack.org/13352514:47
openstackgerrithenry-nash proposed openstack/keystone: Make unit tests call the new resource manager  https://review.openstack.org/13095414:48
openstackgerritMarco Fargetta proposed openstack/keystone: Multiple IDP authentication URL  https://review.openstack.org/14274314:50
*** r-daneel has joined #openstack-keystone14:51
*** ajayaa has quit IRC14:52
*** topol has joined #openstack-keystone14:57
*** ChanServ sets mode: +v topol14:57
*** markvoelker_ has quit IRC15:03
*** zz_avozza is now known as avozza15:05
*** nkinder has joined #openstack-keystone15:07
*** jistr has quit IRC15:10
*** gordc has joined #openstack-keystone15:11
*** jistr has joined #openstack-keystone15:12
*** timcline has joined #openstack-keystone15:23
*** avozza is now known as zz_avozza15:24
*** mattfarina has quit IRC15:25
*** radez_g0n3 is now known as radez15:26
*** zz_avozza is now known as avozza15:26
openstackgerritMerged openstack/keystone-specs: Remove URL field from regions  https://review.openstack.org/15010915:30
morganfainbergayoung, dstanek, bknudson, lbragstad, topol, henrynash, dolphm, gyee, jamielennox|away, http://lists.openstack.org/pipermail/openstack-dev/2015-January/055531.html15:34
*** packet has joined #openstack-keystone15:35
ayoungmorganfainberg, and that is why we post this to the big mailing list15:35
morganfainbergyep15:36
dstanekmorganfainberg: hmmm...15:36
dolphmmorganfainberg: i've actually been testing galera across DC's recently, and it performs quite well15:36
morganfainbergi do like that there is claim they've been making modifications to "make it work" but i've seen no relfection in that contributions back to us15:37
*** mattfarina has joined #openstack-keystone15:37
morganfainbergdolphm, replication across WAN with galera is scary. not that it doesn't work well until it breaks.15:37
lbragstadinteresting...15:37
morganfainbergdolphm, but it could be a workable solution15:37
morganfainbergdolphm, depends on the latency though.15:38
dolphmmorganfainberg: response times fall off as you add more remote DC's, but i have a 5 node galera cluster right now that has a node in washington DC, chicago, dallas, hong kong, and sydney and i'm "only" getting an *extra* 280ms response times for token creates as a result, considering it's such an extreme example15:38
lbragstaddolphm: do you still have those results published on that gist?15:38
dolphmlbragstad: i *just* reset all my numbers to start over on tuning everything15:38
morganfainbergdolphm, that sounds about right. the big issue is massive traffic and the need for galera to do a "all confirm before commit".15:38
dolphmlbragstad: but yes, you can go back a few commits15:38
bknudsonare assignments changing so quickly that sql replication can't work?15:39
morganfainbergbknudson, nah.15:39
morganfainbergyou could totally do SQL replication15:39
dolphmall my benchmarking stuff is here if anyone is interested https://gist.github.com/dolph/02c6d37f49596b3f429815:39
morganfainbergit's just when it breaks w/ a massively distributed replication like dolphm is running it gets scary. it is totally workable with people keeping an eye on it15:40
bknudsonmulti-master replication seems like overkill15:40
dolphmbknudson: but fun15:40
morganfainbergbknudson, mysql multi-master is bad, galera is good :)15:40
*** stevemar has joined #openstack-keystone15:41
*** ChanServ sets mode: +v stevemar15:41
dolphmgalera is basically mysql multimaster now15:41
dolphms/is basically/basically is/ ?15:41
dolphmlbragstad: anyway, i'm spending today doing more methodical tuning15:42
dolphmmorganfainberg: maybe i should write an article about the results?15:42
lbragstaddolphm: ++15:42
dstanekdolphm: yes, that would be cool to see15:42
lbragstaddolphm: I'd be will to help with that15:42
dolphmlbragstad: (hence the reset)15:42
dolphmlbragstad: i'll head to the office then15:42
morganfainbergdolphm, please do!15:43
bknudsonThe issue isn't just that it's unmaintained, but if we're going to have it then it constrains what we can do with assignments in general15:43
morganfainbergdolphm, it would be great to have it!15:43
dolphmmorganfainberg: happy to15:43
bknudsonunless they really think that everything that you can do in sql you can do in ldap15:43
richmI'm working on the puppet keystone code - in puppet keystone, puppet uses the admin_token for auth to do the bootstrap config - this works fine with v2 - however, with v3 policy, once v3 policy is enabled and activated, admin_token auth doesn't work.  Is there some way to configure the v3 policy to allow admin_token to continue to have "superuser" access over all of the domains?15:43
dstanekbknudson: i'd rather then prove it and get it up to speed out of tree so we can keep moving forward15:43
morganfainbergdolphm, galera is sortof multumaster, it "fixes" multi-master by not sucking like mysql replication does ;)15:44
morganfainbergdolphm, but galera even says [last i saw] you *really* should only write to one node. under heavy load it gets a bit wonky writing to any note15:44
morganfainbergnode*15:44
dolphmmorganfainberg: i mean it has effectively deprecated traditional replication15:45
morganfainbergdolphm, it's all usable and doable, just needs people to keep eyes on it [operations]15:45
morganfainbergdolphm, in my experience.15:45
*** markvoelker has joined #openstack-keystone15:45
dolphmmorganfainberg: i'll be benchmarking that too :)15:45
marekdgalera is mysql successor?15:45
morganfainbergdolphm, awesome15:45
morganfainbergmarekd, it's a clustering technology that layers in to the mysql engine15:45
morganfainbergmarekd, like innodb plugin15:45
dolphmmorganfainberg: eventually going to stand up 2 or 3 galera nodes per DC (so 15 nodes total), with HA proxy in front of them, and keystone nodes in every DC15:45
dolphmmarekd: it's more like a replication driver for mysql15:46
*** dims has quit IRC15:46
samueldmqdolphm, what operations are you interested on benchmarking ?15:47
samueldmqdolphm, have you considered to use rally ?15:47
bknudsondoes rally have a benchmark that shows how long it takes to get a token?15:47
morganfainbergbknudson, maybe? i think we have that one running now15:48
samueldmqbknudson, let me check what operations they support, but I think so15:48
*** dims has joined #openstack-keystone15:48
samueldmqbknudson, well, from default scenarios they provide, it's clear it can benchmark user/project creation (https://github.com/stackforge/rally/tree/master/samples/tasks/scenarios/keystone)15:52
samueldmqbknudson, you can even set sla for them (https://github.com/stackforge/rally/blob/master/samples/tasks/sla/create-and-delete-user.yaml)15:52
samueldmqbknudson, not sure about tokens15:52
bknudsonrichm: I think the is_admin:True flag is used in the policy to allow the admin token.15:52
richmbknudson: Is this documented somewhere?15:53
openstackgerrithenry-nash proposed openstack/keystone: Make role manager refer to role cache config options  https://review.openstack.org/15129215:54
bknudsonrichm: it's in the code!15:55
richmbknudson: ack15:55
bknudsonrichm: nkinder was working on some dev docs.15:55
*** dims has quit IRC15:59
openstackgerrithenry-nash proposed openstack/keystone: Move projects and domains to their own backend  https://review.openstack.org/14482416:03
samueldmqhenrynash, need to rebase the whole chain :-)16:04
henrynashsamueldmq: i know…underway16:04
*** thedodd has joined #openstack-keystone16:04
openstackgerrithenry-nash proposed openstack/keystone: Remove unused pointer to assignment in identity driver  https://review.openstack.org/14502216:05
openstackgerrithenry-nash proposed openstack/keystone: Make controllers and managers reference new resource manager  https://review.openstack.org/13352516:06
openstackgerrithenry-nash proposed openstack/keystone: Make unit tests call the new resource manager  https://review.openstack.org/13095416:06
openstackgerrithenry-nash proposed openstack/keystone: Split the assignments controller  https://review.openstack.org/13263416:07
openstackgerritKamil Rykowski proposed openstack/keystone: Documentation fix for Keystone Architecture  https://review.openstack.org/15129416:09
*** avozza is now known as zz_avozza16:10
*** bdossant has quit IRC16:11
*** joesavak has joined #openstack-keystone16:12
morganfainberghenrynash, OMG  SPAM!16:13
morganfainberghenrynash, ;)16:13
morganfainberghenrynash, i am very slowly making it through that review.16:14
morganfainberghenrynash, i think i'm half way through16:14
*** mattfarina has quit IRC16:14
henrynashmorganfainberg: ok!16:17
henrynashbknudson: ping16:17
bknudsonhenrynash: what's up?16:17
openstackgerritMarco Fargetta proposed openstack/keystone: Multiple IDP authentication URL  https://review.openstack.org/14274316:17
richmnkinder: ping - do you have documentation about keystone v3 policy?16:18
henrynashbknudson: so your question on unit tests for the role caching..so there are tests already taht test that that caching works…there in test_backend.py16:18
richmbknudson: would you happen to know how/where is_admin:True is specified in the policy?16:19
bknudsonhenrynash: but they must not be using the new config option?16:19
nkinderrichm: yes, I have some reviews out for some of that16:19
nkinderrichm: let me find links...16:19
bknudsonhenrynash: it was broken and the tests still passed.16:19
henrynashbknudson: so do any of the caching tests actually vary the individual config cache options?16:19
nkinderrichm: here's some general policy syntax docs - https://review.openstack.org/#/c/150953/16:20
openstackgerritSteve Martinelli proposed openstack/keystone: Multiple IDP authentication URL  https://review.openstack.org/14274316:20
nkinderrichm: here's keystone specific - https://review.openstack.org/#/c/123862/16:20
rodrigodsmorganfainberg, so... reseller, have some time to discuss?16:21
bknudsonhenrynash: there's a bunch of tests that do skip_if_cache_disabled -- http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_backend.py#n3074 -- maybe they're all skipped?16:21
morganfainbergrodrigods, not until post coffee16:21
morganfainbergrodrigods, but yes today16:21
rodrigodsmorganfainberg, great! please ping us whenever you have a moment :)16:21
richmI don't see "is_admin" in either of those docs16:21
bknudsonhenrynash: morganfainberg probably knows more about the cache testing.16:21
morganfainbergbknudson, hmm? cache testing?16:22
henrynashbknudson: the tests in test_backend check the the caching is working…they don’t actually manipulate teh config vlaues16:22
bknudsonmorganfainberg: e.g., tests for this change: https://review.openstack.org/#/c/151292/16:22
* morganfainberg looks16:23
bknudsonhenrynash: caching is disabled by default... so it must manipulate the config values in order to test it16:23
*** bdossant has joined #openstack-keystone16:24
bknudsonhenrynash: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_backend.py#n3218 looks like tests for role crud.16:24
henrynashbknudson: the role tests will pass either way…since its a functional cache test…so as long as caching is on, it wil work16:24
morganfainbergbknudson, yes if we're changing the config values to be looked at, the tests must (in setup or .config_override) change to use the correct config values. however, caching for a specific section is enabled by default16:24
morganfainbergglobal caching is disabled16:24
*** abhirc has quit IRC16:24
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617716:24
morganfainberg*usually* just turning on global caching is enough16:24
morganfainbergmost tests already do that16:24
rodrigodsstevemar, ^ wow16:24
bknudsonshould http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_backend.py#n3218 be @tests.skip_if_cache_disabled('role') ?16:25
henrynashbknudosn: so, yes, that’s it (and I shoudl change the disabled wrapped to reference ‘role’)16:25
henrynashbknudson: yes, agreed16:25
morganfainberghenrynash, and yes those should be updated.16:25
*** zzzeek has joined #openstack-keystone16:25
stevemarrodrigods, whats up?16:25
bknudsonhenrynash: ok, that answers my question. that change will work for me.16:25
henrynashbknudson: ok, I’ll make that change and re-submit16:26
rodrigodsstevemar, didn't know there was already an implementation for websso going on :)16:26
richmI see - it's like in the v2 policy "admin_required": "role:admin or is_admin:1",16:27
*** bdossant_ has joined #openstack-keystone16:27
bknudsonI assume several of the @tests.skip_if_cache_disabled('assignment') get updated when the projects and domains are moved to resources.16:27
stevemarrodrigods, i think the CERN guys had this 6 months ago16:28
morganfainbergbknudson, or could be fixed in a quick-follow-on patch.16:28
bknudson@tests.skip_if_cache_disabled('assignment') -> @tests.skip_if_cache_disabled('resources') at http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_backend.py#n316416:28
stevemarrodrigods, we're just slow :)16:28
openstackgerrithenry-nash proposed openstack/keystone: Make role manager refer to role cache config options  https://review.openstack.org/15129216:29
henrynashbknudson: yep, that one too16:29
*** bdossant has quit IRC16:30
*** dims has joined #openstack-keystone16:32
*** dims has quit IRC16:34
*** dims has joined #openstack-keystone16:38
*** chrisshattuck has joined #openstack-keystone16:38
openstackgerrithenry-nash proposed openstack/keystone: Move projects and domains to their own backend  https://review.openstack.org/14482416:40
*** mattfarina has joined #openstack-keystone16:43
openstackgerrithenry-nash proposed openstack/keystone: Remove unused pointer to assignment in identity driver  https://review.openstack.org/14502216:45
*** bdossant_ has quit IRC16:47
openstackgerritDavid Stanek proposed openstack/keystone: Support for running functional federation tests  https://review.openstack.org/13913716:47
openstackgerritDavid Stanek proposed openstack/keystone: enables bashate checking on upcoming dsvm code  https://review.openstack.org/15130916:47
openstackgerritDavid Stanek proposed openstack/keystone: adds a devstack plugin for running a pysaml2 IdP  https://review.openstack.org/15131016:47
openstackgerritDavid Stanek proposed openstack/keystone: adds a devstack plugin for setting up federation  https://review.openstack.org/15131116:47
*** henrynash has quit IRC16:47
*** packet has quit IRC16:49
*** henrynash has joined #openstack-keystone16:49
*** ChanServ sets mode: +v henrynash16:49
*** david-lyle_afk is now known as david-lyle16:49
*** ljfisher has joined #openstack-keystone16:51
*** ajayaa has joined #openstack-keystone16:53
openstackgerrithenry-nash proposed openstack/keystone: Make controllers and managers reference new resource manager  https://review.openstack.org/13352516:53
*** jsavak has joined #openstack-keystone16:53
openstackgerrithenry-nash proposed openstack/keystone: Make unit tests call the new resource manager  https://review.openstack.org/13095416:53
*** rwsu-afk is now known as rwsu16:55
*** bdossant has joined #openstack-keystone16:57
*** joesavak has quit IRC16:57
*** packet has joined #openstack-keystone16:57
*** angelamolock has joined #openstack-keystone16:57
openstackgerrithenry-nash proposed openstack/keystone: Split the assignments controller  https://review.openstack.org/13263416:59
*** markvoelker has quit IRC17:03
*** marg7175 has joined #openstack-keystone17:05
*** afazekas has quit IRC17:07
*** _cjones_ has joined #openstack-keystone17:10
*** nellysmitt has quit IRC17:11
*** bdossant has quit IRC17:12
*** jsavak has quit IRC17:18
*** lhcheng has joined #openstack-keystone17:24
*** EmilienM is now known as EmilienM|afk17:27
*** joesavak has joined #openstack-keystone17:29
*** markvoelker has joined #openstack-keystone17:30
*** jistr has quit IRC17:31
openstackgerritAlexander Makarov proposed openstack/keystone: Redis token backend  https://review.openstack.org/15084417:31
*** afazekas has joined #openstack-keystone17:34
*** jodah has left #openstack-keystone17:36
marekdayoung: Hi. I am just wondering - do you see any usecase for being able to actually map ephemeral users to an existing domain?17:37
marekdayoung: for some metering, billing purposes maybe?17:37
*** breton has quit IRC17:38
ayoungmarekd, "existing"17:40
*** nellysmitt has joined #openstack-keystone17:40
ayoungmarekd, groups17:40
ayoungmarekd, I could see users coming out of saml, but groups being managed on the Keystone side17:41
marekdayoung: so this is today's situation.17:42
marekdephemeral users, groups completely managed by Keystone...17:43
marekdayoung: https://review.openstack.org/#/c/104623/ Service Providers implementation, please :-)17:44
ayoungmarekd, the problem with this is there is no quid-pro-quo.  I have patches from last March, but even if you review, you can't +2.  We need to make you guys that keep beating me up for reviews  core so we can beat you up for +as.17:46
*** gabriel-bezerra has quit IRC17:47
rodrigodsayoung, ^ this is our dream here in the university :P17:48
rodrigodsreally tough to get stuff merged sometimes17:49
*** ayoung is now known as misanthrope17:49
*** misanthrope is now known as ayoung17:49
raildorodrigods, ++17:49
marekdayoung: yes, go ahead :]17:50
*** marg7175 has quit IRC17:50
ayoungmarekd, rodrigods  sorry, but morganfainberg has to do that17:50
marekdayoung: i am not asking for anything! I don't actually like asking for anything!17:51
rodrigodsmarekd, ayoung, yep... maybe one day :P17:51
rodrigodsmarekd, I like to ask sometimes17:51
morganfainbergHmm? What do I need to do?17:51
marekdmorganfainberg: nothing.17:52
ayoungmorganfainberg, promote everyone to core17:52
rodrigodslol17:52
raildoayoung, I like the idea hahaha17:52
samueldmqthen we would need a core-core group17:52
marekdi dont17:52
ayoungmarekd, I don't either.  Being core is probably the single biggest impediment to me getting things done.17:53
rodrigodsayoung, reviews?17:53
ayoungthat too17:53
ayoungrodrigods, conversations in IRC.17:53
* ayoung just as guilty as all others17:53
*** marg7175 has joined #openstack-keystone17:53
rodrigodsayoung, oops =(17:53
ayoungrodrigods, I've been meaning to sit down and unify the AccessInfo changes for two weeks now17:54
ayoungI just got as far as "rebase origin/master"17:54
rodrigodsayoung, :( just be happy that us (keystone n00bs) are really thankful for your help in IRC17:55
ayoungrodrigods, and without you guys, nothing would get done17:55
ayoungand you guys are awesome17:55
rodrigodsthanks! we try to be helpful too17:55
ayoungits just keeping me from doing my direct assigned tasks,  not from actually making progress17:56
*** angelamolock has quit IRC17:56
* ayoung just whingeing17:56
ayoungrodrigods, it was also the internal IRC message about yet another customer-mysql-token-flush issue17:56
ayoungand my expense report I still haven't done from last week17:57
morganfainbergbeing core/ptl is a big drain on time.17:57
ayoungand the million other little details that keep coming up, and I really just want to write code17:57
morganfainbergif you want to develop a lot of code, core is not the place to be :P17:57
ayoungmorganfainberg, Amen17:57
morganfainbergif you want to review a lot and direct the project so others can develop17:57
morganfainbergcore is the right place17:57
rodrigodsmorganfainberg, ayoung the responsibility sounds about right to me17:58
morganfainbergrodrigods, notice how much code i've written this cycle17:58
morganfainbergcompared to even last17:58
rodrigodsthe biggest advantage of being core IMO, is to keep changes flowing17:58
rodrigodsmorganfainberg, yep... I did notice that17:58
* morganfainberg has more bug triage to do before writing code today17:59
rodrigodsin linux kernel, +A counts as patches to the approver heh17:59
rodrigodsLinus has something about 2k patches last year17:59
rodrigodsthe thing is that we are taking some demands that I believe would need core status in near future (to keeps things flowing so our stuff could flow quickly as well)18:00
*** radez is now known as radez_g0n318:00
rodrigodssamueldmq, raildo ^18:01
morganfainbergrodrigods, so what was the reseller thing18:01
morganfainbergthen i'm actually off to go get coffee18:01
morganfainberg*finally*18:01
* marekd lol18:01
raildorodrigods, I totally agree with you :)18:01
*** rushiagr is now known as rushiagr_away18:02
rodrigodsmorganfainberg, heh, sorry about that18:03
*** afazekas_ has joined #openstack-keystone18:03
rodrigodsdid you have the change to look our comments in the spec? https://review.openstack.org/#/c/139824/24/specs/kilo/reseller.rst18:03
rodrigodschance*18:03
morganfainberglooking now18:03
morganfainbergi've read it previously18:03
morganfainbergbut yes i have read it18:04
stevemarrodrigods, nice review of the websso patch :)18:05
rodrigodsstevemar, ++18:05
*** f13o has quit IRC18:06
rodrigodsmorganfainberg, so... 1 question: I remember that you cited once that we need to keep compatibility with the v3 API and list_domains would return only root domains... I didn't get why :(18:06
morganfainbergwhat is a non-root domain to the standard V3 API ?18:07
morganfainbergassuming something doesn't get HMT at all?18:07
rodrigodsif it doesn't get HMT at all, it would never have non-root domains18:07
morganfainbergif you can answer that for me clearly, i can be convinced all domains should be in the list.18:07
morganfainbergsomething consuming keystone data18:08
morganfainbergnot keystone itself18:08
*** f13o has joined #openstack-keystone18:08
morganfainbergif .list_domains returns HMT data, what does that mean to something that has no concept of the hierarchy18:08
rodrigodscan't imagine use cases where they should be aware about the hierarchy18:08
rodrigodsthey would see as separate domains, as far as I can imagine18:09
morganfainbergi'm concerned a flat view of domains would cause issues.18:09
morganfainbergthats all18:09
morganfainbergi can be convinced that is a non-issue. but there are a lot of assumptions about HMT being made in general when non-keystone things are consuming data.18:09
rodrigodsok... I get your point, just don't know how can we justify it clearly in the spec...18:09
rodrigodsand I can't imagine real issues of considering as separate domains (even if there is a hierarchy going on there)18:10
rodrigodshenrynash, ^18:11
morganfainbergrodrigods, i'm not set against showing all domains just explain [lightly] what the behavior should be - treat the domain isolated? etc.18:11
rodrigodsmorganfainberg, ++ makes sense to me18:11
morganfainbergwhat does it mean for projects inside projects then unless you're HMT aware18:11
rodrigodsok, we'll try to be clear about that point18:12
samueldmqmorganfainberg, another option would be to keep list_domains to root domains and then have an api list_subdomains(domain_id)18:12
morganfainbergsamueldmq, correct18:12
morganfainbergi just want to be able to provide clear direction to those consuming HMT enabled keystone18:12
morganfainbergyou shoudl handle this like X18:12
morganfainbergregardless of what X is.18:12
morganfainberg[and that we don't break current v3]18:13
raildoorganfainberg, but we are thinking that a subdomain is a project with domain-ness flag, so we are thinking in implementing this in the project API18:13
*** angelamolock has joined #openstack-keystone18:14
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617718:15
morganfainbergraildo, ok so... when i do .list_domains, what do i get back?18:15
morganfainbergraildo, is it *all domains* or just root-level domains18:15
morganfainbergraildo, remember v3 api knows about domains.18:16
raildomorganfainberg, so, if we need to following what you explain before, in list domains we will just return the root-level domain, and can return the project domain-ness in the project list18:16
morganfainbergit is perfectly fine to say the domain API is really for top-level / root domains18:16
morganfainbergayoung, henrynash, topol, ^ any thoughts18:17
morganfainbergstevemar, bknudson, dstanek, ^18:17
ayoungmorganfainberg, root level18:17
ayounglist_domains needs a namespace18:17
morganfainbergayoung, that is my thought18:18
ayoungif none is specified, assume the default namespace18:18
ayoungnow...if the user has a domain scoped token, you could argue that is like doing ls .18:18
ayoungand you should list all domains under the current namespace, but I'd argue we should stop inferring from the token18:18
*** abhirc has joined #openstack-keystone18:19
morganfainbergayoung, yes inferring from the token is bad18:19
morganfainbergimo18:19
ayoungso list_domains --parent=domid18:19
ayoungor18:19
ayoungso list_domains --parent=dom1/dom2/dom318:19
ayoungprobably make that first18:19
ayoungso list_domains --parent_id=domid18:19
ayoungwe should make it a point to work with the good names if possible18:20
ayoungby default, and resort to Ids only when necessary18:20
ayoungand make it explicit that we are using Ids,  but for most things that ship already sailed18:20
raildo, just to say that.rodrigods had a little problem in your pc, adn he'll back in a few minutes :)18:20
rodrigodsI'm back18:21
rodrigodsayoung, makes sense to me18:21
rodrigodsif we do not provide a parent_id, means we are asking for parent_id=null18:21
rodrigodswhich are root domains18:21
raildoayoung, we discuss something like that i the spec, right now... to get a token for a subdomain, maybe we need to specify the parent domain_id18:22
rodrigodsmorganfainberg, right ^ ?18:22
ayoungraildo, and also to provide a way for specifying the parent by nested name18:22
ayoungdom1/dom2/dom218:22
morganfainbergayoung, ++18:22
ayoungdom dom dom dom DOMMMMM!18:22
raildoayoung, ++18:22
samueldmqmakes sense to me18:22
samueldmqas well18:22
rodrigodsok... so we have a conclusion in the first topic18:23
rodrigodsthe second is token scoping18:23
rodrigodsI've made a comment that includes figures and etc here https://review.openstack.org/#/c/139824/24/specs/kilo/reseller.rst (comments in line 169)18:24
rodrigodsthink that being able to provide the namespace of a domain, can solve the issue where we have several domains with the same name in the hierarchy18:25
rodrigodswhat about dual scoped tokens, does it make sense to add a flag in the token request?18:26
morganfainbergdual scoped?18:26
morganfainbergwhat is a dual scoped token18:26
rodrigodsmorganfainberg, a token with a domain and a project scope hehe18:26
dstanek++ to what ayoung said about list_domains and the optional param to specify a root18:26
morganfainbergrodrigods, there should be zero effect if you are domain and project scoped at any given time.18:26
raildomorganfainberg, do you don't remember that we decided this in the summit? lol18:27
rodrigodsmorganfainberg, and having both scopes?18:27
rodrigodsif we have both assignments, of course18:27
morganfainbergrodrigods, correct. in the case of being on a domain - scoped to both is a non...18:27
rodrigodsUSER_DOMAIN and USER_PROJECT18:27
morganfainbergrodrigods, it's the same assignment18:27
morganfainbergyou could collapse them18:27
morganfainbergsince domain == project18:27
morganfainbergsorry domain.isa(project)18:27
openstackgerritArun Kant proposed openstack/keystone-specs: Spec for adding Barbican service as Keystone credential backend.  https://review.openstack.org/14867218:28
rodrigodsso once we add the domain-ness feature to a project18:28
*** thedodd has quit IRC18:28
rodrigodswe replicate all assignments with the USER_DOMAIN and GROUP_DOMAIN type?18:28
morganfainbergthe destinction of a grant to a domain and a grant to a project is irrelevant except in the token18:28
morganfainbergand auth_context [which could go away internal to keystone]18:28
morganfainbergyou could, absolutely18:29
morganfainbergbut check with henrynash if he sees pitfalls in that18:29
*** jsavak has joined #openstack-keystone18:29
morganfainbergi don't think we need the distinction anymore18:29
rodrigodsmorganfainberg, ++ in a first phase we would create mirrored assignment types for domains18:30
rodrigodsand in a second phase, change it to USER_TENANT and GROUP_TENANT?18:30
rodrigodsand if a entity is both (project and domain) we always return a dual scoped token?18:30
morganfainbergrodrigods, why mirrored?18:30
*** joesavak has quit IRC18:30
morganfainbergrodrigods, why do we need to duplicate data each step of the way?18:31
morganfainbergthough to be fair - there is only one issue, downgrade = lossy if we collapse domain grants to project grants18:31
rodrigodsmorganfainberg, I meant once we add the domain-ness flag, we'd create USER_DOMAIN assignments for all USER_PROJECT18:31
rodrigodsmorganfainberg, that's true18:32
* morganfainberg is becoming skeptical that SQL downgrades are ever a good idea.18:32
morganfainbergdstanek, i'm concerned about even purporting we support a SQL downgrade that is lossy18:33
morganfainbergdstanek, to be clearly stated: upgrade changes data adn there is no way to downgrade to the previous state.18:34
henrynashmorganfainberg, rodigods: sorry, been afk....18:34
rodrigodshenrynash, np, can you catch up with the discussion reading the log?18:34
morganfainbergdstanek, any thoughts on that, (cc dolphm, henrynash) ^18:34
henrynashreading18:34
samueldmqno need to duplicate assignments data, just keep project assignmtns18:35
samueldmqand then expand to dual scope if the project.isa(domain) when list_role_assignments18:35
rodrigods++18:35
samueldmqwhen migrating, besides creating one project for each domain , we should migrate that domain role assignemnts to project ones18:36
*** EmilienM|afk is now known as EmilienM18:36
samueldmqto that domain-ness project18:36
rodrigods++ so we'd always have just one type of assingment that would be USER_PROJECT18:36
rodrigodsand we return a dual scoped token when we request for a domain token18:36
morganfainbergmarekd, https://review.openstack.org/#/c/104623/ +1, needs a couple things addressed - all can be followup patches18:37
raildosounds good to me18:37
morganfainbergmarekd, but without the followup i can't +2 / added to that patch.18:37
morganfainbergmarekd, the code and tests themselves look good. - i assume we will see some extra catalog work done following this patchset?18:37
*** marg7175 has quit IRC18:38
marekdmorganfainberg: yes, it's another workitem.18:38
*** harlowja has joined #openstack-keystone18:38
marekdmorganfainberg: thanks18:38
morganfainbergmarekd, but yeah that code looks good.18:38
*** marg7175 has joined #openstack-keystone18:38
nkindermarekd: I added a few minor comments/nits to https://review.openstack.org/#/c/148229/18:40
dstanekreading up18:40
nkindermarekd: it looks good IMHO though, so I gave it a +1 and you can adjust later.18:40
marekdnkinder: thanks.18:40
nkindermarekd: I don't want to stall the momentum on +2's :)18:40
rodrigodsmorganfainberg, one concern here... since a domain-ness project doesn't contain itself, how can this dual scoped token work?18:40
rodrigodsmorganfainberg, is that a problem?18:40
morganfainbergrodrigods, not an issue you're asking for the scope of the domain or project, return both - you know if it's a domain and project easily18:41
marekdnkinder: morganfainberg so, today i wanted to move remote_ids to Protocol object, but since Protocol's PK is (id, idp_id), we would block ourselves with websso stuff :(18:41
morganfainbergrodrigods, assuming no other issues18:41
dstanekso generally speaking i would argue that you can't have a lossy downgrade because the expectations of the deployer18:41
morganfainbergdstanek, exactly. which makes this collapse icky18:42
rodrigodsmorganfainberg, but if we request for a project token, we need to specify a domain of a higher level of the hierarchy, right?18:42
morganfainbergi guess we could carry domain and project assignments18:42
*** harlowja_ has joined #openstack-keystone18:42
morganfainbergrodrigods, only if you're scoping to the name, id is fixed system wide18:42
rodrigodsmorganfainberg, yep18:42
morganfainbergrodrigods, and you'd be explicitly scoping to a target, still a non-issue18:43
rodrigodsmorganfainberg, if we are scoping using names, we'd need to add the full namespace if there are several entities with the same name in the hierarchy, correct?18:43
nkindermarekd: I think it's very important to keep websso moving forward18:43
morganfainbergrodrigods, you know what someone is scoping to, scope there, in this case if it's a domain (project flagged as domain) - you return dual scope, same object18:43
* morganfainberg tries to kill "domain-ness" that is an awful word18:44
morganfainbergand i will start -2ing patches with it :P18:44
nkindermarekd: is the idea for moving it to the protocol to avoid some of the config settings?18:44
nkinderdomain-mess18:44
morganfainbergnkinder, hey! HEY!18:44
* nkinder hides18:44
* morganfainberg stamps -2 on nkinder 18:44
henrynashmorganfainberg, rodigods: so why do we need a dual scoped token…what’s wroung with one scoped to the specific request (either project or domain, even if their IDs are the same)18:44
rodrigodshenrynash, we'd ease a lot the work on HOrizon side, for example18:45
marekdnkinder: no, to specify set of remote ids per idp/per protocol18:45
marekdnot per idp.18:45
raildorodrigods, and for nested quotas in nova....18:45
marekdbut this would mean significant change in protocol ids.18:45
*** dims has quit IRC18:46
nkindermorganfainberg: I really DO like domains.  It's just switching people over to them that's painful.18:46
*** harlowja has quit IRC18:46
morganfainbergnkinder, and we're not getting rid of them.18:46
morganfainbergnkinder, just making them less "over in the corner"18:46
morganfainbergnkinder, i agree.18:46
rodrigodsmorganfainberg, nkinder we are just making them more beautiful :)18:46
rodrigodsand flexible18:46
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617718:46
henrynashrodigods: so this isn’t because we think we need to make our current proposal work…it is to satisfy different/new requirements (from Horizon, Nova etc.)18:46
rodrigodsmorganfainberg, did you see the comment above? regarding specifying full namespace when request a token using the names18:47
stevemarmarekd, i rebased on top of marcos work (finally)18:47
nkindermarekd: ok, to allow the values to be different per protocol (the attribute is already protocol specific in the config via remote_id_attribute), right?18:47
samueldmqhenrynash, yes18:47
rodrigodshenrynash, don't think so... we'd keep things more generic18:47
rodrigodsand easy to handle18:47
*** dims has joined #openstack-keystone18:47
rodrigodshenrynash, also... we'd finally ease other components to enter the domain world (if it is desirable) :)18:49
openstackgerritMerged openstack/keystone: Make role manager refer to role cache config options  https://review.openstack.org/15129218:50
*** openstackgerrit has quit IRC18:50
*** openstackgerrit has joined #openstack-keystone18:51
marekdstevemar: thanks, but we still need to wait for his next patch with multiple remote_ids.18:51
marekdstevemar: oh, with remote_ids in general.18:51
morganfainberghenrynash, and yes we could just scope domain or project as requested. *shrug* we could also just always ignore domain scope in tokens and keep it for compat down the line [once project == domain]18:51
marekdhe says he wants to carry on with the patch.18:51
morganfainbergerm domain.is_a(project)18:51
stevemarmarekd, carry on with it?18:52
stevemarmarekd, more to do?18:52
stevemaroh i guess remote_id per protocol?18:52
marekdstevemar: so, his current patch assumes there is one remote_id for idp.18:53
marekdwe need remote_idps18:53
nkinderyou mean remote_ids?18:53
marekdnkinder: yes.18:53
*** ayoung has quit IRC18:53
openstackgerritRodrigo Duarte proposed openstack/keystone: Implements parents_as_ids query param  https://review.openstack.org/14856718:54
nkindermarekd: which patch/review is this?18:54
openstackgerritRodrigo Duarte proposed openstack/keystone: Implements subtree_as_ids query param  https://review.openstack.org/14861818:54
stevemarmarekd, use cfg.MultiStrOpt :)18:54
henrynashrodigods: so picking up on a few other questions from the irc log, so once the migration is over and I want to create a new domain that is not a top level domain, I would do PUT /domain {……parent_id=parent_domain/project_id}?18:54
rodrigodshenrynash, would do PATCH /projects/<project_id> passing the "domain-ness" flag as True18:55
rodrigodshenrynash, ah, ok...18:55
rodrigodsdidn't get that you were talking about create18:55
rodrigodshenrynash, yes... something like that18:56
rodrigodsraildo, any thoughts? ^18:56
marekdstevemar: it may be confusing but if you look at the spec it mentiones *remote_ids* whereas in the current impl in the code there is remote_id.18:57
marekdnkinder: ^^18:57
marekdnkinder: it's https://review.openstack.org/#/c/148229/18:57
raildohenrynash, rodrigods I think that you have to use POST /project set the parent_id, domain_id, and set the domain-ness flag as True18:58
marekdand the impl is mentioned somewhere in the references.18:58
nkindermarekd: Thanks.  Didn't see there was an implementation review for that spec18:58
marekdnkinder: look at the bottom. In fact, this spec somehow evolved from the impl which was a fix for a bug :-)18:59
marekdwe need it to make users life easier and to make websso doable.18:59
nkindermarekd: yes, I remember the bug.  I need to write an OSSN for it.18:59
marekdnkinder: yep :-)18:59
marekdstevemar: so, in general there will be yet another patch on top of marcos work :-)18:59
marekdit's a tl;dr18:59
nkindermarekd: So is there anything else holding yup the spec, or just one more +2?19:00
marekdnkinder: imho yet another +219:00
nkinderyeah, it seems complete to me19:00
marekdunless we want a revolution in OS-FEDERATION :-)19:01
henrynashrodigods, raildo: so we should probably think about what the conceptual model we want to end up with…and so we can be taking steps towards it...19:01
marekdbut i'dont want19:01
rodrigodshenrynash, yes19:01
raildohenrynash, sure19:01
rodrigodsraildo was arguing that we may drop the /domains API someday?19:01
stevemarmarekd, i'm just eager to get this done :)19:02
nkindermarekd: I just want to push what we have forward so it's a complete solution across Horizon.  No revolutions please. :)19:02
rodrigodsthere is also the option to support both ways19:02
henrynashraildo: (for clarity, meaning no time soon, but) you mean everything would be done via the project API, and the is_domain flag?19:03
raildohenrynash, for now, I believe that we can keep create root domain in the domain API (we can maintain the compatibility)19:04
raildohenrynash, and i want to create project domain-ness in the project API19:04
raildohenrynash, so in a  future is more ease drop the domain API or something like that, makes sense?19:05
henrynashraildo: ok, so the conceptual proposal is (just trying to understand it): If you are manipulation a top level domain, you sus ethe domain API, for subdomains you MUST use the project API ?19:06
raildohenrynash, yes... you call subdomains, I think in project domain-ness , but yes :)19:07
morganfainbergtopol, http://lists.openstack.org/pipermail/openstack-dev/2015-January/055586.html19:07
*** gtt116__ has quit IRC19:07
rodrigodsraildo, henrynash I'd argue to use both...19:07
rodrigodsso we'd drop one of them in the future19:08
rodrigodsdepending on how things evolve19:08
*** gtt116 has joined #openstack-keystone19:08
morganfainbergdstanek, http://lists.openstack.org/pipermail/openstack-dev/2015-January/055586.html re migrations19:08
raildohenrynash, its a alternative... and internally for both API calls we create a project domain-ness..19:09
morganfainberghenrynash, raildo, can i ask a huge favor19:09
morganfainbergstop using the word domain-ness19:10
morganfainbergi'm serious19:10
henrynashmorganfaiberg: I didn’t :-)19:10
*** nkinder has quit IRC19:10
morganfainbergit's an awful word19:10
rodrigodsmorganfainberg, ++ can with the "is_domain" flag?19:10
rodrigodsheh19:10
morganfainbergperfect19:10
henrynashmorganfainberg: even though I am to blame for coining it origionally...19:10
morganfainbergwaaay better and easier to explain to people19:10
rodrigodsmorganfainberg, right19:11
rodrigodsis_domain ftw19:11
raildomorganfainberg, ok :)19:11
rodrigodsmorganfainberg, what do you think about the ability to create subdomains via both /domains and /projects API?19:11
dstanekmorganfainberg: totally agree19:12
*** sriram has left #openstack-keystone19:12
henrynashrodigods, morganfainberg: it seems to me that the conceptual future model is that you create a project and optionally mark it as is_domain=True, so the current Domain API would eventually eb deprecated…so not sure if we want to extend the current one19:13
rodrigodshenrynash, sounds good to me19:14
rodrigodsand if you cores and our PTL morganfainberg agree with that assumption for now, I think we have lots of remaining points of the reseller spec covered19:15
morganfainberghenrynash, that was my view19:16
morganfainbergthough removing V3 domain specific stuff is a much much different thing that i didn't want to tackle today (or even tomorrow)19:16
morganfainbergOMG I STILL HAVENT HAD COFFEE19:16
* morganfainberg grumps19:16
raildolol19:16
rodrigodsif we could send images via IRC, we'd send a huge picture of a coffee mug here19:16
henrynashmorganfainberg: agrred…this is future…no deprecation in J19:17
henrynashoops, i mean K19:17
rodrigods++19:18
henrynashI’m off to mull on this whole issue  a bit more….19:19
rodrigodswe are going to update the spec and than ask for you guys to see if it is ok19:20
rodrigodshope it makes the kilo 2 deadline19:20
*** henrynash has quit IRC19:20
*** breton_ has joined #openstack-keystone19:20
*** breton_ is now known as breton19:21
lhchenghey folks, does keystoneclient shell supposed to support keyring? It keeps on asking me for password even if I have keyring setup, wondering if that is by design or bug.19:22
lhchengTriaging this bug: https://bugs.launchpad.net/python-keystoneclient/+bug/135756719:22
TempLPBugBotLaunchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" (affected: 1, heat: 8) [Undecided,New] - Assigned to Shraddha Pandhe (shraddha-pandhe)19:22
*** dims has quit IRC19:26
morganfainbergrodrigods, i *think* that is totally possible.19:28
*** henrynash has joined #openstack-keystone19:32
*** ChanServ sets mode: +v henrynash19:32
morganfainbergrodrigods, we can work through the last isseus with the spec today/tomorrow19:33
*** aix has quit IRC19:35
*** dims has joined #openstack-keystone19:36
*** dutsmoc has quit IRC19:38
*** comstud has joined #openstack-keystone19:38
rodrigodsmorganfainberg, great! already working on it19:40
raildomorganfainberg, :D19:40
mfischeverytime I get an email from morganfainberg I realize too late that its a trick question and he's going to take away a feature ;)19:42
morganfainbergmfisch, *note to self, send scary emails to mfisch directly*19:42
mfisch"hey so I'm curious, do you really use your basement?" (next week morgan moves in)19:43
mfischactually I'm with you on downgrades morganfainberg, just trying to amuse myself after an interesting day19:43
morganfainbergmfisch, hey this time i proposed up front we should remove it (in the dev thread) AND linked that in the operator thread19:43
mfischI would be surprised if anyone does rollbacks19:43
morganfainbergmfisch, the only thing i ask is if oyu agree please say so, more voices in this case may make things better / easier for everyone19:44
mfischI did reply19:44
morganfainbergah haven't seen it yet then19:44
morganfainberg:)19:44
morganfainbergmfisch, thanks! :)19:44
morganfainbergi would call someone crazy for doing a rollback tbh19:44
mfischits like rolling back an os package19:45
mfischit might work, but you'd be the first to try it19:45
mfischgood luck19:45
morganfainbergbecause RPM does such a good job of that19:45
morganfainbergor even deb19:45
morganfainbergno really19:45
morganfainbergtry it19:45
morganfainberg:P19:45
mfischwhen we do an upgrade we just halt the db on the cluster, leave one node up19:46
mfischand only rejoin those when we know is good19:46
* mfisch has been fighting db issues all morning so this is fresh19:46
*** stevemar2 has joined #openstack-keystone19:47
*** ChanServ sets mode: +v stevemar219:47
*** ajayaa has quit IRC19:47
*** stevemar has quit IRC19:47
morganfainbergyep19:47
*** arif-ali_ has joined #openstack-keystone19:49
*** breton_ has joined #openstack-keystone19:49
*** SpamapS_ has joined #openstack-keystone19:51
*** henrynash has quit IRC19:53
*** atiwari1 has joined #openstack-keystone19:54
*** dims_ has joined #openstack-keystone19:56
*** rodrigod` has joined #openstack-keystone19:56
*** arif-ali has quit IRC19:56
*** breton has quit IRC19:56
*** SpamapS has quit IRC19:56
*** rodrigods has quit IRC19:56
*** a2hill has quit IRC19:56
*** atiwari has quit IRC19:56
*** arif-ali_ is now known as arif-ali19:56
*** ptoohill has joined #openstack-keystone19:56
*** dims has quit IRC19:58
*** thedodd has joined #openstack-keystone20:00
*** dims_ has quit IRC20:00
*** andreaf has quit IRC20:00
*** zz_avozza is now known as avozza20:02
*** openstackgerrit has quit IRC20:04
*** openstackgerrit has joined #openstack-keystone20:04
*** nellysmitt has quit IRC20:07
*** gabriel-bezerra has joined #openstack-keystone20:07
*** _cjones_ has quit IRC20:07
*** nellysmitt has joined #openstack-keystone20:07
*** nellysmitt has quit IRC20:12
*** jsavak has quit IRC20:14
morganfainbergstevemar2: wow shady there man. How can I be sure who I'm talking to? What did you do to stevemar? ;)20:18
stevemar2morganfainberg, i took his isp and made is even more terrible20:19
stevemar2it*20:19
morganfainbergOh. Kind of like my phone from att uverse20:20
morganfainbergzzzeek: thanks for the reply! I figured you'd jump in :)20:23
zzzeeksure20:23
*** SpamapS_ is now known as SpamapS20:23
morganfainbergAnd I figured that would be your response ;)20:23
*** fifieldt has quit IRC20:24
*** SpamapS has quit IRC20:24
*** SpamapS has joined #openstack-keystone20:24
*** fifieldt has joined #openstack-keystone20:24
morganfainbergmfisch: the cruft below the line is insane. I feel bad when companies mandate that stuff. :(20:26
morganfainberg /comfort20:26
morganfainbergBecause somehow i bet that those disclaimers have about as many teeth as a blog post saying "don't read this"20:27
mfischyeah, its pretty terrible and embarassing20:27
morganfainbergThat is one reason I use gmail for my OpenStack email.20:28
morganfainbergNot that hp mandates it today.20:28
openstackgerritMorgan Fainberg proposed openstack/keystone: Remove deprecated methods and functions in token subsystem  https://review.openstack.org/15138120:57
*** henrynash has joined #openstack-keystone21:00
*** ChanServ sets mode: +v henrynash21:00
morganfainberghmm21:04
morganfainbergI'm really digging rust21:04
morganfainbergkindof want to see where it goes21:04
*** henrynash has quit IRC21:04
topolmorganfainberg, why did you want me to look at  http://lists.openstack.org/pipermail/openstack-dev/2015-January/055586.html I wasnt sure of the context21:04
morganfainbergtopol, you have all the context by reading it.21:04
morganfainbergtopol, downgrades kindof suck21:04
morganfainbergesp. from a data perspective21:05
topolOk. I will read21:05
*** stevemar2 has quit IRC21:05
*** stevemar2 has joined #openstack-keystone21:06
*** ChanServ sets mode: +v stevemar221:06
morganfainbergthis has ... almost everything i want python to have: http://www.rust-lang.org21:07
morganfainbergkindof sexy all around. can't wait to see 1.021:08
bknudson"threads without data races" -- I'm sure.21:08
morganfainberg* In theory. Rust is a work-in-progress and may do anything it likes up to and including eating your laundry.21:09
*** dims has joined #openstack-keystone21:09
bknudson"all sorting in O(1)"!21:09
dstanekbknudson: sounds like magic21:12
bknudson"all programs guaranteed to terminate"21:13
dstaneki've never seen one that doesn't :-)21:13
*** dims has quit IRC21:14
*** _cjones_ has joined #openstack-keystone21:19
*** pnavarro has quit IRC21:25
*** rodrigod` is now known as rodrigods21:31
*** rodrigods has quit IRC21:31
*** rodrigods has joined #openstack-keystone21:31
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: Reseller  https://review.openstack.org/13982421:32
*** radez_g0n3 is now known as radez21:32
rodrigodsmorganfainberg, thanks for the conversation today, tried to add all points there ^21:32
*** topol has quit IRC21:38
*** dims has joined #openstack-keystone21:39
*** dims has quit IRC21:40
*** afazekas_ has quit IRC21:46
*** gabriel-bezerra has quit IRC21:52
*** nkinder has joined #openstack-keystone21:55
*** gabriel-bezerra has joined #openstack-keystone21:56
openstackgerritBrant Knudson proposed openstack/keystone: Change oslo.utils to oslo_utils  https://review.openstack.org/14801921:58
openstackgerritBrant Knudson proposed openstack/keystone: Change oslo.serialization to oslo_serialization  https://review.openstack.org/14802521:58
openstackgerritBrant Knudson proposed openstack/keystone: Change oslo.config to oslo_config  https://review.openstack.org/14525021:59
openstackgerritBrant Knudson proposed openstack/keystone: Change oslo.db to oslo_db  https://review.openstack.org/14802921:59
openstackgerritBrant Knudson proposed openstack/keystone: Change oslo.messaging to oslo_messaging  https://review.openstack.org/14802821:59
*** radez is now known as radez_g0n322:00
*** jamielennox|away is now known as jamielennox22:03
*** gabriel-bezerra has quit IRC22:04
*** joesavak has joined #openstack-keystone22:07
rodrigodslong day -> beer day22:08
*** chlong has quit IRC22:08
*** nellysmitt has joined #openstack-keystone22:08
*** nellysmitt has quit IRC22:13
*** samueldmq_ has joined #openstack-keystone22:18
stevemar2lhcheng, if you're around i'd like your eyes on a patch :)22:20
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113722:22
stevemar2this one ^22:22
*** r-daneel has quit IRC22:22
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113722:23
*** timcline has quit IRC22:26
*** timcline has joined #openstack-keystone22:26
openstackgerritgordon chung proposed openstack/keystonemiddleware: make audit event scoped to request session and not middleware  https://review.openstack.org/14930022:28
openstackgerritgordon chung proposed openstack/keystonemiddleware: make audit event scoped to request session and not middleware  https://review.openstack.org/14930022:30
*** timcline has quit IRC22:31
lhchengstevemar2: aha so... I wonder why you're also up, there's actually two stevemar...  :P22:32
*** mattfarina has quit IRC22:32
stevemar2lhcheng, that other one is a jerk22:32
lhchenglol, so he's in charge of doing reviews? :)22:32
stevemar2hehe22:33
lhchengjamielennox: when you get the chance, can you look at: https://bugs.launchpad.net/python-keystoneclient/+bug/135756722:34
TempLPBugBotLaunchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" (affected: 1, heat: 8) [Undecided,New] - Assigned to Shraddha Pandhe (shraddha-pandhe)22:34
lhchengjamielennox: the keyring doesn't work with shell, just wanted to confirm if by design or bug22:35
jamielennoxlhcheng: it's not by design but i'm not surprised22:35
jamielennoxthat code was always a little flaky22:35
*** timcline has joined #openstack-keystone22:36
openstackgerritMorgan Fainberg proposed openstack/keystone: Remove deprecated methods and functions in token subsystem  https://review.openstack.org/15138122:36
lhchengjamielennox: we got a patch internally to fix that, the dev was just waiting for someone to confirm it is was a valid bug.22:36
lhchengjamielennox: we'll have a patch up soon!22:37
jamielennoxlhcheng: sure put up the patch22:37
stevemar2lhcheng, keyring support is flakey at best22:38
*** abhirc has quit IRC22:40
*** timcline has quit IRC22:40
lhchengstevemar2: hehe figured..  openstackclient will be better! :D22:43
*** markvoelker has quit IRC22:46
jamielennoxstevemar2: does OSC support any keyring stuff?22:46
*** markvoelker_ has joined #openstack-keystone22:47
stevemar2jamielennox, nope, precisely for the reasons stated above, flakeyness22:47
*** avozza is now known as zz_avozza22:47
*** henrynash has joined #openstack-keystone22:48
*** ChanServ sets mode: +v henrynash22:48
jamielennoxstevemar2: tought so22:48
jamielennoxstevemar2: check out https://review.openstack.org/#/c/149175/ i'm not finished with it but its how i think keyring support will work22:48
jamielennoxor at least be based on22:48
stevemar2jamielennox, though i think that, or at least per-user-configs is next on the horizon22:49
jamielennoxyea, i think dtroyer is keen to offload a lot of this stuff to os-cloud-config22:50
stevemar2jamielennox, like maybe a dot file with some user-data, or something related to 'cloud config'22:50
stevemar2yeah22:50
jamielennoxit's just shifting the load though, there's still not a good answer yet22:50
stevemar2jamielennox, and of course now that we have a half-decent built-in API, i think the plan is to add neutron support22:50
jamielennoxstevemar2: cool, i was just going to write something that needed to create a network from the cli22:51
jamielennoxstevemar2: wherever possible i default to using OSC for that now22:51
*** openstackgerrit has quit IRC22:51
*** openstackgerrit has joined #openstack-keystone22:51
jamielennoxthat sort of work22:51
*** tellesnobrega_ has joined #openstack-keystone22:51
stevemar2jamielennox, oh nice, yeah support for a the22:52
stevemar2'network' resource is there22:52
stevemar2but not much else22:52
*** marg7175 has quit IRC22:53
*** henrynash has quit IRC22:53
openstackgerritgordon chung proposed openstack/keystonemiddleware: move add event creation logic to keystonemiddleware  https://review.openstack.org/14940522:53
openstackgerritgordon chung proposed openstack/keystonemiddleware: move add event creation logic to keystonemiddleware  https://review.openstack.org/14940522:56
*** henrynash has joined #openstack-keystone23:00
*** ChanServ sets mode: +v henrynash23:00
*** henrynash has quit IRC23:01
*** zz_avozza is now known as avozza23:03
*** gordc has quit IRC23:03
marekdstevemar2: nkinder it's always a question whether we should just do things or maybe we should do small revolution today in order to avoid big revolution tomorrow :)23:05
stevemar2marekd, big revolutions all the tiem!23:06
stevemar2marekd, why are you up at this hour?23:06
marekdhad a dinner w/ friends today and they just left :-)23:07
marekdit's pretty standard work hour for you, isn't it? :-)23:08
marekdstevemar2: btw, looks like oidc also support something like remote_id (http://openid.net/specs/openid-connect-basic-1_0.html#IDToken ,see iss), so we are safe to go.23:08
openstackgerritMerged openstack/keystone: Fix up _ldap_res_to_model for ldap identity backend  https://review.openstack.org/15063123:08
stevemar2marekd, ++23:09
openstackgerritMerged openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/14915823:09
*** marg7175 has joined #openstack-keystone23:10
*** spandhe has joined #openstack-keystone23:12
spandhehey lhcheng! wanted to discuss https://bugs.launchpad.net/python-keystoneclient/+bug/1357567 : issue with keyring caching23:14
TempLPBugBotLaunchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" (affected: 1, heat: 8) [Undecided,New] - Assigned to Shraddha Pandhe (shraddha-pandhe)23:14
spandheHi jamielennox ! I work with lhcheng.. wanted to discuss https://bugs.launchpad.net/python-keystoneclient/+bug/1357567 with you guys.. Is it confirmed that its a valid bug?23:15
TempLPBugBotLaunchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" (affected: 1, heat: 8) [Undecided,New] - Assigned to Shraddha Pandhe (shraddha-pandhe)23:15
spandheI will update the links in the description23:15
jamielennoxspandhe: i haven't confirmed it, but i'm pretty sure you're right23:16
jamielennoxit was always in the wrong position, keyring should be part of the shell and not part of the client23:16
lhchenghey spandhe! yeah, most likely it is broken lol23:16
spandhejamielennox: ok.. thanks.. I fixed it internally with a patch.. I wil send it out for review in some time..23:17
jamielennoxspandhe: sounds good23:17
openstackgerritBrant Knudson proposed openstack/keystone: Consistently use oslo_config.cfg.CONF  https://review.openstack.org/14736723:17
*** dims has joined #openstack-keystone23:22
*** dims has quit IRC23:25
*** dims has joined #openstack-keystone23:25
*** marg7175 has quit IRC23:26
*** marg7175 has joined #openstack-keystone23:35
morganfainbergjamielennox, we should revisit pecan if we can23:39
morganfainbergjamielennox, https://review.openstack.org/#/c/150821/ would be so easy to add to keystone as well23:39
jamielennoxmorganfainberg: ok, i agree23:39
morganfainbergtrivial microversioning would be a win doe us.23:39
jamielennoxit was a really hard rebase last time i looked23:40
morganfainbergs/doe/for23:40
morganfainbergyeah :(23:40
morganfainberglets target post k223:40
jamielennoxhmm, not sure i agree on the microversioning concept23:40
morganfainbergjamielennox, we're going to need it.23:40
jamielennoxok, i have a few things on my plate first but i'll try and redo that patch23:40
morganfainbergjamielennox, i am not going to increment a major api version *ever* again if i have anything to say about it23:40
morganfainbergno rush23:40
morganfainberglike i said, lets look post k223:40
jamielennoxi'll let you konw when i do, because it touches so much it really needs to get a propose then +A or you are always rebasing23:41
morganfainbergworst case we aim it to land first thing in L23:41
morganfainbergso we Freeze, deal with bugs, and as soon as we have RC land it23:41
*** thedodd has quit IRC23:41
*** dims has quit IRC23:41
jamielennoxmicroversioning is going to make openstack so much harder to deal with23:41
morganfainbergi know23:41
*** dims has joined #openstack-keystone23:42
morganfainbergi expect to use it extremely infrequently for us23:42
morganfainbergbut frankly we need an answer to "how do we change APIs"23:42
morganfainbergshort of keystone223:42
morganfainberg[which also is likely off the table]23:42
jamielennoxmy hope was that all this auth plugin and unversioned endpoints stuff would be ready before this was needed23:42
jamielennoxthen we had a story for how to progress through major API versions23:42
morganfainbergthe issue isn't the endpoints though... or even versioning23:43
morganfainbergit's the lack of x-version support23:43
jamielennoxi don't believe semver solves all problems, but it is a nice way of communication things if you are willing to bump majors every now and the23:43
jamielennoxn23:43
morganfainbergand how much work it is to integrate with the "next great version of X"23:43
morganfainbergfair point, but lets just say if we had keystone 3.5.x and moving to 4.x, even slightly breaking would be a big deal :(23:44
morganfainberglook how hard it's been to get to v323:44
morganfainbergand that has stayed the same for a looong time [the parts people would have been using]23:44
jamielennoxright integration is the problem - and i know that python is not the only set of clients but if we fix that story then everyone else would have to adapt as well23:44
jamielennoxthe problem with v3 wasn't the new api though23:44
jamielennoxstill sin't23:44
morganfainbergwell, indirectly it was23:45
morganfainberganyway23:45
morganfainbergsomething to do not-this-week23:45
*** marg7175 has quit IRC23:47
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Add validate token for v3  https://review.openstack.org/14214723:47
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Tests use keep_blank_values when parse_qs  https://review.openstack.org/15147123:47
openstackgerritMerged openstack/keystone: Documentation fix for Keystone Architecture  https://review.openstack.org/15129423:48
openstackgerritMerged openstack/keystone: Use RequestBodySizeLimiter from oslo.middleware  https://review.openstack.org/14469723:48
*** chrisshattuck has quit IRC23:49
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113723:51
stevemar2morganfainberg, just a heads up - submitted cadf everywhere patch ^23:51
stevemar2so some of that conflicts with henrynashs restructure work23:52
stevemar2well, it will anyway, i need the context from some of the functions23:53
*** chlong has joined #openstack-keystone23:53
*** abhirc has joined #openstack-keystone23:56
*** bknudson has quit IRC23:57

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