Thursday, 2015-07-23

*** topol has quit IRC00:01
*** zzzeek has quit IRC00:13
*** ankita_wagh has quit IRC00:22
*** btully has quit IRC00:26
*** 77CAAEJLH has quit IRC00:28
*** snapdey has joined #openstack-keystone00:28
*** gyee has quit IRC00:33
*** snapdey has quit IRC00:35
*** ankita_wagh has joined #openstack-keystone00:35
*** dguerri is now known as dguerri`00:39
*** btully has joined #openstack-keystone00:41
*** bknudson has joined #openstack-keystone00:47
*** ChanServ sets mode: +v bknudson00:47
*** hightall has joined #openstack-keystone00:48
openstackgerritMerged openstack/keystone: Move cli.py into keystone.cmd  https://review.openstack.org/20322400:49
openstackgerritMerged openstack/keystone: move clean.py into keystone/common  https://review.openstack.org/20329700:52
*** chlong has quit IRC00:52
openstackgerritMerged openstack/keystone: Move backends.py to keystone.server  https://review.openstack.org/20330100:52
*** esp has left #openstack-keystone00:53
*** ankita_wagh has quit IRC00:53
*** browne has quit IRC00:56
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/20430000:56
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/20430000:57
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/20430000:58
*** lhcheng has quit IRC01:01
*** mylu has joined #openstack-keystone01:07
openstackgerritBrant Knudson proposed openstack/keystone: Documentation for other services  https://review.openstack.org/20480101:07
*** drjones has joined #openstack-keystone01:10
bigjoolsmorganfainberg: I want to do a new ldap driver that doesn't depend on any ldap info for group memberships01:12
*** _cjones_ has quit IRC01:12
*** drjones has quit IRC01:12
*** _cjones_ has joined #openstack-keystone01:13
*** piyanai has joined #openstack-keystone01:21
*** ankita_wagh has joined #openstack-keystone01:30
*** hightall has quit IRC01:31
jamielennox<bigjools> i love the pain01:31
bigjoolsmy life is one large pain01:31
openstackgerritBrant Knudson proposed openstack/keystone: Fix s3.core for py34  https://review.openstack.org/20480401:42
*** hightall has joined #openstack-keystone01:44
*** dguerri` is now known as dguerri01:48
*** _cjones_ has quit IRC01:49
*** topol has joined #openstack-keystone01:50
*** ChanServ sets mode: +v topol01:50
*** EmilienM|off is now known as EmilienM01:52
*** topol has quit IRC01:54
*** spandhe has quit IRC01:55
*** dguerri is now known as dguerri`01:58
*** shangxdy has joined #openstack-keystone01:59
*** fangzhou has quit IRC02:05
openstackgerritBrant Knudson proposed openstack/keystone: Fix test_exception.py for py34  https://review.openstack.org/20480702:07
openstackgerritBrant Knudson proposed openstack/keystone: Fix test_exception.py for py34  https://review.openstack.org/20480702:08
*** chenhong has joined #openstack-keystone02:10
*** mylu has quit IRC02:10
*** chlong has joined #openstack-keystone02:11
*** chenhong1 has joined #openstack-keystone02:12
*** chenhong has quit IRC02:13
*** mylu has joined #openstack-keystone02:14
*** chenhong has joined #openstack-keystone02:15
*** mylu has quit IRC02:16
*** chenhong1 has quit IRC02:17
*** mylu has joined #openstack-keystone02:17
*** mylu has quit IRC02:20
*** mylu has joined #openstack-keystone02:20
*** mylu has quit IRC02:21
*** mylu has joined #openstack-keystone02:22
*** iamjarvo has joined #openstack-keystone02:23
morganfainbergbigjools: sure - though, to include it in tree youll need to also convince the other cores.02:31
morganfainbergbigjools: fyi, we are going to start working on moving to ldap3 and away from python-ldap02:31
bigjoolsmorganfainberg: this all stems from the fact that the federation mapping would now require group memberships in the json blob02:32
bigjoolsI was thinking that the option to map to local users, which also come from the ldap, solves the problem of unwieldy json blobs02:34
bigjoolsmaybe I should start a ML thread02:35
*** mylu has quit IRC02:37
*** ankita_wagh has quit IRC02:39
openstackgerritjiaxi proposed openstack/keystone: Suppressing the request when creating endpoint with invalid urls  https://review.openstack.org/20051202:43
*** iamjarvo has quit IRC02:44
*** iamjarvo has joined #openstack-keystone02:45
*** richm has quit IRC02:47
*** browne has joined #openstack-keystone02:48
*** hakimo_ has joined #openstack-keystone02:52
*** iamjarvo has quit IRC02:52
*** hakimo has quit IRC02:55
*** piyanai has quit IRC02:57
*** btully has quit IRC02:58
*** kiran-r has joined #openstack-keystone03:03
*** bradjones has quit IRC03:03
*** bradjones has joined #openstack-keystone03:04
*** bradjones has quit IRC03:04
*** bradjones has joined #openstack-keystone03:04
*** stevemar has joined #openstack-keystone03:06
*** ChanServ sets mode: +v stevemar03:06
*** piyanai has joined #openstack-keystone03:07
*** htruta_ has quit IRC03:08
*** stevemar has quit IRC03:11
*** kiran-r has quit IRC03:13
*** ankita_wagh has joined #openstack-keystone03:14
*** shangxdy has quit IRC03:16
morganfainbergbigjools: ++ ml thread will help03:17
*** hightall has quit IRC03:19
*** stevemar has joined #openstack-keystone03:22
*** ChanServ sets mode: +v stevemar03:22
*** davechen has joined #openstack-keystone03:25
*** jasonsb has joined #openstack-keystone03:35
*** dguerri` is now known as dguerri03:36
*** snapdey has joined #openstack-keystone03:36
*** snapdey has joined #openstack-keystone03:37
*** snapdey has quit IRC03:42
*** topol has joined #openstack-keystone03:45
*** ChanServ sets mode: +v topol03:45
*** dguerri is now known as dguerri`03:46
*** lhcheng has joined #openstack-keystone03:48
*** ChanServ sets mode: +v lhcheng03:48
*** piyanai has quit IRC03:49
*** topol has quit IRC03:50
*** HenryG has quit IRC04:09
*** mordred has quit IRC04:11
*** HenryG has joined #openstack-keystone04:12
*** ayoung has quit IRC04:17
*** mordred has joined #openstack-keystone04:24
*** iamjarvo has joined #openstack-keystone04:37
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/20483604:39
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/19725404:39
*** Kennan has quit IRC04:41
*** Kennan has joined #openstack-keystone04:42
openstackgerritMerged openstack/python-keystoneclient: Make OAuth testcase use actual request headers  https://review.openstack.org/20467804:45
openstackgerritSteve Martinelli proposed openstack/keystone: switch to oslo.cache  https://review.openstack.org/19587304:49
*** fangzhou has joined #openstack-keystone04:53
*** rm_work|away is now known as rm_work05:01
*** kiran-r has joined #openstack-keystone05:05
*** ankita_wagh has quit IRC05:09
*** ankita_wagh has joined #openstack-keystone05:10
*** btully has joined #openstack-keystone05:10
*** ankita_wagh has quit IRC05:14
*** kiran-r has quit IRC05:18
*** dguerri` is now known as dguerri05:24
*** chenhong1 has joined #openstack-keystone05:27
*** chenhong has quit IRC05:29
*** iamjarvo has quit IRC05:29
*** dguerri is now known as dguerri`05:34
openstackgerritjiaxi proposed openstack/keystone: Suppressing the request when creating endpoint with invalid urls  https://review.openstack.org/20051205:38
*** iamjarvo has joined #openstack-keystone05:38
*** henrynash has joined #openstack-keystone05:48
*** ChanServ sets mode: +v henrynash05:48
*** hrou has quit IRC05:50
*** iamjarvo has quit IRC05:51
*** fangzhou has quit IRC05:51
*** afazekas_ has joined #openstack-keystone05:56
marekdstevemar: still here?05:56
*** Moh_ has joined #openstack-keystone05:56
stevemarmarekd: yep05:56
marekdstevemar: thanks for the fixing oauthlib. I am wondering what happens now if I install ksc from pip? will it fetch oauthlib1.0.0 ?05:57
*** ankita_wagh has joined #openstack-keystone05:57
Moh_Hi there, is it possible to assign roles to group instead of users, via keystone APIs V3?05:57
marekdMoh_: yes.05:58
Moh_<+marekd>: Thanks, but I found nothing at: http://developer.openstack.org/api-ref-identity-v3.html05:58
marekdMoh_: for instance in openstack command line simply use --group <gid> swtich instead of --user <id>05:58
marekdi suggest examining openstack help role add05:58
Moh_<+marekd>: fine, but what about assigning roles to a pair of both group-domain or group-project? I found this concept here: http://www.madorn.com/keystone-v3-api.html#.VbCAZjuUe0206:00
marekd$ openstack Moh_ what stops you from creating two requests ?06:00
marekdi would then create two role assignments.06:01
stevemarmarekd: np - if you install from master ksc it'll install 1.0.006:02
stevemaroauthlib1.0.006:02
Moh_<+marekd>: What do you mean?06:02
stevemarMoh_: just create 2 requests06:03
stevemarMoh_: `os role add my_role --group the_group --domain the_domain`06:04
stevemarMoh_: `os role add my_role --group the_group --project the_project`06:04
stevemarwhat the heck is madorn.com06:04
marekdstevemar: not master, the frozen version from pip.06:04
marekdstevemar: Matt Dorn :P06:05
Moh_<+marekd>: Oh, the first one assigns a role to a group in a domain scope, and the second one assign role in project scope. Is it?06:05
stevemarmarekd: i have no idea who he is06:05
stevemarMoh_: you got it boss06:05
marekdMoh_: yes06:05
marekdstevemar: neither do I know him06:05
stevemarmarekd: i think it'll still install oauthlib1.0.0 since it's uncapped in requirements06:05
Moh_<+marekd>: Thanks alot.06:06
marekdMoh_: you are welcome06:06
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/20490306:06
stevemarmarekd: 99% sure that will happen (install 1.0.0)06:06
marekdstevemar: ah, actually never mind....oauthlib sits in test-requirements so it doesn't matter in a 'daily use'06:06
stevemarmarekd: correct06:08
stevemarjust for tests and shtuffff06:09
stevemarmarekd: you are up late06:10
stevemarerr... early06:10
*** boris-42 has quit IRC06:12
*** ankita_wagh has quit IRC06:13
*** afazekas_ has quit IRC06:14
*** Moh_ has quit IRC06:14
*** lhcheng has quit IRC06:18
marekdi need to wake up early (6.30am) if i have a car in Geneva and don't want to get stuck in the traffic.06:20
marekdbut, the good side is that i can meet then some late folks and I am not completely alone here :-)06:20
*** woodster_ has quit IRC06:22
stevemarmarekd: that's true!06:29
*** spandhe has joined #openstack-keystone06:30
*** pnavarro has joined #openstack-keystone06:33
*** snapdey has joined #openstack-keystone06:43
*** kiran-r has joined #openstack-keystone06:43
*** pnavarro has quit IRC06:44
*** snapdey has quit IRC06:47
*** chlong has quit IRC06:49
*** stevemar has quit IRC06:52
*** stevemar has joined #openstack-keystone06:52
*** ChanServ sets mode: +v stevemar06:52
*** stevemar has quit IRC06:55
*** browne has quit IRC07:10
*** dguerri` is now known as dguerri07:13
*** e0ne has joined #openstack-keystone07:15
openstackgerritMerged openstack/keystone: Implement backend filtering on membership queries  https://review.openstack.org/17975807:15
*** fhubik has joined #openstack-keystone07:18
*** fhubik is now known as fhubik_afk07:18
*** rletrocquer has joined #openstack-keystone07:20
*** ParsectiX has joined #openstack-keystone07:21
*** dguerri is now known as dguerri`07:22
openstackgerritBoris Bobrov proposed openstack/python-keystoneclient: Remove unused time_patcher  https://review.openstack.org/20477107:22
*** spandhe has quit IRC07:37
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/20483607:41
*** tsubic has joined #openstack-keystone07:42
*** fhubik_afk is now known as fhubik07:43
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/20313707:44
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/20483607:47
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/20493707:50
*** btully has quit IRC07:53
*** bdossant has joined #openstack-keystone07:53
*** fhubik has quit IRC07:59
*** fhubik has joined #openstack-keystone07:59
*** jistr has joined #openstack-keystone08:02
*** dguerri` is now known as dguerri08:06
*** lhcheng has joined #openstack-keystone08:07
*** ChanServ sets mode: +v lhcheng08:07
openstackgerritMerged openstack/keystone: Updating sample configuration file  https://review.openstack.org/20430008:11
*** lhcheng has quit IRC08:11
*** spandhe has joined #openstack-keystone08:15
*** jecarey has quit IRC08:16
*** ParsectiX_ has joined #openstack-keystone08:21
*** spandhe_ has joined #openstack-keystone08:24
*** Kennan has quit IRC08:26
*** ParsectiX has quit IRC08:26
*** spandhe has quit IRC08:26
*** spandhe_ is now known as spandhe08:26
*** Kennan has joined #openstack-keystone08:26
*** fhubik is now known as fhubik_afk08:27
*** fhubik_afk is now known as fhubik08:29
openstackgerritjiaxi proposed openstack/keystone: Suppressing the request when creating endpoint with invalid urls  https://review.openstack.org/20495208:34
*** fhubik is now known as fhubik_afk08:35
tsubicHey guys, quick question, why is it that sometimes (1 out of 5) when I send a simple request (for example just swift list using the CLI) I get an Authorization error, something about cms_hash_token() getting a unexpected keyword argument 'mode'? Thanks!08:40
*** fhubik_afk is now known as fhubik08:40
*** kiran-r has quit IRC08:44
*** kiran-r has joined #openstack-keystone08:46
*** ParsectiX_ has quit IRC08:47
*** ParsectiX has joined #openstack-keystone08:48
*** ParsectiX has quit IRC08:49
*** aix has joined #openstack-keystone09:02
*** fhubik is now known as fhubik_afk09:06
*** spandhe has quit IRC09:07
*** fhubik_afk is now known as fhubik09:12
*** ParsectiX has joined #openstack-keystone09:19
*** marzif_ has joined #openstack-keystone09:22
*** marzif_ has quit IRC09:23
*** marzif_ has joined #openstack-keystone09:24
*** marzif_ has quit IRC09:24
*** marzif_ has joined #openstack-keystone09:25
bretontsubic: could you please copypaste the exact error?09:27
tsubicbreton: Authorization Failure. Authorization Failed: cms_hash_token() got an unexpected keyword argument 'mode' (HTTP 400)09:29
*** marzif_ has quit IRC09:30
*** stevemar has joined #openstack-keystone09:42
*** ChanServ sets mode: +v stevemar09:42
*** henrynash has quit IRC09:44
*** stevemar has quit IRC09:46
*** davechen has left #openstack-keystone09:53
*** lhcheng has joined #openstack-keystone09:56
*** ChanServ sets mode: +v lhcheng09:56
*** ParsectiX has quit IRC09:57
*** ParsectiX has joined #openstack-keystone09:57
bretontsubic: what are the versions of keystone and python-keystoneclient?10:00
*** lhcheng has quit IRC10:00
*** ParsectiX has quit IRC10:02
tsubicIt is the latest devstack installation of swift and keystone, I have tried with the python keystoneclient versions 0.3.1 and 0.7.110:03
tsubickeystone is 8.0 I believe10:04
tsubicor that is what pip says10:10
*** pnavarro has joined #openstack-keystone10:17
*** fhubik is now known as fhubik_afk10:19
*** chenhong1 has quit IRC10:20
*** lhcheng has joined #openstack-keystone10:21
*** ChanServ sets mode: +v lhcheng10:21
*** lhcheng has quit IRC10:25
*** akscram has quit IRC10:33
*** akscram has joined #openstack-keystone10:35
bretontsubic: that's very weird, because keystoneclient has that function at least since icehouse10:46
bretontsubic: and many our tests use it10:47
*** dims_ has joined #openstack-keystone10:52
*** ParsectiX has joined #openstack-keystone11:04
*** chlong has joined #openstack-keystone11:08
*** piyanai has joined #openstack-keystone11:11
*** pnavarro has quit IRC11:13
*** fhubik_afk is now known as fhubik11:21
*** marzif has joined #openstack-keystone11:23
*** pnavarro has joined #openstack-keystone11:25
*** aix has quit IRC11:27
*** ParsectiX has quit IRC11:28
*** ParsectiX has joined #openstack-keystone11:28
*** stevemar has joined #openstack-keystone11:30
*** ChanServ sets mode: +v stevemar11:30
*** stevemar has quit IRC11:34
*** daemontool_ has joined #openstack-keystone11:36
*** daemontool_ has quit IRC11:36
*** daemontool_ has joined #openstack-keystone11:37
*** ajayaa has joined #openstack-keystone11:43
ajayaaHi Jamielennox, I want to get tokens using keystoneclient.11:44
ajayaaHow do I do that?11:44
jamielennoxajayaa: why do you want a token rather than do things with keystoneclient11:44
ajayaaTo stress my keystone deployment and see how many tokens it can generate.11:44
*** fhubik is now known as fhubik_afk11:44
ajayaajamielennox11:45
ajayaa^^11:45
*** gordc has joined #openstack-keystone11:45
ajayaaDo I have to use requests library to do that or is there a way to do that with keystoneclient?11:45
jamielennoxso you would need to authenticate over and over again11:45
ajayaaThe client.Client call?11:45
ajayaajamielennox ^^11:46
jamielennoxso if you created a session and an auth plugin you could do an invalidate between calls and just do get_token() over and over11:46
*** fhubik_afk is now known as fhubik11:46
jamielennoxor you could do heaps of client.Client calls11:46
ajayaaokay. That's helpful.11:47
ajayaaAs it stands these calls synchronous. Is there a way to make these calls async?11:47
ajayaainsert *are11:47
ajayaaand not rewrite keystoneclient in the process.11:48
ajayaajamielennox ^^11:48
jamielennoxajayaa: i haven't done that specifically with keystoneclient11:49
jamielennoxyou could do eventlet monkey patching and make a bunch of green threads11:49
jamielennoxit will work just fin11:49
jamielennoxe11:49
*** fhubik is now known as fhubik_afk11:51
ajayaaThank you jamielennox11:51
marekdjamielennox: Hi. I'd like to finally get rid of this patch from my gerrit list: https://review.openstack.org/#/c/186854/ Would you take a look?11:51
jamielennoxmarekd: that's not that old11:52
jamielennox)11:53
*** jaosorior has joined #openstack-keystone11:53
marekdwell, so at least enqueue it on the reviews pile :-)11:53
openstackgerritMerged openstack/keystone: Clean up docs before creating new ones  https://review.openstack.org/20392511:57
openstackgerritMerged openstack/keystone: Minor fix in the `configuration.rst`  https://review.openstack.org/20452911:57
openstackgerritMerged openstack/keystone: Moves keystone.hacking into keystone.tests  https://review.openstack.org/20289511:57
openstackgerritMerged openstack/keystone: Docs link to ACTIONS  https://review.openstack.org/20343311:58
*** dims_ has quit IRC12:02
samueldmqgit commit -a --amend12:13
samueldmqoooooops12:13
samueldmq:)12:13
*** bdossant has quit IRC12:15
*** gordc is now known as gordc_offsite12:18
*** ajayaa has quit IRC12:18
*** geoffarnold has quit IRC12:23
*** geoffarnold has joined #openstack-keystone12:23
openstackgerritBrant Knudson proposed openstack/keystone: Documentation for other services  https://review.openstack.org/20480112:24
*** aix has joined #openstack-keystone12:28
*** mflobo has quit IRC12:28
*** mflobo has joined #openstack-keystone12:37
openstackgerritjiaxi proposed openstack/keystone: Suppressing the request when creating endpoint with invalid urls  https://review.openstack.org/20495212:42
*** geoffarnold has quit IRC12:44
*** geoffarnold has joined #openstack-keystone12:44
openstackgerritMerged openstack/keystoneauth-saml2: Updated from global requirements  https://review.openstack.org/20185612:46
*** kiran-r has quit IRC12:48
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/20493712:50
*** amakarov_away is now known as amakarov12:51
*** htruta has quit IRC12:51
*** htruta has joined #openstack-keystone12:54
*** edmondsw has joined #openstack-keystone12:56
*** jsavak has joined #openstack-keystone13:01
*** geoffarnold has quit IRC13:05
*** geoffarnold has joined #openstack-keystone13:06
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystonemiddleware: Introduce endpoint_ids config  https://review.openstack.org/20504913:06
*** fhubik_afk is now known as fhubik13:15
*** stevemar has joined #openstack-keystone13:19
*** ChanServ sets mode: +v stevemar13:19
*** fhubik is now known as fhubik_afk13:21
*** fhubik_afk is now known as fhubik13:21
*** fhubik is now known as fhubik_afk13:21
*** stevemar has quit IRC13:22
*** ajayaa has joined #openstack-keystone13:23
*** geoffarnold has quit IRC13:25
*** geoffarnold has joined #openstack-keystone13:26
*** yottatsa has joined #openstack-keystone13:28
yottatsahappy #openstack5bday13:28
yottatsahey, just found some disgusting problem with Validate token HTTP API13:29
yottatsahttp://developer.openstack.org/api-ref-identity-admin-v2.html#admin-validateToken here is said that "An itemNotFound (404) fault is returned for a token that is not valid."13:29
yottatsaAnd I've got 401 for invalid fernet token in Kilo13:30
*** janonymous has joined #openstack-keystone13:30
openstackgerritjanonymous proposed openstack/keystone: Python 3: Replace assertRaisesRegexp to its six implementation  https://review.openstack.org/19386613:30
*** yottatsa has quit IRC13:30
*** yottatsa has joined #openstack-keystone13:31
*** jdandrea has joined #openstack-keystone13:34
*** ninag has joined #openstack-keystone13:36
*** hrou has joined #openstack-keystone13:36
yottatsalooks like it was broken by dolphm it 201213:39
yottatsahttps://github.com/openstack/keystone/commit/4e2be8a8880f03b1c6d1dc663d7259dbb45ddf6713:39
*** stevemar has joined #openstack-keystone13:39
*** ChanServ sets mode: +v stevemar13:39
marekdstevemar: Bonjour monsieur Steve~13:40
*** jecarey has joined #openstack-keystone13:40
marekdstevemar: are there any plans on switchng OSC to keystoneauth once it's eventually released?13:40
stevemarmarekd: o/13:40
marekdI mean is somebody willing to take a leap on it?13:40
yottatsaand test is also incorrect https://github.com/openstack/keystone/blob/master/keystone/tests/unit/token/test_fernet_provider.py#L5113:40
*** bknudson has quit IRC13:40
stevemarfor sure13:40
marekdor it's a non determined state "it'd be good to have it...one day..in the future"13:40
stevemarwe still need ksc13:41
marekdstevemar: for CRUD of coruse13:41
marekdbut i am saying on auth with KSA13:41
marekdstevemar: I am basically thinking about "K2K from OSC" and for that I need KSA in OSC or porting K2K to KSC.13:42
*** fhubik_afk is now known as fhubik13:42
*** ayoung has joined #openstack-keystone13:42
*** ChanServ sets mode: +v ayoung13:42
stevemarmarekd: osc picks up all plugins anyway13:43
stevemarhttps://github.com/openstack/python-openstackclient/blob/master/openstackclient/api/auth.py13:43
yottatsait's like https://bugs.launchpad.net/python-keystoneclient/+bug/1243336 but it's broke keystoneclient13:43
openstackLaunchpad bug 1243336 in python-keystoneclient "Rescope in V3 for invalid/expired token should return unauthorized (returns 404 currently)" [Wishlist,Opinion]13:43
*** richm has joined #openstack-keystone13:44
*** dims_ has joined #openstack-keystone13:44
*** dims_ has quit IRC13:45
bretonyottatsa: is it for fernet only or for all types of token?13:45
*** dims_ has joined #openstack-keystone13:45
marekddolphm: stevemar yeah, but from KSC13:45
yottatsabreton, I'm diggin the problem right now13:46
yottatsait looks like fernet only problem13:47
bretonyottatsa: thank you. Please make a bugreport, I will be happy to have a look at it13:47
marekddolphm: is fernet marked as stable/experimental/nothing ?13:48
*** zzzeek has joined #openstack-keystone13:48
*** htruta has quit IRC13:51
openstackgerritSteve Martinelli proposed openstack/keystone: switch to oslo.cache  https://review.openstack.org/19587313:51
*** btully has joined #openstack-keystone13:52
openstackgerritSteve Martinelli proposed openstack/keystone: Show config option changes for oslo.cache  https://review.openstack.org/20506613:54
bretonmarekd: it's marked as none I guess13:54
*** fhubik_afk has joined #openstack-keystone13:54
openstackgerritMerged openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/20313713:54
*** fhubik has quit IRC13:55
*** woodster_ has joined #openstack-keystone13:55
openstackgerritMerged openstack/python-keystoneclient: Remove unused time_patcher  https://review.openstack.org/20477113:55
*** yottatsa has quit IRC13:57
*** raildo has joined #openstack-keystone13:59
*** mylu has joined #openstack-keystone13:59
*** yottatsa has joined #openstack-keystone13:59
yottatsabreton, https://bugs.launchpad.net/keystone/+bug/147760013:59
openstackLaunchpad bug 1477600 in Keystone "Token Validation API returns 401 not 404 on invalid token" [Undecided,New]13:59
*** dgrauet has joined #openstack-keystone13:59
stevemarmarekd: i  think its experimental13:59
dstanekyottatsa: a 404 just seems wrong there14:02
yottatsadstanek, you're wrong, because spec requires 40414:02
dstanekyottatsa: i'm not saying the spec doesn't say that :-)14:03
dstanekyottatsa: in reality i don't think a 404 is the right response code14:03
yottatsadstanek, https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L114714:03
*** jsavak has quit IRC14:03
yottatsain ksc auth middleware we're expect 404 for invalid token14:04
dstanekyottatsa: yeah, that logic seems strange14:04
yottatsaand 401 for invalid ADMIN token14:04
yottatsaso 401 for invalid user token makes middleware go for new admin token14:04
*** piyanai has quit IRC14:05
*** belmoreira has joined #openstack-keystone14:08
*** piyanai has joined #openstack-keystone14:08
*** sigmavirus24_awa is now known as sigmavirus2414:08
dstanekyottatsa: wow, that seems very wrong. i wonder why we did that14:08
yottatsaI think it's just a bug to be fixed14:09
yottatsaShould I make a patch?14:09
dstanekyottatsa: sure, i suspect you just want to patch fernet to have the same odd behavior?14:09
*** ParsectiX has quit IRC14:10
*** jsavak has joined #openstack-keystone14:11
*** bknudson has joined #openstack-keystone14:11
*** ChanServ sets mode: +v bknudson14:11
yottatsadstanek, I'm afraid I broke things if I patch token_formatters. I think I need to patch it here https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/core.py#L152 and raise 404 on same manner as UUID do https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L67914:12
dstanekyottatsa: i would guess you'll have to isolate your patch to the fernet code14:13
dstanekyottatsa: i'm going to file a bug about the 404 being the wrong status code. it's probably too hard to fix that now though14:15
yottatsadstanek, it's not true that 404 is wrong14:16
yottatsa404 mean we're could not find a token14:16
yottatsa401 mean our request is not authorized14:16
*** piyanai has quit IRC14:18
*** piyanai has joined #openstack-keystone14:18
*** thedodd has joined #openstack-keystone14:18
*** topol has joined #openstack-keystone14:19
*** ChanServ sets mode: +v topol14:19
*** belmoreira has quit IRC14:19
*** jsavak has quit IRC14:19
dstanekyottatsa: i believe 404 is wrong because it fails validation - not that the resource doesn't exist14:20
*** jsavak has joined #openstack-keystone14:20
dstanekwe shouldn't have different HTTP code for different types of tokens coming from the same resource14:20
openstackgerritHenrique Truta proposed openstack/keystone: Change project name constraints  https://review.openstack.org/15837214:21
yottatsadstanek, again, UUID is working correct and returns 404 here14:21
*** piyanai has quit IRC14:21
*** htruta has joined #openstack-keystone14:21
lbragstadyottatsa: returns 404 when you give a non-existant token ID?14:21
yottatsalbragstad, yep14:21
dstanekyottatsa: i'm saying that i think a 404 was the wrong implementation choice14:21
yottatsamaybe 403?14:22
lbragstadyeah, we do a lot of obfuscation in the token provider with 401, so we don't give much information14:22
dstaneklbragstad: i think it's worse than that - https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L114714:23
lbragstaddstanek: oh, so *everything* that is a 404 is returned as a 401?14:24
dstaneklbragstad: seems like the keystone server returns 401 for admin tokens and a 404 for other validation failures14:24
lbragstadstrange...14:26
dstanekyottatsa: a 403 is probably correct - it seems like 401 must have a WWW-Authenticate header on the return and i'm pretty sure we don't do that14:26
dstanekunless webob is helping us out14:27
yottatsalbragstad, dstanek, it was chosen because on v2.0 API token was an URI component like /v2.0/auth/token/TOKENHERE14:27
yottatsaso no token, no resource, 40414:27
dstanekyottatsa: but that's not the case anymore right?14:28
*** jecarey has quit IRC14:28
yottatsafor v3 it's not the case14:28
yottatsabut I believe v2.0 is not a subject to change14:28
morganfainbergCorrect v2 is frozen14:30
dstanekv2.0 is all but dead14:30
morganfainbergDont change v2 unless it is an egregious error / security14:30
dstaneki'll file a bug on that because even if we can't fix it i think it14:30
dstanek's wrong14:30
*** briancurtin has quit IRC14:31
dstanekmorganfainberg: no changes to v2. v3 has some stupid encoded into it as a side effect of the way v2 was implemented14:31
*** briancurtin has joined #openstack-keystone14:31
dstanekyottatsa: does fernet responding with a 401 break anything or did you must find it inconsistent?14:32
morganfainbergdstanek: yep14:32
*** jsavak has quit IRC14:33
*** gordc_offsite has quit IRC14:34
yottatsaI believe https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/token_formatters.py#L201 fernet token_formatter.validate_token SHOUD return exception.ValidationError instead of exception.Unauthorized14:34
yottatsaand it shoud be handled properly14:34
*** jsavak has joined #openstack-keystone14:35
morganfainbergA strict 400 is sufficient here. But it has to be in the 400 class.14:35
dstanekyottatsa: but does it cause an issue being a 401? or are you just looking to make it match the docs?14:35
yottatsadstanek, it's breaking API services on heavy load14:36
morganfainbergyottatsa: how?14:36
lbragstadjust under *heavy* load?14:36
dstanekyottatsa: really? this should be load related14:36
morganfainbergHow does an error code break api services under heavy load?14:36
lbragstadif it breaks api service it should break them under light load, too :)14:36
morganfainberglbragstad: ++14:37
lbragstadservices*14:37
yottatsaHere is the debug log of glance-api for example14:38
yottatsahttps://gist.github.com/anonymous/c2040eb89e23fc1a4af014:38
*** henrynash has joined #openstack-keystone14:38
*** ChanServ sets mode: +v henrynash14:39
morganfainbergAgain, why is load a factor14:39
dstanekyottatsa: that just means your token was invalid14:39
dstanekthe 'admin token' in the error message is the unfortunate part14:39
yottatsadstanek, if USER token is invalid, why do middleware reissue ADMIN token?14:40
yottatsanote that line 2 and 4 contains differrent admin tokens14:40
morganfainbergyottatsa: does the same thing occur with uuid tokens and v3?14:41
morganfainbergI have to ask because *i* think i know why this is happening14:41
*** TheIntern has joined #openstack-keystone14:41
* morganfainberg ignores v214:41
dstanekmorganfainberg: i would guess no because of the 40414:41
yottatsaso instead of 10 ms on request, we've got 10 + 60 + 10, and +60  on next request (where 10ms is a validation time and 60ms is issue time)14:42
yottatsamorganfainberg, no, UUID is working just fine on v2.0 and v314:42
morganfainbergdstanek: this is another "edge" case that is occuring because fernet doesnt wrap the same way as the other providers. So, a validate is raisng a 401. I fixed this in uuid14:42
morganfainbergBut fernet didnt lean on any of the other provider's code14:43
*** marzif has quit IRC14:43
morganfainbergThis is a medium prio bug, but it is effectively a regression14:43
dstanekmorganfainberg: yeah, that what yottatsa's bug says. that fernet isn't returning a 404. what i was saying is that a 404 isn't correct, but not sure that we can fix that now.14:43
morganfainbergWe could change to a 400 and be ok14:44
*** marzif has joined #openstack-keystone14:44
morganfainbergSame class of error14:44
yottatsamorganfainberg, just don't forget about ksc14:44
morganfainbergOr we can go to 404 in fernet14:44
morganfainbergyottatsa: dont care about ksc14:44
dstanekmorganfainberg: no, because auth_token would be broken. you have to use a 404. - it's being dumb here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L114714:45
morganfainbergCare about middleware14:45
morganfainbergdstanek: so we fix middleware too14:45
morganfainberg;)14:45
morganfainberg404 or 400 both fine ;)14:45
yottatsamorganfainberg, I mean middleware :)14:45
dstanekmorganfainberg: yeah, that's what i was thinking.14:45
morganfainbergWe *can* fix this was my point14:45
dstanekwhat i don't know if how to differentiate between a user and admin token for the client14:46
morganfainbergdstanek: also how does keystonemiddleware work?14:46
morganfainbergNot ksc version14:46
morganfainbergKsc version is dead14:46
morganfainbergdstanek: i dont understand your problem. Middleware holds admin token in session14:47
morganfainbergUser token is separate14:47
morganfainbergAgain, dont look at middleware in keystoneclient, look in the keystonemiddleware package14:47
morganfainbergKeystoneclient version has been bit rottibg/dead for cycles14:48
dstanekmorganfainberg: yeah, i'm looking how to see what it does. i'm hoping it's been fixed14:48
dstanekmorganfainberg: i can't find anything to catch the 404, so maybe it's working fine14:49
dstanekyottatsa: can you switch over to keystonemiddleware to test?14:50
rletrocquerhi, currently is-it possible for an user that is authenticated to an openstack site A to switch to an other openstack site B without re-authenticate on dashboard ? (site with own keystone and not sharing or synchronize database)14:50
*** jecarey has joined #openstack-keystone14:50
morganfainbergyottatsa: if you are using keystoneclient's version of middleware - it is not supported14:50
morganfainbergWe are removing it in a very soon release of keystoneclient14:50
morganfainbergdstanek: i am going to guess this is still an issue with fernet14:51
morganfainbergrletrocquer: nope14:51
morganfainbergrletrocquer: not really unless you're using fernet and synchronising dbs14:52
morganfainbergrletrocquer: or synchronisng the token table for other token types.14:52
dstanekmorganfainberg: do you think fernet should 404 like the other providers? (i have not validated that they do that)14:52
morganfainberg Or sharing the db14:52
janonymousHi, Could someone help me out on : https://review.openstack.org/#/c/193866/14:53
morganfainbergdstanek: it should re-raise 404 (or everything move to 400) on a validate14:53
janonymousI donno what is going wrong with the patch14:53
morganfainbergdstanek: once the admin token has passed14:53
yottatsadstanek, I'll switch on keystonemiddleware in next two weeks. Now part of our production is still on Icehouse14:53
lbragstadI have some patches up for the consolidation of the fernet code path, I wonder if it's changed in there?14:53
* lbragstad has to double check 14:54
morganfainbergdstanek: 401 - admin token broken, 404/400 user token bad14:54
morganfainberglbragstad: worth checking.14:54
dstanekmorganfainberg: why not a 401/403 for the user token?14:55
lbragstadi think it will still be subject to the same bug https://review.openstack.org/#/c/196877/1114:55
dstanek400 seems too generic and 404 doesn't fit because the resource is actually there14:56
morganfainbergdstanek: 401 is used for indicating x-auth-token is wrong14:56
openstackgerritBoris Bobrov proposed openstack/keystoneauth: Expose bug in AccessToken  https://review.openstack.org/20509414:56
morganfainbergErm invalid14:56
morganfainbergYou cant access keystone14:56
morganfainbergX-subject-token invalid is an indicator the resource is not valid14:57
morganfainbergSo 401 is incorrect14:57
bretonwhat do you think about  ^? Should these properties be None or should an exception be raised?14:57
morganfainbergA 403 would also be incorrect14:57
morganfainbergAs you are not forbidden from seeing the resource14:57
yottatsadstanek morganfainberg, speaking about ksmiddleware, it's relies on ksc, so validation is just get: https://github.com/openstack/python-keystoneclient/blob/795b8567174f1d210eab6a4585d7339a302b0a69/keystoneclient/v2_0/tokens.py#L87 https://github.com/openstack/python-keystoneclient/blob/795b8567174f1d210eab6a4585d7339a302b0a69/keystoneclient/v3/tokens.py#L7514:58
morganfainbergdstanek: so we need this to be a bad request - the 404 is correct in v2, in v3 it is sinply a resource that is incorrect in the request, so 40014:59
morganfainbergyottatsa: keystoneclient is really mostly irrelevant here14:59
yottatsamorganfainberg, rly?14:59
morganfainbergYep.14:59
*** jasonsb has quit IRC15:00
yottatsamorganfainberg, https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_identity.py#L7615:00
morganfainbergThis is a question of how the server responds15:00
morganfainbergWe would fix the client to match15:00
morganfainbergHence irrelvant15:00
*** jasonsb has joined #openstack-keystone15:00
*** pnavarro has quit IRC15:01
dstanekmorganfainberg: hmmm...i was thinking 403 because the credentials were invalid15:01
yottatsamorganfainberg, I think 404 is just fine for v2.0 because of semantics15:01
morganfainbergV2 cant be changed itll be a 40415:01
morganfainbergThis is a convo about v315:02
yottatsamorganfainberg, and 403 for v3 is good to15:02
morganfainbergNo 403 is incorrext15:02
morganfainbergYou are not forbidden from accessing the url15:02
dstanekwhat is the actual error then?15:02
morganfainbergdstanek: but the credentials arent invalid, x-subject-token arent credentials15:02
morganfainbergX-auth-token is15:02
yottatsamorganfainberg, I think that passing Subject token in headers IS incorrect15:03
yottatsait broke semantics15:03
morganfainbergyottatsa: that is a security thing15:03
morganfainbergIt should have been in a body15:03
morganfainbergBut it meant we couldnt use a get15:03
yottatsahow about 402? ;)15:03
morganfainberg400 imo is the most correct when x-subject-token is invalid15:04
*** fhubik_lunch has joined #openstack-keystone15:04
morganfainbergyottatsa: i keep wanting to use 402:  pay me to fix this bug15:04
morganfainberg:P15:04
rletrocquerthanks morganfainberg for your answer.15:04
dstanekmorganfainberg: hmmm...yeah that probably makes sense15:04
*** jasonsb has quit IRC15:05
dstanek402's everywhere!15:05
*** topol has quit IRC15:05
morganfainbergThere is no question that 404 is correct for v215:05
lbragstadI would be fine with 400,15:05
lbragstadsince here https://github.com/openstack/keystone/blob/2a3f9b45faf833bfed587ecc217d83f37e90ddcb/keystone/token/providers/fernet/token_formatters.py#L199-L203 we might not be "unauthorized" explicitly.15:05
morganfainbergAnd v3 should probably just raise the same as uuid for now - with a followup to do 40015:05
*** fhubik_afk has quit IRC15:06
morganfainbergBut that requires client/middleware changes15:06
morganfainbergSo as a followup15:06
lbragstadI think when the fernet stuff was written, we appoarched it from the fact it was a tampered token15:06
morganfainberglbragstad: that is fine - validate code path is used for both admin and user tokens15:06
morganfainbergYou need to reraise down in the controller15:07
morganfainbergWe reraise unauthorized in the auth process15:07
yottatsaso: 1. I'll fix keystone.token.providers.fernet.token_formatters.TokenFormatter#validate_token and replace exception.Unauthorized with exception.ValidationError; 2. I'll fix all the code around validate_token to handle exception properly; 3. somebody propose API change and replace 404 with 40015:07
*** fhubik_lunch has quit IRC15:07
yottatsamorganfainberg, how about it?15:08
morganfainbergyottatsa: you may need the controller to reraise a 404 instead of fixing the provider15:08
lbragstadI believe dolphm was around writing some of that too, so he might have some more context around that ^15:08
morganfainbergyottatsa: the move from 404-400 should be a wishlist item for v315:09
*** daemontool_ is now known as marzif_15:10
*** alex_xu has quit IRC15:10
*** alex_xu has joined #openstack-keystone15:11
yottatsahow about 498?15:13
yottatsa498 Token expired/invalid (Esri)15:14
yottatsaReturned by ArcGIS for Server. A code of 498 indicates an expired or otherwise invalid token.[28]15:14
yottatsahttps://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error15:14
*** esp has joined #openstack-keystone15:14
*** pnavarro has joined #openstack-keystone15:15
*** david-lyle has joined #openstack-keystone15:17
*** dgrauet has quit IRC15:17
morganfainbergNope. Want to use http standards15:17
morganfainberg498 is esri specifif15:17
morganfainbergSpecific15:17
morganfainbergWe could make our own code, but have historically avoided that15:19
*** diazjf has joined #openstack-keystone15:20
*** piyanai has joined #openstack-keystone15:21
morganfainbergmfisch: so I think I see another optimization we can do to help with the revoke issues15:23
morganfainbergmfisch: but I'd need to get some time to profile it15:24
morganfainbergmfisch: effectively we also load from the DB every time w/o caching.15:24
morganfainbergmfisch: though profiling this could be easy with memcache vs non-memcache enabled revoke15:24
*** arunkant_ has joined #openstack-keystone15:25
morganfainberglbragstad: ^ cc15:26
*** marzif_ has quit IRC15:28
*** piyanai has quit IRC15:29
mfischmorganfainberg: I did some numbers last night after enabling memcached15:30
mfischthe test is pretty biased in favor of caching since I'm validating the same token over and over15:30
mfischit was way faster of course, but still had the slow down affect15:30
morganfainbergmfisch: so only enable caching of revoke15:30
morganfainbergnot token15:30
mfischright I can try that some time15:31
morganfainbergmfisch: but this tells me what I've been asserting in the ML thread15:31
morganfainbergwe have an expensive matching algorithm15:31
*** jsavak has quit IRC15:31
mfischI agree15:32
morganfainbergi think it is because we do string subs15:32
*** jsavak has joined #openstack-keystone15:32
morganfainbergvs. just string matching15:32
morganfainbergeven when the tree itself is cached15:32
*** Guest24740 has joined #openstack-keystone15:32
morganfainberg subtree = revoke_map.get('%s=%s' % (name, key))15:32
dstanekcan we unroll it a little and explicitly add entries for each token instead of adding a single entry to bundle them?15:32
morganfainbergdstanek: no - we end up back to a TRL15:33
morganfainbergwhich causes more issues15:33
*** piyanai has joined #openstack-keystone15:33
morganfainbergi'd rather have a slow validate than a unbounded list of 10s of thousands of tokens15:33
morganfainbergwe end up back to just storing tokens in the db15:33
dstanekhmmm... not sure how much we can do with the current algorithm.15:34
*** mylu has quit IRC15:34
morganfainbergdstanek: we move back to something a bit more liniar15:34
morganfainbergthat doesn't need stringsubs eat each level15:34
morganfainberga == b15:35
morganfainbergwill be faster than ('%s' % a) == b15:35
morganfainbergplus other magic string manipulations15:35
dstaneki'll have to look at the linear algorithm that ayoung posted. why was the tree chosen over linear15:36
janonymous__eq__15:36
morganfainbergdstanek: because someone rewrote it as a drive-by15:36
morganfainbergin the initial review process15:36
dstanekthat particular example will be microscopically different15:36
morganfainbergand those working on it didn't push hard enough to go back to something readable15:37
dstanekdrive-bys are fun15:37
morganfainbergdstanek: well it's doing things like name=key in a dict lookup and then doing a name=* for a wildcard match15:38
morganfainbergits a lot of extra string manipulations15:38
morganfainbergwe could just check does value == thing from token value15:38
morganfainbergand at the very least, could be a bit easier to read15:38
dstanekmorganfainberg: i thought that the tree did that so that it could rely on less revocation entries. now i'm interested in what it's actually doing :-)15:40
morganfainbergthe tree is just so you are doing an "optimised" search15:40
morganfainbergnot changing the entries15:40
morganfainbergand i don't think ayoung's linear search is really better ir's doing other expensive things at each setp15:40
morganfainbergstep*15:40
*** pnavarro has quit IRC15:41
*** mylu has joined #openstack-keystone15:42
morganfainbergthe best solution is to avoid the dict constructor(s) and break early if the token matches15:42
ayoungmorganfainberg, so, the question is where are things slow right now?  Is it in the building of the treee, and we are creating the treee too many times, or is in the lookup?15:42
morganfainbergnot run through the entire list of event matching15:42
morganfainbergayoung: we cached the treee with mfisch's envifonrment15:43
ayoungmorganfainberg, normal case is going to be "token is valid"15:43
mfischwhat about limiting the query some? you are loading the entire table each time15:43
mfischyou should be able to limit it by user right?15:43
ayoungso , yeah, early failur is good, but will minimize the speedup15:43
morganfainbergayoung: it still suffered in slowdown15:43
ayoungmorganfainberg, my guess is that we are creating the tree each time instead of caching it somehow15:43
morganfainbergayoung: it's 3 bad things: 1) load from DB every time [inefficient model->usable python struct], tree build, and match15:43
*** mestery has joined #openstack-keystone15:43
morganfainbergayoung: we don't cache by default it's a memoize15:44
ayoungremember, I wrote this with an eye to being fetched and cached in ATM...so the assumptions do not hold15:44
morganfainbergayoung: so i think we need to just rethink the thing top to bottom15:44
ayoungmemoize the tree...should work, but be expensive, IIUC?15:44
ayoungmorganfainberg, kill all revocations and make tokens 5 minutes long?15:44
morganfainbergayoung: memoize helped. memoize = memcache15:44
morganfainberghere15:44
morganfainbergayoung: we *cant* do that15:44
morganfainbergayoung: you know that15:44
morganfainbergnot today15:45
ayoungwill memoize be fast for hashtables?15:45
morganfainbergmemoize is fast enough in this case. since it's storing a dict15:45
morganfainbergit is faster than db->dict15:45
morganfainbergbut it has to be memcache it can't be internal15:45
*** jsavak has quit IRC15:45
morganfainbergdue to multiprocess15:45
morganfainberghas to be a shared cache.15:45
*** jsavak has joined #openstack-keystone15:46
dstanekmorganfainberg: and memory constraints!15:46
morganfainbergso setting that aside15:46
ayoungright...so...15:46
ayoungmfisch, what are the classes of revocation you are actually seeing?15:46
ayoungyou said it was mostly from users logging out of Horizon, right?15:46
morganfainberglets look at how we store events, since ATM no longer needs to fetch. then look at the event model -> python struct15:46
mfischin the real world yes15:46
mfischwe also have a regression test that is sometimes run that generates a bunch of user and role deletes/removes15:46
morganfainbergthe horizon deleting tokens is just such an awful case15:46
ayoungthose are done by userid.15:46
mfischfor my testing I just straight up generate and revoke a token15:47
claytonmorganfainberg: I suspect the memoize is still slow because it still has to deserialize the entire tree every time15:47
mfischbecuase thats easy15:47
claytonthat's a lot of memory allocations that get thrown away every time15:47
ayoungif we maintained a sorted (by userid ) list of those,  searching would be O(log N)15:47
morganfainbergclayton: it's not that slow - it's mostly the same as anything else in openstack15:47
morganfainbergclayton: but when we also need to do tons of transforms15:48
ayoungand the database can help us with those, right?15:48
morganfainbergthat's where it gets ugly15:48
morganfainbergayoung: thats one thing we can do.15:48
ayoungseklect * from  revoke_events where (not expired)  order_by user_id;15:48
morganfainberglets kill the KVS revoke event driver15:48
morganfainbergthen we can focus on makeing the SQL one behave like SQL should15:49
morganfainbergrather than trying to make SQL and KVS both handle things sanely15:49
ayoungmorganfainberg, I think I want to suggest a straight up linear search.15:49
*** nkinder has joined #openstack-keystone15:49
ayoungI think that any other operation performed on a per-check basis will be more overhead than gain15:49
morganfainbergayoung: that's fine - if we're doing that, lets avoid the dict transform stuff we're doing in db -> python struct15:49
morganfainbergayoung: which is what i was noticing in your original code.15:50
claytonhas anyone profiled the tree code?15:50
morganfainbergclayton: in all cases it has always been slow in test, in validate, etc15:50
morganfainbergclayton: not in the strictest search sense but it was a sub-optimial idea when we started15:51
claytonsure, it seems overly complex for something you throw away every time you use it15:51
morganfainbergclayton: i want to throw it out based on its lack of maintainablility anyway - this all came from the idea that auth_token middleware would be fetching the events and checking on the endpoint side15:51
ayoungmorganfainberg, somewhere in that patch set I had both code paths...the lienar was in the test case.  I had ideas back then to be able to compare a run of one with the other15:51
morganfainbergsince that is no longer true, we can reimagine everything in a way that isn't assuming something is fetching externally15:51
morganfainbergclayton: ^15:52
ayoungmfisch, you said you had a trivial number of revocations right?15:52
mfischnormally its like 30 or so15:52
mfischmaybe up to 10015:52
mfischfrom general use15:52
ayoungyeah...lets linear search that15:52
mfischbut once it gets to 500 perf is cut in half15:53
ayoungok...let me see if I can get a build of the code to work with the linear....15:53
claytonyeah, and 500 isn't a particularly crazy number15:53
*** ankita_wagh has joined #openstack-keystone15:53
mfischthe issue is that validation is pretty much the fundamental building block of openstack15:53
ayoungthe degrataion should be....wait for it...linear....15:53
mfischeverything in the entire cloud hinges on it15:53
morganfainbergmfisch: so i hate to ask15:53
morganfainbergwhat is 50% performance15:53
morganfainbergat 500?15:53
*** federico3 has quit IRC15:53
morganfainbergwhat is the wallclock validate?15:53
claytonmfisch: you have a link to the graph you shared with me?15:53
mfischthinking15:54
morganfainbergbecause frankly... if it's <.5s I'm viewing this as medium15:54
mfischmost of the benchmarks I did were done with concurrent validations let me see if it captures info15:54
morganfainbergif is .5-1s validate, it's a little higher priority15:54
morganfainbergif its 5s+ that is serious15:55
*** kiran-r has joined #openstack-keystone15:55
mfischthe measurements are more about throughput15:55
claytonmorganfainberg: the issue isn't so much the wall clock time, it's when we have some something go slightly wonky and token validation rate goes up by 5x, everything falls over.15:55
mfischmy recent ones are on a virtual environment, let me see if I have prod numbers15:55
*** _kiran_ has joined #openstack-keystone15:56
morganfainbergclayton: again, if validations take up to 2s in "OMG IO latency" or some wacky thing15:56
morganfainbergwe need to make that more resilient15:56
morganfainbergassuming 500ms -> 5x15:56
morganfainbergfor a wonky omg moment15:56
morganfainbergif that is the case - i don't think we're looking at the right bits15:56
mfischtwo thoughts: first this would hurt less except that fernet token validation slowed us down quite a bit and made me focus on this, and second, we will be enabling caching which will help improve the base rate substantially15:56
*** jiaxi has joined #openstack-keystone15:57
mfischlet me look at my prod #s15:57
claytonmorganfainberg: the issue is validations start failing because you run out of capacity.15:57
*** pnavarro has joined #openstack-keystone15:57
morganfainbergclayton: again - we're attacking the wrong thing in the 2s model15:57
mfischmorganfainberg: let me get you some numbers on individual times with 500 revocations in my staging env, dont want to hack prod15:58
morganfainbergmfisch: ok15:58
*** zhiyan has quit IRC15:58
mfischgive me a bit15:58
morganfainbergisolated environment is fine as long as we have consistent numbers15:58
*** zhiyan has joined #openstack-keystone15:58
morganfainbergand we keep benchmarking the same thing15:58
morganfainbergclayton: my argument is if we can't handle a 2s validate storm - we have resiliency issues15:59
morganfainbergnot latency issues15:59
morganfainbergif everything is always 2s15:59
morganfainbergthen we have another problem because 10s is really unreasonable15:59
morganfainbergclayton: 500ms normal, with bursts into 2s in wonkyness, i'd focus on making sure we're resilent/optional tuning to help with scale-out resiliency16:00
*** kiran-r has quit IRC16:00
morganfainbergif that makes sense16:00
morganfainbergwe can always work to improve.16:00
* morganfainberg also thinks part of the problem is the chatty-ness to the backends in keystone16:00
morganfainbergbut that is a bigger issue to address16:01
*** jistr has quit IRC16:01
bknudsonif you've got a few minutes I'd like some input on https://etherpad.openstack.org/p/keystone-info -- nova meetup folks are asking for a "keystone overview for nova devs"16:01
claytonmorganfainberg: the issue we tend to see is some other service getting slammed, DoS'ing keystone and everything else falls over because keystone does.16:01
bknudsonto help them understand what v3 is.16:01
*** ninag has quit IRC16:02
*** jsavak has quit IRC16:02
*** marzif has quit IRC16:02
morganfainbergbknudson: simple: v3 is the CRUD api version - unfortunately, auth is also tied to it.16:02
morganfainbergbknudson: there should be almost nothing nova *needs* from the crud interface.16:02
*** jsavak has joined #openstack-keystone16:03
*** browne has joined #openstack-keystone16:03
morganfainbergbknudson: i know oyu know this16:03
*** ninag has joined #openstack-keystone16:03
morganfainbergbut i'm honestly kindof tired of the conversation16:03
bknudsonmorganfainberg: somebody is proposing using HMT to nova so they need to know how it works.16:03
bknudsonmorganfainberg: I'm tired of the conversations, too.16:03
* morganfainberg thinks we should just roll auth back into nova and glance and cinder16:04
bknudsonbecause it seems like everyone's making more of v2 -> v3 than they should be.16:04
bknudsonmaking it a lot more complicated than it is16:04
morganfainbergbknudson: it's an auth mechanism - and the auth details changed slightly16:04
morganfainbergthats the line i'm going with now16:04
morganfainbergunless they are heat16:04
morganfainbergbut funny, heat isn't the issue here16:04
*** _cjones_ has joined #openstack-keystone16:05
morganfainbergbknudson: your etherpad looks good to me, but i'd tell them to stop asking about the internals of keystone crud stuff16:05
morganfainbergit's irrelevant16:05
*** _kiran_ has quit IRC16:06
morganfainbergthe HMT bits16:06
morganfainbergif they have a way to ask for the hierarchy, that is good enogh16:07
*** TheIntern has quit IRC16:07
morganfainbergand they can know the hierarchy is immutable16:07
* morganfainberg tries to boil it down16:07
morganfainberghow does it "work" is the same as asking "how does storing data in RBD work?" do you just consume the block device that cinder tells you to? yes, ok same deal16:07
bknudsonnova folks think about v2 more than we do.16:07
morganfainbergi don't know why16:08
bknudsonme neither... we assume everyone uses v3 all the time and they think they're still using v2.16:08
morganfainbergtry and convince them to just think about the authorization data16:08
morganfainbergand not care what API version it comes from16:09
*** htruta has quit IRC16:09
morganfainbergif you feel bold16:09
*** htruta has joined #openstack-keystone16:10
*** dguerri is now known as dguerri`16:11
*** serverascode has quit IRC16:14
*** marzif has joined #openstack-keystone16:15
*** serverascode has joined #openstack-keystone16:16
*** mylu has quit IRC16:18
jiaxi http://webchat.freenode.net/?channels=openstack,openstack-10116:19
jiaxiIt's 00:19 in China.  Please help me to review my patch set  http://webchat.freenode.net/?channels=openstack,openstack-10116:19
jiaxiThank you16:19
openstackgerritBoris Bobrov proposed openstack/keystone: Tweak memcache lock sleep time and attempts number  https://review.openstack.org/20513916:20
jiaxiToo sleepy. I'm going to go to bed.  Good night.     https://review.openstack.org/20495216:22
*** jiaxi has quit IRC16:22
*** piyanai has quit IRC16:27
*** ankita_wagh has quit IRC16:28
*** ctracey has quit IRC16:31
*** lhcheng has joined #openstack-keystone16:31
*** ChanServ sets mode: +v lhcheng16:31
*** ctracey has joined #openstack-keystone16:31
*** jsavak has quit IRC16:33
*** jsavak has joined #openstack-keystone16:34
*** dguerri` is now known as dguerri16:34
mfischmorganfainberg: I have some prelim numbers for you16:34
*** lhcheng has quit IRC16:34
morganfainbergmfisch: cool16:35
mfischwith 0 revocation events16:35
mfisch104.67 [#/sec]16:35
mfischaverage time per16:35
mfisch191.071 [ms]16:35
mfischwith 500 events16:35
morganfainbergAcceptable baseline16:35
mfisch 52.48 [#/sec]16:35
mfisch  381.103 [ms]16:35
mfischnon-concurrent is about the same16:35
morganfainbergOk so i think we need to focus on resiliency. Now. We can improve the event bit too as part of it.16:35
mfisch 225.707 [ms] to 387 ms16:35
morganfainbergYeah.16:36
mfischany improvements here make all of openstack better which is ince16:36
mfischnice16:36
morganfainbergGreat. Can you toss those numbers on the ML thread too?16:36
mfischsure16:36
bknudsonmfisch: did you try defining an index?16:36
mfischnegative bknudson16:36
*** aix has quit IRC16:37
morganfainbergIm going to go out on a limb and say 381ms validate is not awful16:37
mfischI did see your blog comment this morning16:37
morganfainbergNot great, but not awful16:37
claytonI thought the only query it did was basically "SELECT * from <table> ORDER BY expires_at"16:37
bknudsonoh, I thought it was the cleanup that was too slow16:37
claytonoh, you mean to help with deletes?16:37
morganfainbergclayton: it is.16:37
morganfainbergThe cleanup was being hit everytime16:37
morganfainbergSo we moved when cleanup happened to on new event16:38
bknudsonit must do WHERE expires_at > ?16:38
claytonnope16:38
bknudsonok... getting the current revocation events doesn't need all the rows, only the active ones16:39
claytonbknudson: https://github.com/openstack/keystone/blob/master/keystone/contrib/revoke/backends/sql.py#L85-L8616:40
bknudsonsame with cleanup -- it only needs to look at the inactive ones.16:40
morganfainbergYes16:40
bknudsonthat's fetching revocation events, as in if keystonemiddleware was checking events16:40
bknudsonbut we never implemented revocation events in auth_token.16:40
samueldmqmorganfainberg: mfisch what is that you were talking about ? performance in tokens revocations ? looks interesting ...16:40
mfischyes16:40
mfischsamueldmq: http://www.mattfischer.com/blog/?p=67216:41
samueldmqmfisch: great, I will take a look thanks16:41
dolphmbknudson: https://review.openstack.org/#/c/203900 vs https://bugs.launchpad.net/keystone/+bug/147449116:43
openstackLaunchpad bug 1474491 in Keystone "keystone.tests.unit.test_config fails in isolation" [Low,In progress] - Assigned to lei zhang (zhang-lei)16:43
*** TheIntern has joined #openstack-keystone16:43
bknudsondolphm: stragely the tests didn't fail on py27, but I guess it would fix the prob.16:44
dolphmbknudson: the tests fail on py27 if you run that module in isolation16:45
*** TheIntern has quit IRC16:45
dolphmbknudson: and i verified that your patch fixes that16:45
*** mylu has joined #openstack-keystone16:45
bknudsondolphm: y, that fails for me too16:46
dolphmbknudson: dstanek just +A'd, but can you slap a Closes-Bug on there?16:46
bknudsonsure16:46
openstackgerritBrant Knudson proposed openstack/keystone: Ensure database options registered for tests  https://review.openstack.org/20390016:46
dstanekdolphm: hey!16:47
janonymousHi  guys : @dstanek , @bknudson, @boris,  : Could you please suggest something on, i think i am stuck somewhat here: https://review.openstack.org/#/c/193866/16:49
*** ninag has quit IRC16:49
samueldmqbknudson: hey, I was looking at that patch .. the explanation leads me to think something very similar is happening here16:50
samueldmqbknudson: https://bugs.launchpad.net/keystone/+bug/147449016:50
openstackLaunchpad bug 1474490 in Keystone "keystone.tests.unit.common.test_notifications.NotificationsTestCase fails in isolation" [Low,In progress] - Assigned to Diego Adolfo (diegoado)16:50
samueldmqbknudson: but in that ^ case, some other test may be registering the options16:51
bknudsonwithout python3 support in dogpile.cache there's not much that works.16:52
bknudsonso if someone was working on that we'd be able to increase coverage a lot16:52
bknudsonalthough for some reason oslo.cache doesn't seem to have a problem with python3, which is odd.16:52
samueldmqinteresting, tbh I haven't looked at oslo.cache yet :(16:53
*** e0ne has quit IRC16:53
*** thedodd has quit IRC16:54
*** snapdey has joined #openstack-keystone16:56
*** pnavarro has quit IRC16:58
dstanekdolphm: bknudson: it's even better if it fixes a bug!16:58
*** piyanai has joined #openstack-keystone16:58
dstanekbknudson: i am looking at that now16:59
*** dramakri has joined #openstack-keystone17:00
dstanekbknudson: it's not dogpile it's us or at least can be controlled by us17:00
bknudsondstanek: oh, oops17:00
*** ankita_wagh has joined #openstack-keystone17:00
dstanekbknudson:  i have a couple py3 patches baking right now.17:01
dolphmdstanek: hi!17:01
dstaneksamueldmq: that's why i have a problem with the whole option registration stuff. feel wrong to me17:02
*** ninag has joined #openstack-keystone17:05
*** jraim has quit IRC17:07
*** jraim has joined #openstack-keystone17:08
*** ninag has quit IRC17:10
*** mylu has quit IRC17:11
*** ninag has joined #openstack-keystone17:11
*** dims_ has quit IRC17:12
*** spandhe has joined #openstack-keystone17:13
janonymousany comment relating to my link..?17:15
bretonjanonymous: I had the same issue with https://review.openstack.org/#/c/188796/17:17
bretonjanonymous: the issue is that either some exception, or some marked for translation string does not want to be coerced to unicode17:17
bretonoh, no, it was not ready to be coerced to str17:18
bretonFile "/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_i18n/_message.py", line 208, in __str__17:18
bretonright, a string marked for translation doesn't want to be come a string17:19
bretonpython's assertRaisesRegexp tries to do str()17:19
dstanekjanonymous: i think the python2.7 version of the assertion method just doesn't play well with translation messages17:20
bretonif you really-really want to use the assertion, you need to make some changes in oslo_i18n17:20
dstanekwe may be stuck wrapping it after all to compensate17:20
*** nzeer has quit IRC17:20
*** nzeer has joined #openstack-keystone17:20
bretonWhen I wrote my patch, I decided that it doesn't worth the pain.17:21
dstanekbreton: which patch?17:21
bretondstanek: https://review.openstack.org/#/c/188796/17:22
bretondstanek: patchsets 1 and 217:23
dstanekah, i see17:23
dstanekyeah i agree that this may not be worth it right now17:23
bretonif ever17:23
janonymousohh.. i see , is thr any workaround for this...?17:24
*** lhcheng has joined #openstack-keystone17:24
*** ChanServ sets mode: +v lhcheng17:24
janonymousor shoul i keep it on hold for some time..17:24
dramakribknudson: ping.. when you get a chance, can you please take a look at https://review.openstack.org/#/c/196942/ ? I have addressed your comments. Thanks!17:24
bretonI know!17:24
bretonmake a comment there:17:24
*** lhcheng has quit IRC17:24
*** piyanai has quit IRC17:24
breton"Do not try to remove it. Developers, who already tried and failed: 2. Increase the number when you do."17:25
*** lhcheng has joined #openstack-keystone17:25
*** ChanServ sets mode: +v lhcheng17:25
*** mylu has joined #openstack-keystone17:25
bknudsondramakri: thanks. I'll add it to my list17:27
dramakribknudson: sure, thanks!17:27
*** r-daneel has joined #openstack-keystone17:28
*** ankita_w_ has joined #openstack-keystone17:31
*** piyanai has joined #openstack-keystone17:33
*** ankita_wagh has quit IRC17:34
*** e0ne has joined #openstack-keystone17:35
*** Zanatoz has joined #openstack-keystone17:37
*** ankita_wagh has joined #openstack-keystone17:38
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystonemiddleware: Dynamic Policies Fetch and Cache  https://review.openstack.org/18856117:40
samueldmqlhcheng: add unit tests, as you requested :)17:40
*** ankita_w_ has quit IRC17:41
openstackgerritDolph Mathews proposed openstack/keystone: Refactor: clean up TokenAPITests  https://review.openstack.org/20325017:42
lhchengsamueldmq: thanks for adding that17:42
*** mylu has quit IRC17:42
openstackgerritBoris Bobrov proposed openstack/keystoneauth: Expose bug in AccessToken  https://review.openstack.org/20509417:42
*** TheIntern has joined #openstack-keystone17:43
lhchengsamueldmq: I am wondering if we should the "Dynamic" in the commit msg. It seems like it is really just policy fetch and cache.17:43
lhcheng*should remove17:43
*** mylu has joined #openstack-keystone17:44
samueldmqlhcheng: hmm, look at henrynash's comment at https://review.openstack.org/#/c/134655/, you may agree with him17:45
dstaneklhcheng: i agree... in one of the dynamic policy reviews (i think a spec), dolphm mentioned that this isn't dynamic, but rather consolidated17:45
samueldmqlhcheng: actually I just saw there are comments from dstanek and dolphm tehre as well :)17:45
*** marzif has quit IRC17:45
lhchengWe have a system similar that does policy management, I am going to look it up what feature/config might be helpful for us.17:45
*** dims has joined #openstack-keystone17:45
dstaneksamueldmq: that's the one17:45
samueldmqok I am very open, if you guys think the terminology have to be changed I will be happy to change that17:45
lhchengsamueldmq: we also have a requirement for this centralized policy, will try to find more info and provide more feedback in the review.17:46
samueldmqlhcheng: nice please do o/17:47
samueldmqdstanek: lhcheng henrynash are you ok with dolphm's suggested terminology: 'centralized policy'?17:47
lhchengdstanek: yeah.. "dynamic" sounds like it changes on runtime, or have some self managing algorithm :)17:47
dstanek++17:48
*** rletrocquer has quit IRC17:48
ayoungsamueldmq, did you see dolphm 's comments on the Spec for the SFE?  Those need to be answered, or the extension is going to be turned down.17:48
lhchengsamueldmq: Yeah, I'll be cool with that. The feature is just specific for fetching anyway.17:48
*** mylu has quit IRC17:48
samueldmqayoung: will look17:48
openstackgerritDeepti Ramakrishna proposed openstack/keystone: Reuse token_ref fetched in AuthContextMiddleware.  https://review.openstack.org/19086317:49
samueldmqayoung: this spec https://review.openstack.org/#/c/134655/9/specs/backlog/dynamic-policies-fetch-cache.rst17:49
samueldmq?17:49
*** mylu has joined #openstack-keystone17:50
rodrigodsmorganfainberg, ping... is there a release planned for keystoneauth? (k2k support in horizon is waiting for it), otherwise we can do as marekd suggested yesterday and add k2kauthplugin in keystoneclient17:50
samueldmqayoung: ok so we're going to call it 'centralized policy'17:50
samueldmqayoung: sounds good ?17:50
morganfainbergrodrigods: we need to remoce17:50
*** e0ne has quit IRC17:51
morganfainbergRemove oslo.config and land 2-3 more patches before we can do 1.x17:51
*** janonymous has quit IRC17:51
morganfainbergUnfortunately, this needs jamielennox and i havent been able to get time to figure that out17:51
rodrigodsmorganfainberg, how can I help?17:51
morganfainbergrodrigods: figure out how to remove oslo.config and/or work with jamielennox on that front17:52
dramakrihenrynash: ping.. removed the comments as per your suggestion. Please take a look at it - https://review.openstack.org/#/c/190863/ ? Thanks!17:52
rodrigodsmorganfainberg, great, will ping him later today17:53
rodrigodsmorganfainberg, added a topic in next week meeting anyway17:53
morganfainbergthe big blocker is oslo.config removal17:53
*** piyanai has quit IRC17:53
morganfainbergwe can't have oslo dependencies in keystoneauth17:53
morganfainbergor at least we can't have them as "default" dependencies.17:53
rodrigodsI see17:54
*** doug-fish has joined #openstack-keystone17:54
*** zzzeek has quit IRC17:55
rodrigodsdoug-fish, ^ http://paste.openstack.org/show/404442/17:55
*** zzzeek has joined #openstack-keystone17:55
doug-fishthx!17:56
samueldmqbtw, I am feeling so good to see all those -1s on that spec, let's improve it o/17:56
*** snapdey has quit IRC18:03
openstackgerritBoris Bobrov proposed openstack/keystoneauth: Expose bug in AccessToken  https://review.openstack.org/20509418:05
*** snapdey has joined #openstack-keystone18:06
amakarovgeoffarnold, greetings! Do you develop a congress service?18:14
amakarovs/a/the/18:15
*** yottatsa has quit IRC18:16
doug-fishrodrigods: so just to review on k2k - next step is to follow up with jamielennox to sort out how soon keystoneauth can be brought up to speed/what work remains on getting olso dependency removed and a couple of other needed patches - is that right?18:16
geoffarnoldamakarov We're not using Congress right now. Ideally we'd like OpenStack to move to a comprehensive HMT-aware quota system, and that should probably be built on Congress18:16
rodrigodsdoug-fish, yes, otherwise I'll submit the k2k plugin to keystoneclient18:16
openstackgerritBoris Bobrov proposed openstack/keystoneauth: Fix decorators of properties in AccessToken  https://review.openstack.org/20520918:17
doug-fishrodrigods: perfect! thanks for being on top of this!18:17
rodrigodsdoug-fish, np, hope to have eveything working soon18:17
*** yottatsa has joined #openstack-keystone18:18
amakarovgeoffarnold, aha... I have a question: there are some Horizon folks sitting not far from me interesting in development of a policy editor. They've asked Horizon team about it and were told that Congress already does the policy editing. Is it so, or I can encourage them to create the feature?18:19
doug-fishFWIW adding the k2k plugin to keystone client is an easier path to getting Horizon working - otherwise there are a number of other changes needed for django_openstack_auth to use keystoneauth18:19
geoffarnoldamakarov Not sure how to move this kind of cross-functional multiple release effort forward.  One approach would be to have a couple of the user communities (large scale deployments, for instance) to put together a set of requirements, then use the ProductWG to move it forward as part of a coordinated roadmap18:19
*** mylu has quit IRC18:19
geoffarnoldamakarov I'm not enthusiastic about "generic policy" and "generic policy editors". I prefer a domain-specific approach. DSL FTW18:20
geoffarnoldI like a generic engine underneath, but keep the UX close to the use case18:21
*** mylu has joined #openstack-keystone18:22
amakarovgeoffarnold, I presume iterative approach can help: they can start working on a prototype improving it according to a feedback18:22
geoffarnoldSure. But use cases are needed to drive the x-project aspects, amakarov18:23
amakarovgeoffarnold, their concern is that there may be an overlapping feature that already performs everything :)18:23
*** doug-fish has quit IRC18:24
geoffarnoldamakarov Just because chisels exist doesn't remove the need for scalpels!18:24
pauloewertondoug-fish, +1. having a little test nightmare in d-0-a right now ;-)18:25
samueldmqayoung: quota subject.. suppose a user having project_admin (noninherited) and quota_admin (inherited) in the same project18:25
amakarovgeoffarnold, :)18:25
samueldmqayoung: requiring a token in specific scope for the project one to control quota may make sense this way ^18:25
amakarovgeoffarnold, so what would you suggest about it?18:25
ayoungsamueldmq, its an "or"  and it depends on what would be assigned on the token iteslf18:26
*** doug-fish has joined #openstack-keystone18:26
ayoungtokens should always be specific to scope18:26
ayoungbut...nova might not be able to handle this...without HMT....18:26
geoffarnoldamakarov is there a BP or set of user stories that we can start with?18:26
*** tsufiev has joined #openstack-keystone18:27
geoffarnoldamakarov Also we should loop in Congress and Quota experts... (I'm not - I'm an operator who wants to use HMT for federation, and who needs policy-based quotas and stuff)18:28
amakarovgeoffarnold, no, it's just an idea for now. I need to validate if first to understand the need18:28
samueldmqayoung: if we require one to have quota_admin in the project he's trying to change quota, the current policy enforcement works pretty fine18:28
geoffarnoldamakarov Sounds good. I've got to go to a meeting now; let's follow up in email: geoff@geoffarnold.com18:29
*** hrou has quit IRC18:30
samueldmqdolphm: dstanek would you suggest to send an email to operators list asking for feedback on this 'centralized policy' delivery ?18:30
*** hrou has joined #openstack-keystone18:30
ayoungsamueldmq, yeah.   It works fine, excpet that it makes no sense.  But, hey.  Sure.18:33
samueldmqayoung: well .. I think we should listen from nova/cinder guys on that alternative18:34
samueldmqayoung: since that changes very little of the current mechanism18:34
ayoungsamueldmq, so, if the role is on the project, then, sure,  you can add/edit quota for that proejct18:35
ayounglets see what they say on the ML18:35
samueldmqayoung: yes, the quota_admin role18:35
samueldmqayoung: on a project would grant you permission to hit the quota of that project18:35
samueldmqayoung: that's kind of Melanie proposed in her message :)18:37
*** ayoung has quit IRC18:40
*** geoffarnold has quit IRC18:42
*** e0ne has joined #openstack-keystone18:42
*** browne has quit IRC18:52
*** bitblt has joined #openstack-keystone18:55
*** davi8784 has joined #openstack-keystone18:57
*** snapdey has quit IRC18:57
*** bitblt has quit IRC18:58
*** TheIntern has quit IRC18:59
*** piyanai has joined #openstack-keystone19:01
*** jaosorior has quit IRC19:06
*** mylu has quit IRC19:08
*** Guest24740 has quit IRC19:10
*** mylu has joined #openstack-keystone19:10
*** diazjf has quit IRC19:11
*** jsavak has quit IRC19:12
*** jsavak has joined #openstack-keystone19:13
*** davi8784 has quit IRC19:17
*** lhcheng is now known as lhcheng_away19:20
*** amirosh has joined #openstack-keystone19:21
*** ajayaa has quit IRC19:22
amiroshHello, need help to understand how public_endpoint & admin_endpoint settings work in WSGI env, I assume both apps (in V2) are on the same port19:24
*** petertr7_away is now known as petertr719:24
*** mylu has quit IRC19:24
bknudsonpublic_endpoint and admin_endpoint are put into the links in the responses.19:26
*** mylu has joined #openstack-keystone19:27
amiroshright, that's why I'm asking - "Keystone API GET 5000/v3 returns wrong endpoint URL in response body" https://bugs.launchpad.net/keystone/+bug/138196119:28
openstackLaunchpad bug 1381961 in Keystone "Keystone API GET 5000/v3 returns wrong endpoint URL in response body" [Low,In progress] - Assigned to Alexey Miroshkin (amirosh)19:28
*** jsavak has quit IRC19:28
*** jsavak has joined #openstack-keystone19:28
openstackgerritMerged openstack/keystoneauth-saml2: py34 not py33 is tested and supported  https://review.openstack.org/20109119:29
amiroshIn V3 we have only one app now, so In case of eventlet I can check port and decide if it was request to admin or main app to return the right endpoint19:29
bknudsonI think that problem happens when you're running in eventlet19:29
bknudsonif you're running in wsgi then the applications are invoked independently so they know if they're admin or public19:30
samueldmqmorganfainberg: in HTTP, max-age is applied on the time the distant server generated the response (Date header) instead of local time19:30
samueldmqmorganfainberg: otherwise the cache_timeout would be 'misunderstood' because of the time the response takes to arrive (time spent in the web)19:31
samueldmqdoes that make sense ?19:31
amiroshbknudson: there is only one app for V3 (public), so it must be smart enough19:31
samueldmqmorganfainberg: actually I am supposed to be asking .. and I did'nt put any interrogation markers there :)19:31
morganfainbergmax-age is # of seconds19:32
morganfainbergiirc19:32
samueldmqmorganfainberg: yes it is19:32
morganfainbergso we don't care what datestamp it is applied to19:32
dstanekmorganfainberg: yes it is19:32
samueldmqmorganfainberg: in our case we should19:32
morganfainbergno[e19:32
morganfainbergnope*19:33
samueldmqtake the following example19:33
morganfainbergwe still only care about a fixed offset19:33
samueldmqyes it should, listen :)19:33
morganfainbergwhat is the difference between localtime + 120s vs remote_time + 120?19:33
samueldmqyou are the server, you generate the policy and say me it's valid for 30 seconds19:33
morganfainbergthey are still +12019:33
samueldmqthe response took 10 seconds to arrive to me19:33
bknudsonamirosh: v3 is handled on both public and admin.19:33
samueldmqI'll be using that for 10 seconds more than you expect me to be using19:34
samueldmqmorganfainberg: ^19:34
dstaneksamueldmq: why does that matter?19:34
htrutabknudson: in the mood for a +2 https://review.openstack.org/#/c/167613/3 ?19:34
samueldmqmorganfainberg: the difference is the time the response spend in the network19:34
*** topol has joined #openstack-keystone19:34
*** ChanServ sets mode: +v topol19:34
dstaneksamueldmq: max-age is basically saying "hold on to this for the next X seconds"19:34
morganfainbergnetwork speed should be assumed to be near 019:34
morganfainbergat a certain point you're overthinking it ;)19:35
*** snapdey has joined #openstack-keystone19:35
morganfainbergif we are distributing policy with a 10s latency [ or anything ], my answer is "uhh... fix your network"19:35
dstanekeven if it were not 0 we should assume the cache lifetimes are somewhat fluid and can never be exact19:35
samueldmqmorganfainberg: hmm .. dunno19:35
samueldmqmorganfainberg: that was just an example ..19:35
morganfainbergdstanek: I figure within a avg of 1s should be more than enough fluidity within an openstack deployment19:36
morganfainbergand under 1s, i call it "0" for purposes of cache19:36
morganfainbergsince...19:36
samueldmqdstanek: but if I applied the max-age to the server time, that would be exact, wouldn't it?19:36
morganfainbergcache has no resolution below 0 in these cases19:36
morganfainbergerm below 119:36
dstaneksamueldmq: no - you are telling the client to hold on to something for X seconds19:36
samueldmqwhat if I defined Expires instead of max-age19:37
dstaneksamueldmq: also it's important to remember that clients sometimes use the cached values slight longer than you say anyway19:37
samueldmqthat's basically my point19:37
morganfainbergdstanek: in this case we control both sides19:37
morganfainbergso we don't need to worry too much on over-aggressive caching19:37
samueldmqmorganfainberg: ++19:38
morganfainbergand iirc expires is the "old" way to do things19:38
amiroshbknudson: conceptually public and admin in V3 are identical, but technically there is only one app (public), but we need to return correct endpoint url in any case https://review.openstack.org/#/c/118522/19:38
morganfainbergif we can assume we are within a 1s window of network transit [a fair assertion for an openstack deployment, over 1s is going to be other types of wonky]19:38
samueldmqmorganfainberg: dstanek k if we can assume network time to be 0 (<1s) I agree completely with you then19:38
morganfainbergI think we're generally safe to assume network transit is effectively 019:38
bknudsonamirosh: eventlet only has one app but when running in apache you get separate apps.19:39
samueldmqI thought some installations could have some issues and take longer than that19:39
morganfainbergand a spike above 1s isn't going to realllllly break things19:39
*** topol has quit IRC19:39
morganfainbergbut consistent over 1s, i'm going to be shocked that openstack is really working19:39
dstaneksamueldmq: i wouldn't worry about that19:39
samueldmqmorganfainberg: that would give inconsistent results for calls in a service behind a HAProxy19:39
samueldmqmorganfainberg: in the case of spikes over 1 s19:39
morganfainbergsamueldmq: this follows with rule 1 of optimization: don't19:40
morganfainbergif the whole network is spiking over 1s latency, then so are user requests and it should normalize out19:40
dstaneksamueldmq: the real question is how are you calculating the max-age? expiry_time - now?19:40
morganfainbergdstanek: that was the thought (on the server side)19:41
openstackgerritHenrique Truta proposed openstack/keystone: Add is_domain field in Project Table  https://review.openstack.org/15742719:41
openstackgerritHenrique Truta proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376319:41
openstackgerritHenrique Truta proposed openstack/keystone: Change project name constraints  https://review.openstack.org/15837219:41
samueldmqdstanek: L36 https://review.openstack.org/#/c/188561/5/keystonemiddleware/auth_token/_policy.py19:41
amiroshbknudson: great, that's what I'm asking, will check details, appreciate any doc references, thanks!19:41
samueldmqdstanek: btw we don't need the policy_cache_time as you noticed in the spec .. :)19:41
dstaneksamueldmq: that's the client side right? _cache_timeout will come from the server's max-age?19:43
samueldmqmorganfainberg: dstanek so .... I am trying to overthink the things to do the better I/we can, so you can prune my thoughts where thinking too much isn't a necessary optimization19:43
bknudsonamirosh: https://review.openstack.org/#/c/118522/ just made the code less confusing, didn't actually fix eventlet server to work right.19:43
samueldmqif that makes sense :)19:43
bknudsonthe pipelines need to communicate somehow and there's no really good way to do it.19:43
samueldmqdstanek: yes that will ! that's in the server spec https://review.openstack.org/#/c/197980/19:43
dstaneksamueldmq: i'll take a look at these reviews again then19:44
samueldmqdstanek: (might need an update after the client one, which is what I am doing right now, after dolph and you 'throttling' it)19:45
amiroshbknudson: yes, I understand, there was always only one app19:45
samueldmqdstanek: I'll be sending a new version of the middleware spec in a couple of minutes ...19:45
samueldmqdstanek: thanks!19:45
dstaneksamueldmq: cool....i'm trying to get some unicodey things worked out anyway19:45
samueldmqdstanek: ++19:46
dstanekmorganfainberg: our str -> bytes -> str -> bytes -> bytes is driving me crazy19:46
morganfainbergdstanek: can we get a bytes->unicode->str->unicode->bytes->bytes->bytes->burger->bytes?19:47
*** browne has joined #openstack-keystone19:47
morganfainbergand when that fails, cast it all to an int and call it done19:47
*** ayoung has joined #openstack-keystone19:47
*** ChanServ sets mode: +v ayoung19:47
raildogit loh19:48
*** mylu has quit IRC19:48
samueldmqmorganfainberg: ahahahaha19:48
dstanekmorganfainberg: i'll create 'def burger' do the the conversions19:49
morganfainberg:)19:49
*** topol has joined #openstack-keystone19:49
*** ChanServ sets mode: +v topol19:49
rodrigodsgit log ^ raildo19:49
*** mylu has joined #openstack-keystone19:49
raildorodrigods: ++ :P19:49
rodrigods:w :P19:50
dstanekraildo: i do have a 'git lol' alias for git blame19:50
rodrigodsdsirrine, lol19:50
raildodstanek: hahaha19:50
rodrigodsoops19:50
rodrigodsdstanek,19:50
ayoungmorganfainberg, so, I have the absolute basics of a WIP patch.19:51
dstaneki also have it aliased to 'git wtf' - do depending on my mood i get to choose19:51
ayoungfor revoke events, but I cannot spend the time to bring it to production right now19:51
dstanekayoung: post it!19:51
raildodstanek: we can suggest more options to git19:52
openstackgerritayoung proposed openstack/keystone: Revoke Events in list  https://review.openstack.org/20526619:52
openstackgerritRodrigo Duarte proposed openstack/keystone: List projects filtering by is_domain flag  https://review.openstack.org/15839819:52
*** geoffarnold has joined #openstack-keystone19:52
ayoungdstanek, morganfainberg mfisch feel free to take it and run with it19:53
ayoungI'll be happy to review any further changes.19:54
*** diazjf has joined #openstack-keystone19:54
mfischayoung: thanks, I'm about to leave town for a trip but I can follow-along19:54
ayoungmfisch, I thought you were actually going to code this.19:55
*** hockeynut_afk has joined #openstack-keystone19:55
ayoungsamueldmq, so, what we were saying about "all permissions come from root" is true of quotas as well, I think.  All quota's should come from root, too.  quota really is a delegation, just like a role assignment19:56
*** Zanatoz has quit IRC19:56
*** dims has quit IRC19:58
*** geoffarnold has quit IRC19:58
samueldmqayoung: if you use role delegation mechanism (inherited assignment?) for quota operation, you are kind of delegating the quota management, aren't you ?19:59
samueldmqayoung: for that living in the policy (checking if you are scoped to a parent project) we'd need new checks, etc19:59
*** piyanai has quit IRC19:59
samueldmqayoung: I am not against, but we should consider the available alternatives19:59
*** amirosh has quit IRC20:01
ayoungsamueldmq, setting the quota is a delegation20:02
ayoungno quote means nothing delegated20:02
ayoungsamueldmq, just, the quota is delegated *to* the project20:03
openstackgerritMerged openstack/python-keystoneclient: Add get_token_data to token CRUD  https://review.openstack.org/19448420:04
ayoungsamueldmq, I'm not really suggesting that we do it, just that...well, it makes sense20:04
*** e0ne has quit IRC20:04
*** mylu has quit IRC20:05
samueldmqayoung: so you think it does make sense to update a quota of a child project with a token scoped to one of its parents20:05
samueldmqayoung: that makes sense to me too, as the other option does as well :)20:05
*** amakarov is now known as amakarov_away20:06
*** mylu has joined #openstack-keystone20:07
mfischayoung: I plan on sitting on the beach with a beer in my hand for 2 solid weeks, if I don't think at all about openstack it will be a good trip20:10
ayoungmfisch, so when you said "... but I can follow-along" I should have mentally added "but you won't"20:11
mfischlol, I can't like I'll likely be doing reviews and what not while I'm gone..20:12
morganfainbergmfisch: you should totally unplug from the ML and irc for the trip20:12
morganfainbergjust sayin'20:12
ayoungsamueldmq, I think that setting the  quote of a child should be done using the token of exactly its parent, no higher, no lower20:12
morganfainberg;)20:12
openstackgerritIan Cordasco proposed openstack/python-keystoneclient: Set reasonable defaults for TCP Keep-Alive  https://review.openstack.org/20474120:12
morganfainbergmfisch: otherwise you're clearly doing vacation wrong20:13
mfischtrue20:13
morganfainbergmfisch: beer and beach - it's a good start20:13
* morganfainberg is planning vacation post summit20:13
morganfainbergand you know I'll be disappearing for $vacation_time20:13
mfischI skipped last summer b/c I was in the process of selling my house20:13
openstackgerritMerged openstack/python-keystoneclient: Unit tests catch deprecated function usage  https://review.openstack.org/18914520:14
samueldmqayoung: yes, that makes sense20:15
ayoungsamueldmq, so, this was floated in the past.  The reasons why quota are not in Keystone are:20:15
*** yottatsa has quit IRC20:15
ayoung1.  It is based on values that are specific to the services20:15
ayoung2.  quota enforcement can't be done by keystone20:16
ayoung3.  quota distribution would be strange. You really would not want to put it in the token ,and notifications would be messy, too20:16
ayoungnow...per user quotas, maybe those could go in a token, but quotas tend to be per project20:17
samueldmqayoung: if we only allow the immediate parent to update20:17
samueldmqayoung: the issue with knowing the hierarhcy would be solved by including the immediate children in the token20:17
*** petertr7 is now known as petertr7_away20:17
ayoungsamueldmq,  the problem is that existing distributions don't have HMT20:18
ayoungso there are no "parent projects"20:18
ayoungand ruight now, nova does not know about domains20:18
openstackgerritIan Cordasco proposed openstack/keystoneauth: Set reasonable defaults for TCP Keep-Alive  https://review.openstack.org/20527620:19
samueldmqayoung: I think we shouldn't care about existing distributions at this point ... they shouldn't be using hierarchical quotas if they don't have HMT20:19
samueldmqayoung: and nova won't need to know about domains once we have reseller, that will be just projects, right ?20:20
*** petertr7_away is now known as petertr720:20
ayoungsamueldmq, call it a proejct or a domain, but in an HMT setup, you always need to have aparent if you are setting a quota20:21
stevemarbknudson: thanks for the infra fix20:22
bknudsonstevemar: no problem.20:22
samueldmqayoung: yes, so including the immediate children solves the problem, that defines the project which you can define the quota (in the approach you described)20:22
samueldmqayoung: (including in the token)20:22
ayoungsamueldmq, not gonna do that20:22
ayoungsamueldmq, they should reco0rd that info in Nova20:22
ayoungpolicy should be target.parent_proejhct_id = %{project_id}20:23
samueldmqayoung: makes sene20:24
samueldmqsense yes20:24
samueldmqanyway I think ericksonsantos is the right person to talk about all this quota stuff :)20:24
samueldmqayoung: I am just having parallel thoughts all the time and sharing :) (I think you know what I mean)20:25
samueldmqhehe20:25
raildoayoung: since we don't have the parent information in the token, we can't do this in the nova policy20:25
ayoungraildo, its not in the token20:26
ayoungits on the project object20:26
ayoungtarget is the object fetched from the DB, in this case it is a project20:26
raildoayoung: right, but we need to put this information in the nova context, right?20:26
*** piyanai has joined #openstack-keystone20:27
ayoungraildo, it should be there already, but maybe their project object does not have parent ID?20:28
ericksonsantosayoung, if this info is already in the token, we  won't need to make calls to keystone in order to know hierarchy info20:29
openstackgerritsonu proposed openstack/keystone: Replacing print with print() to provide py 2/3 compatibility  https://review.openstack.org/20528120:29
ayoungericksonsantos, it does not belong in the token20:29
ayoungericksonsantos, the token does not care about nova20:30
ericksonsantosayoung, I know, but I think it should be20:30
ayoungthe token is above it all, aloof, unmoving20:30
*** fangzhou has joined #openstack-keystone20:30
ayoungericksonsantos, seriously, though the hierarchy is outside the token contract20:30
ayounga tokne is scoped to a proejct.  THe fact that is a parent/child is irrelevant20:31
ericksonsantosayoung, hmm..20:31
ayoungericksonsantos, now...I had myslef 1/2 convince a moment ago that quotas should go into Keystone. BUt I recovered20:31
raildohaha20:31
ericksonsantosayoung, lol20:32
*** richm has quit IRC20:33
ayoungericksonsantos, I could see a "resource_type" field on the service, with a units measurement, and then a quota would be set by that...and if you request a token scoped to an endpoint, you would get the quota appropraite for the service you are trying to call on20:34
ayoungthen the quota value would be just another attribute for a policy check.20:35
*** jaosorior has joined #openstack-keystone20:35
ayoungat this point, morganfainberg is contemplating taking out a contract on my life to stop this type of mindless prattling20:36
morganfainbergnah, i can hold out until october20:36
morganfainberg:P20:37
ericksonsantosayoung, haha20:37
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Centralized Policies Fetch and Cache  https://review.openstack.org/13465520:38
ericksonsantosayoung, I'm still trying to understand what you've said20:38
samueldmqdstanek: dolphm lhcheng_away ^ just sent a new version, there is a *massive* change in that spec, thanks for your review20:39
*** snapdey has quit IRC20:39
*** richm has joined #openstack-keystone20:39
ayoungericksonsantos, http://www.goodreads.com/quotes/9347-i-know-that-you-believe-you-understand-what-you-think20:39
ericksonsantosayoung, hahahah20:40
dolphmsamueldmq: thanks, i'll give it another pass. is there an email out to operators?20:40
samueldmqdolphm: I will send it, just finished updating that spec .. too much things to fix :)20:40
samueldmqdolphm: btw I will be thinking more about the security aspects and enumerating potential attack vectors in the next version20:40
samueldmqdolphm: I didn't want to take longer to send a new patch set20:40
*** snapdey has joined #openstack-keystone20:41
*** markvoelker has quit IRC20:42
ericksonsantosayoung, I thought tokens could just be scoped to projects and domains20:42
samueldmqdolphm: morganfainberg ayoung I will draft the email message to operators and ask you guys to validate it20:43
*** e0ne has joined #openstack-keystone20:51
*** piyanai has quit IRC20:53
*** e0ne has quit IRC20:55
*** lhcheng_away is now known as lhcheng20:56
*** zzzeek has quit IRC21:01
*** arun_kant has joined #openstack-keystone21:02
*** arunkant_ has quit IRC21:02
*** zzzeek has joined #openstack-keystone21:04
*** snapdey has quit IRC21:06
*** lhcheng has quit IRC21:10
*** mylu has quit IRC21:10
*** petertr7 is now known as petertr7_away21:11
samueldmqdolphm: morganfainberg ayoung this is the message I am thinking now .. https://etherpad.openstack.org/p/centralized-policy-delivery-operators21:12
samueldmqlet me know your thoughts on it21:12
*** e0ne has joined #openstack-keystone21:12
pauloewertonhi there! can anyone confirm whether this is indeed a bug in keystoneauth: https://review.openstack.org/#/c/204253/?21:12
dolphmsamueldmq: s/for already in place mechanisms/for existing mechanisms/21:13
samueldmqdolphm: done21:13
dolphmsamueldmq: s/on that features/on this feature/21:13
samueldmqdolphm: yes this one was very bad English, thanks21:14
dolphmsamueldmq: s/distribution of the Centralized Policies/centralized distribution of policies/21:14
*** lhcheng has joined #openstack-keystone21:14
*** ChanServ sets mode: +v lhcheng21:14
*** lhcheng has quit IRC21:15
*** lhcheng has joined #openstack-keystone21:15
*** ChanServ sets mode: +v lhcheng21:15
samueldmqdolphm: done, btw feel free to add something if you think appropriate/needed21:17
dolphmsamueldmq: i'd suggest adding a more specific question to inspire feedback, rather than just "let me know your thoughts." for example, ask if deployers would be interested in managing policies via an API, rather than strictly through their configuration management systems.21:19
openstackgerrithenry-nash proposed openstack/keystone-specs: Clarify project hierarchy and parent usage within the API  https://review.openstack.org/20062421:19
*** snapdey has joined #openstack-keystone21:20
dolphmsamueldmq: you'll be more likely to get responses that way21:20
*** mgarza_ has joined #openstack-keystone21:20
*** dguerri is now known as dguerri`21:21
dolphmsamueldmq: also "centralized distribution" is a fairly common and well understood term... "centralized policy fetch and cache" would read much more naturally as "centralized policy distribution." caching should be assumed, IMO, but you can include it in the body if you think anyone will be concerned about it being missing21:22
ayoungsamueldmq, um.....hmmmm21:24
ayoungI don't think so....the centralized is only part of the the overall approach, just the first step, and that does not explain what we are trying to do.  I think if we only got that much through, the answer would be "don't do it"21:24
ayoungcentralized by itself does not get us much, and I would not suggest it without hierarchical roles, database management of policy, and so on.21:25
ayoungjust, you can't do any of that other stuff withou the distribution21:26
*** ninag has quit IRC21:28
*** r-daneel has quit IRC21:30
*** bknudson has quit IRC21:31
*** raildo has quit IRC21:32
*** snapdey has quit IRC21:33
*** zzzeek has quit IRC21:33
ayoungsamueldmq, I think the response you are going to get from that email is "why are you trying to replace puppet"  or ansible21:33
*** zzzeek has joined #openstack-keystone21:34
samueldmqdolphm: ok I will add more specific questions rather than asking for a general feedback21:34
dolphmsamueldmq: you can ask for general feedback as well, but direct questions will be more useful21:35
samueldmqayoung: makes sense, I will add something to say that's the base for the work that will be coming next21:35
samueldmqdolphm: ++21:35
*** snapdey has joined #openstack-keystone21:35
*** zzzeek has quit IRC21:35
dolphmsamueldmq: as ayoung just suggested, you could also allude to the additional features this opens this door for21:35
*** hakimo has joined #openstack-keystone21:36
*** hakimo_ has quit IRC21:36
*** e0ne has quit IRC21:38
*** sigmavirus24 is now known as sigmavirus24_awa21:43
*** TheIntern has joined #openstack-keystone21:44
*** pauloewerton has quit IRC21:46
*** ankita_w_ has joined #openstack-keystone21:46
*** ankita_wagh has quit IRC21:49
samueldmqdolphm: ayoung I just clarified/added the points you asked21:53
ayoungsamueldmq, people will still focus on the distribution of it.  Its why this has been so hard to communicate21:54
*** thedodd has joined #openstack-keystone21:55
samueldmqayoung: for now we are talking about what we propose for this cycle, that is th edistribution22:00
samueldmqayoung: I think it's clear it opens the door for other features22:00
ayoungsamueldmq, I know...beacuse that is all we could get in, because of the development process...and people are now going to suggest we postpone this because....22:00
samueldmqayoung: I don't see how we can talk more about the other things if we are proposing that :/22:00
samueldmqayoung: no I think we will get it ... we have the other bits already (defining the policy and associating to endpoints)22:02
samueldmqayoung: we just don't distribute :(22:02
samueldmqayoung: I really hope people aren't going to postpone this22:03
ayoungsamueldmq, at this point, I would not push for a general discussion of it22:03
ayoungits a keystone decision, and I think the best we can do is educate the smaller team about what we are trying to do.  The larger discussions need to happen at the summit22:04
samueldmqdstanek: dolphm cc ^ as this was originally proposed by you guys22:05
samueldmqayoung: I am ok with both, experience/opinion of the cores should decide it22:05
*** lhcheng_ has joined #openstack-keystone22:07
*** lhcheng has quit IRC22:07
dolphmsamueldmq: ayoung: without educating deployers on the benefits as early as possible, you're going to face a backlash by introducing extra complexity where both other projects and deployers have previously expressed a strong preference for the existing model: services own their own policy files and the distribution method is trivial22:07
*** cloudnull is now known as cloudull_zzz22:08
*** lhcheng_ has quit IRC22:08
*** htruta_ has joined #openstack-keystone22:08
*** lhcheng has joined #openstack-keystone22:08
*** ChanServ sets mode: +v lhcheng22:08
openstackgerritHenrique Truta proposed openstack/keystone: Restrict inherited role assignments to subdomains  https://review.openstack.org/16418022:09
ayoungdolphm, I agree.  Just that this one piece is just that;  the first step.   I had a presentation on dynamic policy at the last summit, as well as a cross project session there.  We'll do the same at the next.  I do have a presetnation that I gave at the midcycle.  I'm just worried that bringing up just the distro piece is going to be counter productive22:09
mfischlbragstad: dolphm you guys need to fix your bio on the fernet talk right now it just has your name and no pic or bio22:10
ayoungso, if we are going to make this a wider discussion, I'd recommen framing it in that context;  not just a bout distributuion, but about giveing policy a logical framework22:10
samueldmqdolphm: ayoung another point is that people may focus only in the distribution, and then postpone it .. but the distribution is just openning the door to other things22:10
*** geoffarnold has joined #openstack-keystone22:10
samueldmqayoung: yes, actuall that's what I tried to make clear with the text I added there ..22:10
samueldmqayoung: to make very  clear that's more than just distribution22:11
samueldmq"this feature opens the door for other potential features the Keystone team considers for future versions, including: ..."22:11
*** hakimo has quit IRC22:12
*** hakimo has joined #openstack-keystone22:13
*** mgarza_ has quit IRC22:15
*** jecarey has quit IRC22:16
*** TheIntern has quit IRC22:19
samueldmqmorganfainberg: henrynash ^^ I'd like to hear your toughts on this as well :)22:20
ayoungsamueldmq, if you can get the message clear, please do so.22:20
samueldmqayoung: the email message clearer? did you see the version that is in there now?22:21
samueldmqayoung: I can try to improve more that, to make clearer that this is the first step ..22:22
*** max_ has joined #openstack-keystone22:22
*** max_ is now known as Guest322022:22
*** Guest3220 has quit IRC22:23
*** jsavak has quit IRC22:23
*** maxabidi has joined #openstack-keystone22:23
flwangayoung: ping22:26
samueldmqayoung: will improve in a bit, brb22:27
flwangayoung: may i know is there any way to create a role which can only access a given service? like swift only22:27
*** edmondsw has quit IRC22:27
flwangor anybody can give me a tip how to create a role which can only access a given service? like swift only or zaqar only, thanks a lot22:29
*** nkinder has quit IRC22:30
*** snapdey has quit IRC22:31
*** snapdey has joined #openstack-keystone22:34
*** ankita_w_ has quit IRC22:37
*** maxabidi has quit IRC22:37
*** max_a has joined #openstack-keystone22:38
*** dims has joined #openstack-keystone22:39
htruta_hey ayoung (or any other cores)22:40
htruta_do you feel like reviewing some reseller patches?22:40
htruta_henrynash is already enjoying22:40
*** geoffarnold has quit IRC22:41
*** mkoderer has quit IRC22:44
*** stevemar has quit IRC22:46
*** doug-fish has left #openstack-keystone22:50
*** ankita_wagh has joined #openstack-keystone22:51
*** chlong has quit IRC22:52
*** diazjf has quit IRC22:53
*** david-lyle has quit IRC23:02
openstackgerritHenrique Truta proposed openstack/keystone: Honor domain operations in project table  https://review.openstack.org/14376323:03
*** hrou has quit IRC23:05
*** piyanai has joined #openstack-keystone23:06
ayoungflwang, you can create a role that only swift knows about by editing the policy file23:12
ayoungif you create a role called swiftinator and then in the swift policy file you would put a check role:swiftinator  for the API you want it to protext23:12
flwangayoung: so, I just need to create a role in keystone, and update the policy.json of swfit to let it understand, right?23:15
flwangbut meanwhile, should I update all the other policy.json, such as nova, cinder, glance, to ask them don't honour the role?23:15
flwangayoung: in other words, can I create a role like 'swift_only' and don't have default role 'Member'? not sure if there is any limitation in Keystone to allow a user just has a new role but doesn't have 'Member' or '_member_'23:17
openstackgerritHenrique Truta proposed openstack/keystone: Remove domain table references  https://review.openstack.org/16593623:18
*** gyee has joined #openstack-keystone23:20
*** ChanServ sets mode: +v gyee23:20
*** dims_ has joined #openstack-keystone23:24
*** dims has quit IRC23:27
*** jsavak has joined #openstack-keystone23:29
*** bknudson has joined #openstack-keystone23:31
*** ChanServ sets mode: +v bknudson23:31
*** browne has quit IRC23:33
*** gyee has quit IRC23:36
*** david-lyle has joined #openstack-keystone23:36
openstackgerritHenrique Truta proposed openstack/keystone: Bye Bye Domain Table  https://review.openstack.org/16185423:38
*** gyee has joined #openstack-keystone23:38
*** ChanServ sets mode: +v gyee23:38
*** snapdey has quit IRC23:42
*** gordc has joined #openstack-keystone23:44
*** darrenc is now known as darrenc_afk23:44
*** dims_ has quit IRC23:46
*** snapdey has joined #openstack-keystone23:48
*** jsavak has quit IRC23:50
*** thedodd has quit IRC23:50
*** snapdey has quit IRC23:50
*** jsavak has joined #openstack-keystone23:50
*** jiaxi has joined #openstack-keystone23:52
*** jsavak has quit IRC23:52
jiaxiGood morning. everyone.23:53
*** darrenc_afk is now known as darrenc23:54
jiaxihttps://review.openstack.org/#/c/204952/23:55
*** bhenderson has joined #openstack-keystone23:58

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