Tuesday, 2016-02-16

*** clenimar has joined #openstack-keystone00:02
*** dims has quit IRC00:04
*** dan_nguyen has joined #openstack-keystone00:06
*** mylu has quit IRC00:06
*** su_zhang has joined #openstack-keystone00:07
*** dims has joined #openstack-keystone00:11
*** clenimar has quit IRC00:11
*** gildub has joined #openstack-keystone00:12
*** mylu has joined #openstack-keystone00:13
*** mylu has quit IRC00:15
*** mylu has joined #openstack-keystone00:22
*** EinstCra_ has quit IRC00:31
*** su_zhang has quit IRC00:32
*** markvoelker has joined #openstack-keystone00:35
*** markvoelker has quit IRC00:39
*** gildub has quit IRC00:40
*** spzala has quit IRC00:47
*** spzala has joined #openstack-keystone00:47
*** su_zhang has joined #openstack-keystone00:47
*** aginwala has quit IRC00:51
*** spzala has quit IRC00:51
*** spzala has joined #openstack-keystone00:53
*** gildub has joined #openstack-keystone00:56
*** spzala_ has joined #openstack-keystone00:58
*** spzala has quit IRC00:58
*** spzala has joined #openstack-keystone01:01
*** spzala_ has quit IRC01:02
*** dims has quit IRC01:04
*** spzala has quit IRC01:05
*** jorge_munoz has joined #openstack-keystone01:05
*** dims has joined #openstack-keystone01:08
*** davechen has joined #openstack-keystone01:08
openstackgerritJorge Munoz proposed openstack/keystone: Consolidate TestTrustRedelegation and TestTrustAuth tests  https://review.openstack.org/28044701:10
*** jorge_munoz has quit IRC01:12
*** csoukup has joined #openstack-keystone01:12
openstackgerritTin Lam proposed openstack/keystone: Removing H405 violations from keystone  https://review.openstack.org/27819001:14
*** csoukup has quit IRC01:14
*** aginwala has joined #openstack-keystone01:17
*** mylu has quit IRC01:17
*** spzala has joined #openstack-keystone01:23
*** david-lyle has joined #openstack-keystone01:23
*** spzala has quit IRC01:27
*** diazjf has joined #openstack-keystone01:38
*** diazjf has quit IRC01:39
*** dan_nguyen has quit IRC01:43
*** mylu has joined #openstack-keystone01:48
*** jasonsb has quit IRC01:56
*** edmondsw_ has quit IRC01:56
openstackgerritayoung proposed openstack/keystone: Disable Admin tokens set to None  https://review.openstack.org/28046701:56
*** jasonsb has joined #openstack-keystone01:57
*** spzala has joined #openstack-keystone01:57
openstackgerritfengzhr proposed openstack/keystone: The name can be just white character except project and user  https://review.openstack.org/27235802:06
*** su_zhang has quit IRC02:26
*** su_zhang has joined #openstack-keystone02:26
*** shoutm_ has joined #openstack-keystone02:31
*** shoutm has quit IRC02:33
*** markvoelker has joined #openstack-keystone02:36
openstackgerritMerged openstack/keystone: Avoid `None` as a redundant argument to dict.get()  https://review.openstack.org/28031902:36
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28047702:39
*** markvoelker has quit IRC02:40
*** su_zhang has quit IRC02:43
*** dan_nguyen has joined #openstack-keystone02:44
*** mylu has quit IRC02:44
*** mylu has joined #openstack-keystone02:48
*** mylu has quit IRC02:52
*** mylu has joined #openstack-keystone02:55
*** gildub has quit IRC02:59
*** xavier_ has joined #openstack-keystone03:12
xavier_good night everyone03:13
xavier_I'm facing an error when restarting keystone on devstack: ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option03:15
openstackgerritMerged openstack/keystone: Fix terms from patch 275706  https://review.openstack.org/28043603:15
xavier_do you have any idea why this is happening?03:15
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28047703:16
*** neophy has joined #openstack-keystone03:17
*** aginwala has quit IRC03:19
openstackgerritMerged openstack/keystone: Avoid "non-Pythonic" method names  https://review.openstack.org/28030903:22
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28047703:24
*** gildub has joined #openstack-keystone03:28
stevemarxavier_: any other information?03:29
*** ccard__ has joined #openstack-keystone03:31
*** xavier_ has quit IRC03:32
*** ccard_ has quit IRC03:34
*** shoutm_ has quit IRC03:34
*** ccard_ has joined #openstack-keystone03:35
*** ccard__ has quit IRC03:36
*** dims has quit IRC03:37
*** xavier_ has joined #openstack-keystone03:38
*** aginwala has joined #openstack-keystone03:38
*** spzala has quit IRC03:38
xavier_@stevemar: https://etherpad.openstack.org/p/bug03:39
*** spzala has joined #openstack-keystone03:39
xavier_@stevemar: thats all03:39
davechenxavier_: how do you restart keystone?03:40
*** shoutm has joined #openstack-keystone03:40
openstackgerritMerged openstack/keystone: Allow project_id in catalog substitutions  https://review.openstack.org/27957603:41
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28047703:42
davechenxavier_: sometimes, the service is not acutally stopped before started if you typing 'restart', try to stop it at first and them start it again.03:44
*** spzala has quit IRC03:44
xavier_I was trying to kill the processes on rejoin-stack.sh03:47
xavier_devechen: I was trying to kill the processes on rejoin-stack.sh*03:47
xavier_devechen: crtl + c on 'key' (rejoin-stack.sh)03:49
davechenxavier_: i was facing this issue like this, the workaroud is making sure the service is really stopped and start it again, this might be a bug and could be fixed in keystone.03:49
davechenxavier_: crtl + c on 'key' doesn't work03:50
xavier_devechen: so, how to make sure the service is stopped?03:51
davechenxavier_: keytone is running with apache, you cannot stop the service by ctrl + c03:51
davechenxavier_: the easy way is restart apache2 instead.03:51
xavier_devechen: roger that, trying it now03:52
davechenxavier_: good luck03:52
*** davechen is now known as davechen_afk03:52
*** xavier_ has quit IRC03:58
*** daemontool has quit IRC04:02
*** Nirupama has joined #openstack-keystone04:03
*** david-lyle has quit IRC04:03
stevemarjamielennox: poke04:04
jamielennoxstevemar: hmm04:04
stevemarjamielennox: gotta bug you about this bug (pun not intended)04:05
stevemarhttps://bugs.launchpad.net/keystonemiddleware/+bug/154248604:05
openstackLaunchpad bug 1542486 in OpenStack Compute (nova) "nova-compute stack traces with BadRequest: Specifying 'tenant_id' other than authenticated tenant in request requires admin privileges" [Undecided,Incomplete]04:05
*** gildub has quit IRC04:09
jamielennoxstevemar: i'm not sure what the issue is04:10
openstackgerritMerged openstack/pycadf: Add docstring validation  https://review.openstack.org/23025704:11
stevemarjamielennox: me either!04:12
*** mylu has quit IRC04:16
jamielennoxstevemar: added comment - it's kind of a guess based on the error message, but i don't know what to do without the environment04:16
*** mylu has joined #openstack-keystone04:17
*** mylu has quit IRC04:19
stevemarjamielennox: review https://review.openstack.org/#/c/279872/ if you can, it's an easy requirements clean up04:20
stevemarjamielennox: gonna release ksa/ksm tomorrow (today for you)04:20
jamielennoxstevemar: done04:21
*** dan_nguyen has quit IRC04:22
*** dan_nguyen has joined #openstack-keystone04:26
*** mylu has joined #openstack-keystone04:28
*** mylu has quit IRC04:29
*** mylu has joined #openstack-keystone04:31
*** k-ishii_ has joined #openstack-keystone04:31
*** anzen has joined #openstack-keystone04:33
*** hid-kanetoshi has joined #openstack-keystone04:33
*** r-mizuno has joined #openstack-keystone04:33
*** hid-kanetoshi has quit IRC04:34
*** k-ishii_ has quit IRC04:34
*** gildub has joined #openstack-keystone04:34
stevemarty!04:34
*** anzen has quit IRC04:35
*** markvoelker has joined #openstack-keystone04:36
*** spzala has joined #openstack-keystone04:39
*** markvoelker has quit IRC04:41
*** dan_nguyen has quit IRC04:41
*** r-mizuno has quit IRC04:42
*** spzala has quit IRC04:45
*** dave-mccowan has quit IRC04:47
*** fawadkhaliq has joined #openstack-keystone04:52
*** david-lyle has joined #openstack-keystone04:55
*** jasonsb has quit IRC05:09
*** subscope has joined #openstack-keystone05:09
*** jasonsb_ has joined #openstack-keystone05:10
openstackgerritMerged openstack/keystoneauth: Cleanup test-requirements.txt  https://review.openstack.org/27987205:11
stevemardavechen_afk: poke: https://review.openstack.org/#/c/280435/05:13
*** davechen_afk is now known as davechen05:18
davechenstevemar: done :)05:19
*** mylu has quit IRC05:24
stevemar\o/05:24
*** mylu has joined #openstack-keystone05:25
openstackgerritSteve Martinelli proposed openstack/keystone: wsgi: fix base_url finding  https://review.openstack.org/22646405:33
*** spzala has joined #openstack-keystone05:41
*** mylu has quit IRC05:42
*** spzala has quit IRC05:46
*** mylu has joined #openstack-keystone05:51
*** Ephur has joined #openstack-keystone05:53
*** wanghua has quit IRC05:54
*** mylu has quit IRC05:54
*** su_zhang has joined #openstack-keystone06:03
openstackgerritMerged openstack/keystone: Updating sample configuration file  https://review.openstack.org/28047706:05
*** neophy has quit IRC06:15
*** gildub has quit IRC06:20
*** jaosorior has joined #openstack-keystone06:20
*** vgridnev_ has joined #openstack-keystone06:23
*** subscope has quit IRC06:34
*** markvoelker has joined #openstack-keystone06:37
*** aginwala has quit IRC06:38
*** david-lyle has quit IRC06:39
*** david-lyle has joined #openstack-keystone06:40
*** spzala has joined #openstack-keystone06:41
*** markvoelker has quit IRC06:42
*** GB21 has joined #openstack-keystone06:43
*** zzzeek has quit IRC06:44
*** spzala has quit IRC06:47
openstackgerritMerged openstack/keystone: Fixes parameter in duplicate project name creation  https://review.openstack.org/28044806:50
*** subscope has joined #openstack-keystone06:52
openstackgerritjaveme proposed openstack/python-keystoneclient: Encode the url parameters for base.CrudManager  https://review.openstack.org/25415406:53
*** subscope has quit IRC06:55
*** e0ne has joined #openstack-keystone07:02
*** _cjones_ has joined #openstack-keystone07:04
*** _cjones_ has quit IRC07:06
*** _cjones_ has joined #openstack-keystone07:06
openstackgerritSteve Martinelli proposed openstack/keystone: wsgi: fix base_url finding  https://review.openstack.org/22646407:20
*** kiranr_ has joined #openstack-keystone07:32
*** kiranr_ is now known as kiran-r07:33
*** rcernin has joined #openstack-keystone07:37
*** GB21 has quit IRC07:40
*** lhcheng has joined #openstack-keystone07:41
*** ChanServ sets mode: +v lhcheng07:41
*** spzala has joined #openstack-keystone07:44
*** ekarlso has quit IRC07:44
*** Anticimex has quit IRC07:45
*** kragniz has quit IRC07:46
*** kragniz has joined #openstack-keystone07:46
*** Anticimex has joined #openstack-keystone07:46
*** spzala has quit IRC07:48
*** fawadkhaliq has quit IRC07:51
*** fawadkhaliq has joined #openstack-keystone07:52
*** fawadkhaliq has quit IRC07:52
*** fawadkhaliq has joined #openstack-keystone07:52
*** fawadkhaliq has quit IRC07:53
*** fawadkhaliq has joined #openstack-keystone07:53
*** ekarlso has joined #openstack-keystone07:57
*** jed56 has joined #openstack-keystone08:08
openstackgerritSteve Martinelli proposed openstack/keystone: encode user id for notifications  https://review.openstack.org/28054208:13
*** e0ne has quit IRC08:13
*** subscope has joined #openstack-keystone08:21
openstackgerritMerged openstack/keystone: sensible default for secure_proxy_ssl_header  https://review.openstack.org/28043508:22
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28054508:24
*** su_zhang has quit IRC08:27
*** _cjones_ has quit IRC08:29
*** shoutm has quit IRC08:31
*** shoutm has joined #openstack-keystone08:33
*** vgridnev_ has quit IRC08:33
*** vgridnev has joined #openstack-keystone08:34
*** henrynash has joined #openstack-keystone08:37
*** ChanServ sets mode: +v henrynash08:37
*** vgridnev has quit IRC08:38
*** vgridnev_ has joined #openstack-keystone08:39
*** GB21 has joined #openstack-keystone08:41
*** vgridnev_ has quit IRC08:42
*** vgridnev has joined #openstack-keystone08:43
*** vgridnev has quit IRC08:44
*** subscope has quit IRC08:50
*** fhubik has joined #openstack-keystone08:53
*** fhubik is now known as fhubik_brb08:53
*** fhubik_brb is now known as fhubik09:03
*** subscope has joined #openstack-keystone09:04
*** kiran-r has quit IRC09:08
*** kiran-r has joined #openstack-keystone09:09
*** mhickey has joined #openstack-keystone09:11
*** e0ne has joined #openstack-keystone09:16
*** d0ugal has quit IRC09:21
*** d0ugal has joined #openstack-keystone09:21
*** lhcheng has quit IRC09:26
*** mvk has quit IRC09:27
*** shoutm_ has joined #openstack-keystone09:31
*** shoutm has quit IRC09:32
*** akscram has quit IRC09:33
*** akscram has joined #openstack-keystone09:33
*** subscope has quit IRC09:40
*** spzala has joined #openstack-keystone09:45
*** subscope has joined #openstack-keystone09:47
*** fawadkhaliq has quit IRC09:48
*** fawadkhaliq has joined #openstack-keystone09:48
*** davechen has left #openstack-keystone09:49
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add return-request-id-to-caller function(v2_0)  https://review.openstack.org/26744909:50
*** fawadkhaliq has quit IRC09:50
*** fawadkhaliq has joined #openstack-keystone09:50
*** spzala has quit IRC09:50
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add return-request-id-to-caller function(v3)  https://review.openstack.org/26745609:51
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add return-request-id-to-caller function(v3/contrib)  https://review.openstack.org/26800309:53
*** mvk has joined #openstack-keystone09:54
*** fawadkhaliq has quit IRC09:54
*** fawadkhaliq has joined #openstack-keystone09:55
*** GB21 has quit IRC10:08
*** GB21 has joined #openstack-keystone10:09
*** fhubik is now known as fhubik_brb10:21
*** fhubik_brb is now known as fhubik10:21
*** GB21 has quit IRC10:24
openstackgerritMerged openstack/keystone: Updating sample configuration file  https://review.openstack.org/28054510:26
*** GB21 has joined #openstack-keystone10:26
*** GB21 has quit IRC10:33
*** spzala has joined #openstack-keystone10:46
samueldmqmorning keystoners10:46
*** GB21 has joined #openstack-keystone10:47
*** subscope has quit IRC10:47
*** pece has joined #openstack-keystone10:50
*** spzala has quit IRC10:50
*** dims has joined #openstack-keystone10:51
*** dave-mccowan has joined #openstack-keystone11:04
henrynashsamuedlmq: mornin11:04
henrynashsamueldmq: hey, got a random question for you if you have a moment11:04
samueldmqhenrynash: hi, sure11:05
henrynashsamueldmq: trusts…..take a look at https://bugs.launchpad.net/keystone/+bug/154603911:05
openstackLaunchpad bug 1546039 in OpenStack Identity (keystone) "If one trustor role is removed, the trust cannot be used" [Undecided,New]11:05
henrynashsamueldmq: I just raised this….how do you think it is meant  to work11:06
henrynash?11:06
samueldmqhenrynash: it may work both way, it depends on what the use cases/preferences are11:07
henrynashsamueldmq: I know exacly how ro fix this (patch on its way)…but just want to make sure what the expected rsult shoul dbe11:07
samueldmqhenrynash: both may make sense, for example:11:08
samueldmqi) if you have project_admin and project_member and admin has been remove, maybe you can get a token with member only and do things that will be useful11:08
samueldmqii) if you have nova_create and glance_read and glance_read has been revoked, it doesn't matter to have nova_create anyways if you can't read the image for a vm11:09
samueldmqmaybe the default could be 'get all or fail', but a special query_param in the request allow it ? (since both cases above make sense and it would be up to the caller ? ) ^11:10
samueldmq(this is a third option)11:10
henrynashso sure, I can imagine the user scenarios being different…..I guess it is more should our code issue a “partial token” if it finds some of the roles of the trustor have been removed11:10
henrynashmaybe, indeed11:10
henrynashso I’ll post the patches, and then get ayoung on teh case later!11:11
*** dims has quit IRC11:12
samueldmqhenrynash: nice11:13
openstackgerrithenry-nash proposed openstack/keystone: Demonstrate defect in trusts if a role is unassigned  https://review.openstack.org/28061011:14
*** fhubik has quit IRC11:14
samueldmqhenrynash: do you see a trust as a delegation or a set of delegations ?11:15
samueldmqif it's *a delegation* of a set of roles, then it should be revoked too upon assignment revocation11:17
samueldmqif it's a set of role delegations, then the set doesn't disappear when one of the delegations are removed from the set11:17
samueldmqhenrynash: makes sense ? I really can see it either way :)11:18
*** subscope has joined #openstack-keystone11:18
*** dims has joined #openstack-keystone11:24
*** GB21 has quit IRC11:25
*** d0ugal has quit IRC11:36
*** rodrigods has quit IRC11:38
henrynashsamueldmq: rght11:38
*** rodrigods has joined #openstack-keystone11:38
henrynashsamueldmq: right, agreed11:38
*** dims has quit IRC11:38
openstackgerrithenry-nash proposed openstack/keystone: Fix defect in trusts if a role is unassigned  https://review.openstack.org/28062111:41
openstackgerrithenry-nash proposed openstack/keystone: Modify rules in the v3 policy sample for domain specifc roles  https://review.openstack.org/26207811:43
*** GB21 has joined #openstack-keystone11:45
*** fawadkhaliq has quit IRC11:45
*** fawadkhaliq has joined #openstack-keystone11:45
*** fawadkhaliq has quit IRC11:46
*** fawadkhaliq has joined #openstack-keystone11:46
*** spzala has joined #openstack-keystone11:47
*** fawadkhaliq has quit IRC11:47
*** fawadkhaliq has joined #openstack-keystone11:47
*** fawadkhaliq has quit IRC11:47
*** rodrigods has quit IRC11:47
*** rodrigods has joined #openstack-keystone11:48
*** fawadkhaliq has joined #openstack-keystone11:48
*** spzala has quit IRC11:51
openstackgerrithenry-nash proposed openstack/keystone: Modify implied roles to honor domain specific roles  https://review.openstack.org/26306411:54
openstackgerrithenry-nash proposed openstack/keystone: Modify rules for domain specific role assignments  https://review.openstack.org/26354911:55
*** d0ugal has joined #openstack-keystone12:00
*** d0ugal has quit IRC12:00
*** d0ugal has joined #openstack-keystone12:00
*** GB21 has quit IRC12:02
*** sdake has quit IRC12:06
*** fawadkhaliq has quit IRC12:06
*** fawadk has joined #openstack-keystone12:06
*** sdake has joined #openstack-keystone12:06
*** raildo-afk is now known as raildo12:11
*** fawadk has quit IRC12:11
*** mvk has quit IRC12:13
*** ericksonsantos has joined #openstack-keystone12:13
*** mvk has joined #openstack-keystone12:15
*** raildo is now known as raildo-afk12:16
*** pcaruana has joined #openstack-keystone12:18
*** raildo-afk is now known as raildo12:20
*** raildo is now known as raildo-afk12:25
openstackgerritAlexander Makarov proposed openstack/keystone: Enable support for posixGroups in LDAP  https://review.openstack.org/25852812:29
*** raildo-afk is now known as raildo12:31
*** archers has joined #openstack-keystone12:41
*** archers has quit IRC12:43
openstackgerritAlexander Makarov proposed openstack/keystone: Enable support for posixGroups in LDAP  https://review.openstack.org/25852812:46
*** spzala has joined #openstack-keystone12:47
*** gordc has joined #openstack-keystone12:51
*** annasort has quit IRC12:52
*** spzala has quit IRC12:52
*** boris-42 has joined #openstack-keystone12:56
*** davechen has joined #openstack-keystone12:59
openstackgerritAlexander Makarov proposed openstack/keystone: Enable support for posixGroups in LDAP  https://review.openstack.org/25852813:01
openstackgerritDavid Stanek proposed openstack/keystone: Enables the notification tests in py3  https://review.openstack.org/28067113:01
openstackgerritDavid Stanek proposed openstack/keystone: Fix keystone.common.wsgi to explicitly use bytes  https://review.openstack.org/28067213:01
openstackgerritDavid Stanek proposed openstack/keystone: Fixes the templated backend tests for Python3  https://review.openstack.org/28067313:01
openstackgerritDavid Stanek proposed openstack/keystone: Fixes to get cert tests running in Py3  https://review.openstack.org/28067413:01
openstackgerritDavid Stanek proposed openstack/keystone: Fixes hacking for Py3 tests  https://review.openstack.org/28067513:01
*** mvk has quit IRC13:02
*** edmondsw has joined #openstack-keystone13:03
samueldmqdstanek: wow13:05
*** mvk has joined #openstack-keystone13:05
dstaneksamueldmq: howdy13:07
*** bdossant has joined #openstack-keystone13:07
samueldmqdstanek: hey :)13:08
samueldmqdstanek: so files removed from tests-py3-blacklist.txt are automaticlly ran against py313:08
dstaneki had some stuff that's been sitting around for a bit13:08
dstaneksamueldmq: yes13:09
dstaneksamueldmq: i have lots more tests working! but the code change is awful right now. i have to fix when i have the time13:09
samueldmqdstanek: cool, will look at it13:10
samueldmqdstanek: yes, this is the type of things that need quick review/merge13:10
samueldmqdstanek: otherwise is a bit painful to maintain13:10
dstanekyup.13:11
*** doug-fish has joined #openstack-keystone13:14
openstackgerrithenry-nash proposed openstack/keystone: Allow project domain_id to be nullable at the manager level  https://review.openstack.org/26453313:15
openstackgerrithenry-nash proposed openstack/keystone: Verify project unique constraints for projects acting as domains  https://review.openstack.org/15837213:20
samueldmqhenrynash: +2'ed ^13:21
henrynashsamueldmq: thx!13:21
openstackgerrithenry-nash proposed openstack/keystone: Add tests in preparation of projects acting as a domain  https://review.openstack.org/27236913:21
openstackgerrithenry-nash proposed openstack/keystone: Add is_domain filter to v3 list_projects  https://review.openstack.org/15839813:22
henrynashayoung: ping13:26
*** davechen1 has joined #openstack-keystone13:28
*** davechen has quit IRC13:31
*** spzala has joined #openstack-keystone13:31
*** doug-fish has quit IRC13:34
marekddolphm: hi13:35
dolphmmarekd: o/13:35
marekddolphm: you wanted to chat on pysaml in keystone13:35
dolphmmarekd: i was wondering if you'll have time to start making traction on a PoC for Newton?13:36
marekddolphm: I am unsure on my priorities for next release. If so, that would probably become my highest priority and majority of my time.13:37
*** davechen has joined #openstack-keystone13:37
dolphmmarekd: that would be awesome if so :)13:38
dolphmmarekd: is it something you want to work on?13:38
*** markvoelker has joined #openstack-keystone13:39
marekddolphm: since this time that would not be as interchangeable as with apache modules i'd first kick off some discussion (user survey?) on which protocol we sohuld work on - saml or oidc.13:39
*** davechen1 has quit IRC13:40
marekddoes Rackspace have preferences?13:40
dolphmmarekd: i imagine SAML - i have yet to hear of anyone interested in OIDC beyond IBM (?)13:40
dolphmmarekd: SAML was the clear preference before we went down the shibboleth route too13:41
marekdaha13:41
marekdok13:41
marekdwell, it was 'let's make protocol agnostic solution first' and I was more like referring to SAML always as it's something I  have here.13:42
*** EinstCrazy has joined #openstack-keystone13:42
dolphmmarekd: true13:42
openstackgerrithenry-nash proposed openstack/keystone: Projects acting as domains  https://review.openstack.org/23128913:44
*** dims has joined #openstack-keystone13:45
*** StefanPaetowJisc has joined #openstack-keystone13:46
anteayaStefanPaetowJisc:13:46
anteayahi13:46
anteayaso hey keysstone folks13:46
anteayathis is StefanPaetowJisc13:46
StefanPaetowJiscHi! :-)13:47
anteayastefan is at the ops meetup in manchester with me13:47
anteayaStefanPaetowJisc: works with an educational group in the uk13:47
StefanPaetowJiscCorrect... I work for the UK equivalent of Internet213:47
anteayaand would like to learn how to contribute to keystone13:47
anteayahe has a specific functionality that he feels would be useful in keystone13:48
anteayaand would like to learn how to communicate that to folks13:48
StefanPaetowJiscIndeed... in the EU there's a lot of focus on federation and some of our collaborators (like the University of Kent through David Chadwick) have already contributed some changes to make that happen.13:50
*** dims has quit IRC13:51
StefanPaetowJiscThe one thing that's sort-of the holy grail I suppose is making that work on the command-line. We'd like to see how we can help with this through GSSAPI support in Keystone, or any other modules that use GSSAPI.13:52
*** subscope has quit IRC13:53
dstanekStefanPaetowJisc: it would probably be a good idea to write up a short summary for what you are thinking so that is can be discussed.13:53
anteayadstanek: would something on an etherpad be sufficient as a beginning?13:54
anteayadstanek: and good morning13:54
dstanekStefanPaetowJisc: just don't get caught up too much in the details13:54
StefanPaetowJisc*nod* Is there any specific format you need it in?13:54
dstanekanteaya: probably at first. the end result should probably be a spec13:54
anteayaawesome13:54
dstanekanteaya: good morning!13:54
anteaya:)13:55
anteayaStefanPaetowJisc: I've created this for you: https://etherpad.openstack.org/p/JISC-GSSAPI13:55
dstanekStefanPaetowJisc: we have a spec template if you want to submit as a spec, but if you do i would say not to stress on filling out all of the sections.13:55
StefanPaetowJiscAhh, thank you very much.13:55
anteayaStefanPaetowJisc: start by getting the rough draft in the etherpad13:56
anteayathen you can transfer to a spec13:56
StefanPaetowJiscOk.13:56
dstanekStefanPaetowJisc: also note that depending on the implementation some logic may be ksc and some osc13:56
*** davechen has left #openstack-keystone13:57
StefanPaetowJiscosc? Pardon my ignorance, please.13:57
dstanekStefanPaetowJisc: oh, and welcome!13:57
anteayaI'll add the keystone-spec template to the etherpad13:57
StefanPaetowJiscThank you. :-)13:57
dstanekopenstack client - this is the actual command line interface for openstack services13:57
StefanPaetowJiscAhhh. Of course. Thanks.13:57
StefanPaetowJiscThat's the 'new' client, yes?13:57
dstanekthe keystone client is losing it's ability to be a standalone command line client13:58
anteayaStefanPaetowJisc: yes the openstack client is the way of the future13:58
anteayait actually is older than some of the clients but it is the selected point of convergence13:58
anteayanow we just have to converge13:59
StefanPaetowJiscOk. Thanks for the clarification :-)14:00
dstanekStefanPaetowJisc: once you are done, the best way to get a consensus is to get on the meeting agenda to talk through your idea14:02
*** doug-fish has joined #openstack-keystone14:02
StefanPaetowJiscOk. To do that, subscription to a mailing list?14:02
*** raildo is now known as raildo-afk14:03
anteayaStefanPaetowJisc: http://eavesdrop.openstack.org/#Keystone_Team_Meeting14:03
anteayayou should see the details about the keystone team meeting there14:03
StefanPaetowJiscAhh, thanks Anita.14:03
anteayaattending a few prior to you wanting to discuss your spec will help you understand the workflow14:03
anteayaStefanPaetowJisc: welcome :)14:03
StefanPaetowJisc*nod* Understood14:04
anteayathe team meeting happens today in 4 hours14:05
*** shoutm_ has quit IRC14:08
*** kiran-r has quit IRC14:08
*** StefanPaetowJisc has quit IRC14:08
*** mvk has quit IRC14:09
*** StefanPaetowJisc has joined #openstack-keystone14:09
*** raildo-afk is now known as raildo14:11
*** Guest76507 is now known as med_14:12
*** med_ has quit IRC14:12
*** med_ has joined #openstack-keystone14:12
*** Nirupama has quit IRC14:13
StefanPaetowJiscYes... I'll have to try and attend the one next week... I've got the 'other' Openstack meeting in town to attend :-)14:14
anteayafair enough14:14
*** jaosorior has quit IRC14:16
*** jaosorior has joined #openstack-keystone14:17
*** petertr7_away is now known as petertr714:18
*** ninag has joined #openstack-keystone14:20
*** mvk has joined #openstack-keystone14:21
*** henrynash_ has joined #openstack-keystone14:22
*** ChanServ sets mode: +v henrynash_14:22
*** subscope has joined #openstack-keystone14:22
StefanPaetowJiscOk, I'll jot some thoughts down on the Etherpad, and then see whether we can bash that into a reasonable version of a spec? :-)14:22
*** henrynash has quit IRC14:23
*** henrynash_ is now known as henrynash14:23
*** EinstCra_ has joined #openstack-keystone14:25
*** EinstCrazy has quit IRC14:28
dstanekStefanPaetowJisc: also you may want to get ayoung's feedback specifically because he is all about kerberos and related things14:35
StefanPaetowJiscOk. Will do.14:35
*** zzzeek has joined #openstack-keystone14:35
*** shoutm has joined #openstack-keystone14:40
*** eandersson has joined #openstack-keystone14:51
eanderssonSilly question, but did 5000/v3/tenants ever work?14:53
eanderssonor was it always 5000/v3/projects?14:53
edmondsweandersson I believe it's always been /v3/projects14:53
eanderssonThats what I thought, but just wanted to double check.14:54
eanderssonThanks14:54
edmondsweandersson maybe I should let someone that was actually working on keystone back then answer, though :)14:55
edmondswnotmorgan ^14:55
notmorganV3 has always been projects14:55
notmorganV2 was tenants14:56
eanderssonthanks notmorgan14:56
eanderssonI was mostly thinking in case tenants was previously supported for some weird backwards compatibility or something14:57
eanderssonBasically just wanted to make sure this silly error wasn't just because of an upgrade to Liberty =]14:57
edmondswI was using keystone v3 in havana, and it was /v3/projects there :)14:58
*** subscope has quit IRC14:59
openstackgerrithenry-nash proposed openstack/keystone: Tidy up configuration documentation for inherited assignments  https://review.openstack.org/28074714:59
eanderssonI didn't dare to try v3 until Kilo haha =]14:59
openstackgerrithenry-nash proposed openstack/keystone: Tidy up configuration documentation for inherited assignments  https://review.openstack.org/28074715:01
openstackgerrithenry-nash proposed openstack/keystone: Tidy up configuration documentation for inherited assignments  https://review.openstack.org/28074715:03
*** EinstCra_ has quit IRC15:04
*** EinstCrazy has joined #openstack-keystone15:04
*** shoutm has quit IRC15:05
*** subscope has joined #openstack-keystone15:06
openstackgerritAlexander Makarov proposed openstack/keystone: Enable support for posixGroups in LDAP  https://review.openstack.org/25852815:07
openstackgerritChaozhe Chen(ccz) proposed openstack/keystone: Trivial: Cleanup unused conf variables  https://review.openstack.org/28075215:09
openstackgerrithenry-nash proposed openstack/keystone: Clean up configuration documentataion on v2 user CRUD  https://review.openstack.org/28075515:10
openstackgerrithenry-nash proposed openstack/keystone: Tidy up configuration documentation for inherited assignments  https://review.openstack.org/28074715:11
*** EinstCrazy has quit IRC15:12
*** sigmavirus24_awa is now known as sigmavirus2415:13
stevemarmorning all15:13
henrynashstevemar: morning15:14
*** EinstCrazy has joined #openstack-keystone15:14
stevemarmarekd: dolphm PoC?15:15
stevemarmarekd:  dolphm plenty of ibm'ers interested in oidc :)15:15
dolphmstevemar: ?15:15
openstackgerrithenry-nash proposed openstack/keystone: Don't describe trusts as an extension in configuration doc  https://review.openstack.org/28076115:15
stevemardolphm: you and marekd were talking about something -- hours ago, saml and oidc15:16
dolphmstevemar: yes?15:16
stevemardolphm: ohhh nvm "anyone interested in OIDC beyond IBM (?)"15:16
*** mkoderer__ has quit IRC15:16
stevemar*beyond*15:16
*** mkoderer__ has joined #openstack-keystone15:17
dstanekmarekd: stevemar: with federation the assertion headers always have a prefix right? like SAML_, PFX_ or something15:19
dstanekOh, I Don't Care?15:19
marekddstanek: at which lever?15:20
marekdlevel15:20
dstanekstevemar: finishing up some work on https://review.openstack.org/#/c/27990815:20
*** su_zhang has joined #openstack-keystone15:20
marekddstanek: are you talking input for mapping engine?15:20
dstanekmarekd: i'm looking at the keystone.federation.utils.get_assertion_params_from_env15:20
marekddstanek: so the prefix is configurable15:20
dstanekmarekd: it looks like there would always be a prefix of some sort15:20
dstanekdoes it ever get stripped off?15:21
StefanPaetowJiscFunny you should mention OIDC... someone has brought this up15:21
marekddstanek: what do you mean stripped off?15:21
marekddstanek: the name of the parameters are actually dictated by mod_shib configuration15:22
marekdbut, for clarity they should have some prefix - easier to actually distinguish from rest of the variables from the environment.15:22
dstanekmarekd: the tests all use UserName, LastName, etc. in the assertion data and I'm wondering if in real life it would look more like SAML_USERNAME15:22
marekddstanek: test use random names, and yes in reality that should be more like SAML_IDP, SAML_EMAIL, SAML_USERNAME, SAML_SOMETHING15:23
dstanekmarekd: ok, that's what i thought. the test_utils tests and mapping_fixtures made me thing i was wrong15:24
dstanekmarekd: thanks15:24
stevemardstanek: the apache modules usually have a configurable setting, something like "Assertion prefix", that let you define a header prefix15:24
marekddstanek: yw15:24
marekdstevemar: ++15:24
stevemardstanek: were you asking me a question about https://review.openstack.org/#/c/279908 or looking at it?15:24
dstanekstevemar: fixing the issue. the tests were just throwing me off15:25
*** EinstCrazy has quit IRC15:25
*** slberger has joined #openstack-keystone15:25
*** StefanPaetowJisc has quit IRC15:26
*** StefanPaetowJisc has joined #openstack-keystone15:27
stevemardstanek: \o/15:27
marekdstevemar: sorry, didn't read up enough.15:27
dstanekstevemar: i have no idea how to test this for real though15:28
marekdstevemar: dolph was asking on future plans for native SP code in Keystone.15:28
stevemarmarekd: ah cool15:29
henrynashayoung: ping15:29
stevemardstanek: if we handle the single case described in the bug, i'm happy15:30
henrynashnotmorgan: are you OK with https://review.openstack.org/#/c/264533/28 with the commit fixed?15:30
notmorganhenrynash: my.concern is addressed but I have not reviewed in depth15:31
henrynashnotmorgan: ok, np15:31
*** fawadkhaliq has joined #openstack-keystone15:34
StefanPaetowJiscThanks for the help so far, guys. I'll try to shape this Etherpad into something resembling a spec and will dial in next week if I can. :-)15:34
*** jorge_munoz has joined #openstack-keystone15:34
*** fawadkhaliq has quit IRC15:34
*** fawadkhaliq has joined #openstack-keystone15:35
*** StefanPaetowJisc has quit IRC15:37
ayounghenrynash, I'm here15:38
dstanekstevemar: for the record, i had text/unicode/bytes - ascii ftw15:38
ayoungstevemar, I am saving the Closes tag on Bug: 1545761  for when we finally deprecate and remove it.15:39
openstackbug 1545761 in OpenStack Identity (keystone) "admin_token_auth 'deprecation' actually removes it from the pipelines" [High,In progress] https://launchpad.net/bugs/1545761 - Assigned to Adam Young (ayoung)15:39
*** EinstCrazy has joined #openstack-keystone15:39
ayoungnotmorgan, can you bless https://review.openstack.org/#/c/280467/  and the predecessor?15:39
ayounghttps://review.openstack.org/#/c/280329/815:39
henrynashayoung: sorry, on phone, will be abck soon15:40
stevemarayoung: i suggest not doing that, we will use blueprints to actually remove content (like we did with "removed_as_of_mitaka_15:40
stevemarayoung: also, henry nash found a cool bug with trusts and posted a fix in record timing :O https://review.openstack.org/#/c/280621/115:41
ayoungstevemar, ok, I'll modify the commit message15:41
notmorganayoung: 2 comments - release not15:41
stevemarayoung: thank you15:41
henrynashayoung: was going to ask you views on: https://review.openstack.org/#/c/280621/115:41
notmorganNote* and add comment to the config help to say if it isn't set15:42
notmorganOf the new behavior15:42
notmorganayoung: otherwise lgtm15:42
ayounghenrynash, good question.  I think that, if the role is explicitly part of the trust, executing the trust should fail15:42
ayoungthe idea is that a trust is "what you need to get a job done"15:42
ayoungso if a service user executes a trust, and there is a missing role, it is likely that the job cannot be done15:43
ayoungthat was deliberate15:43
ayoungnotmorgan, ++15:43
ayounghenrynash, make sense?15:43
henrynashayoung: brb15:45
*** pushkaru has joined #openstack-keystone15:51
stevemardstanek: i love your python3 fixes <315:52
dstanekstevemar: i almost have all the tests working :-)15:53
stevemardstanek: the ipv6 ones should be removed when we remove eventlet15:53
stevemarwhich i'm beginning to think is gonna happen in newton...15:53
*** dave-mccowan has quit IRC15:53
dstanekevery time i see newton i think of cookies15:54
dstanekhttp://static.caloriecount.about.com/images/medium/newtons-fruit-chewy-cookies-59696.jpg15:55
*** wanghua has joined #openstack-keystone15:56
*** su_zhang has quit IRC16:00
dstanekstevemar: good call on asking for a better commit message. that is a strange py2 vs. py3 behavior16:00
stevemardstanek: \o/16:01
stevemardstanek: N release reminds me of how cam newton failed me :(16:01
dstanekstevemar: seems he doesn't like to lose16:03
raildostevemar: lol16:03
dstanekstevemar: i was rooting for the roid/perv16:04
dstanek*alleged16:04
stevemardstanek: the guy who won because his defense got all the points for him?16:04
*** tcline has joined #openstack-keystone16:05
dstanekyup, but to be fair points were now easy to come by for either team16:05
*** tcline has quit IRC16:06
henrynashayoung: (back)16:06
henrynashayoung: but that gets murky with implied roles. I.e. so the trustor still has the prior role (that was part of the trust), but one of the implied roles has been removed….should the trustee still get a token (with reduced roles)?16:07
*** timcline has joined #openstack-keystone16:07
*** timcline has quit IRC16:07
*** timcline has joined #openstack-keystone16:09
henrynashayoung: seems to me that a more logical situation is that the trustee gets whatever roles are still valid at teh point they ask for a token…..and if it isn’t enough to do the job, then that’s no different than some removing a regualr role from the user….something they may try and do will fail16:10
ayounghenrynash, implied roles are going to be tightly managed.  THey are admin only.  Yeah, an admin can break things, but more likely they are going to be making things more fine grained16:12
ayoungthe assumption with implied roles is that the two together mean something:  if on is no longer imp;lied by the other, what does that mean?  uits a change of overall system policy16:12
*** dave-mccowan has joined #openstack-keystone16:12
*** su_zhang has joined #openstack-keystone16:13
*** EinstCrazy has quit IRC16:15
*** EinstCrazy has joined #openstack-keystone16:16
henrynashayoung: just seems like we are making assumptions about the meaning (for the admin) of a trust…..16:16
*** clenimar has joined #openstack-keystone16:16
ayounghenrynash, I'd like to leave it for now.  We can make it a topic of discussion at the summit.  I'd like to have a serious session on unfied delegation, and this would be part of it16:16
* stevemar waves at bknudson_16:18
*** pcaruana has quit IRC16:18
* bknudson_ waves back at stevemar16:18
stevemarbknudson_: i need to bug you today about 3 bugs :P16:19
bknudson_stevemar: what are the bugs? and what's the question?16:19
stevemarbknudson_: privileges of being oslo core right?16:19
stevemarbknudson_: bug: https://bugs.launchpad.net/keystone/+bug/151703716:20
openstackLaunchpad bug 1517037 in OpenStack Identity (keystone) "API-based Domain specific config does not check for type of option" [Low,New]16:20
*** EinstCrazy has quit IRC16:20
stevemarbknudson_: the config options for domain specific configs in SQL come in looking like {'some_ldap_config_option': 'some_value'}16:21
henrynashayoung: how come the exception was 'Trustee has no delegated roles.”…kind of implied that it only be raised if none of the roles was valid anymore16:21
*** mvk has quit IRC16:21
stevemarbknudson_: how easy is it to look up 'some_ldap_config_option' in CONF.ldap..., and check what it's "type" is (boolean/string/port....) and evaluate the new option?16:22
bknudson_stevemar: there's probably a way to get the option type and try to convert it.16:22
bknudson_this must happen during config parsing already16:22
stevemarbknudson_: i looked through olso.config and couldn't could only half-way do it using private classes16:22
bknudson_stevemar: you should be Opt.type(option_value)16:23
*** diazjf has joined #openstack-keystone16:23
bknudson_http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n64416:23
*** su_zhang has quit IRC16:24
stevemarbknudson_: want to dish this one out to tjcocozz?16:24
bknudson_so CONF.ldap.whatever.type(whatever)16:24
bknudson_stevemar: I want to dish all sorts of stuff to tjcocozz but I know he's busy with other stuff.16:24
*** su_zhang has joined #openstack-keystone16:25
stevemarbknudson_: hmm.. CONF.ldap.url.type should give StringOpt?16:25
*** su_zhang has quit IRC16:25
henrynashayoung: the reason I’m looking at all this, is that it mucks up domain roles16:27
ayounghenrynash, trusts?16:27
bknudson_stevemar: if you don't pass a type to the constructor then it's types.String16:27
ayounghenrynash, how?16:27
bknudson_stevemar: types.String is http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/types.py#n6216:27
bknudson_types.String does all sorts of validation -- see http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/types.py#n12416:28
stevemarbknudson_: i know the types.Whatever do validation there, just wasn't sure about how they link up together16:28
*** bdossant has quit IRC16:29
henrynashayoung: just a matter of code….but on create token, we ge the roles the trustor has now (which strips OUT the domain role).. so if the trust wwas for the domain role, the check throws out the trust since the roles don’t “match”16:29
stevemarbknudson_: okay, i'll try it out in a minute, one more question16:29
ayounghenrynash, hmmm.16:29
bknudson_I assume CONF.ldap.url is a StringOpt and CONF.ldap.url.type is types.String16:29
ayounghenrynash, ok, ignore everything else and answer this:  should it be possible to make a trust on just a domain role?16:30
stevemarbknudson_: was poking around with setting up bluepages and ldap last night and ran into this bug: https://bugs.launchpad.net/keystone/+bug/154596016:30
openstackLaunchpad bug 1545960 in OpenStack Identity (keystone) "authenticating with ldap user fails due to notification" [High,In progress] - Assigned to Steve Martinelli (stevemar)16:30
ayoungI think that it should16:30
ayoungso the real issue is that the way that we list roles for a user should not strip the domain role until the trust compares the two16:30
*** agireud has quit IRC16:31
dstanekstevemar: marekd: what is the term for what mod_shib actually is? it's not an IdP, but what is it?16:31
stevemardstanek: it's an apache module?16:31
ayoungits not a question of the user not having the role, but of us stripping it out before the check.16:31
dstanekstevemar: i was hoping that there was a generic term for it16:31
dstanekmaybe there's not16:31
ayoungSo,  leave the assignment logic as is.  Make sure the trust roles are all valid, then strip domain specific16:32
stevemardstanek: i've always described it as: it performs the handshake between the user and the identity provider, so we don't have to.16:32
henrynashayoung: I also think you should….16:32
*** agireud has joined #openstack-keystone16:32
stevemarbknudson_: i tossed up https://review.openstack.org/#/c/280542/ -- but if you look at the comment, theres already a test for this16:33
henrynashayoung: agreed…I already had to do this to make trust creation work,16:33
dstanekstevemar: i'm going to call it a 'web server plugin'16:33
stevemardstanek: ++16:33
*** boris-42 has quit IRC16:34
henrynashayoung: please comment on my “fix for the bug” with our views, then I’ll abandon, and we can bring it back in the future if we want16:34
ayounghenrynash, just do not do the additional logic of allowing a token with a subset of roles from the trust.  THat would be a mistake, I think16:34
bknudson_stevemar: which comment?16:34
ayounghenrynash, will do16:34
stevemarbknudson_: "not sure what's going on here, since it looks like this should have been covered by this test: https://github.com/openstack/keystone/blob/master/keystone/tests/unit/common/test_utils.py#L45-L46"16:34
bknudson_stevemar: what was the string that couldn't be converted?16:35
stevemarbknudson_: that's in comment #2 in the bug16:36
stevemarbknudson_: "2165702f085e15ff59308d8723df016d75fdd07e9af527a881b87812278e5068"16:36
openstackgerritPandiyan proposed openstack/keystone: Add driver details in architecture doc  https://review.openstack.org/28080216:36
bknudson_stevemar: the exception is saying that the value was chr(0xec)16:36
stevemarbknudson_: "Found existing mapping to public ID: 2165702f085e15ff59308d8723df016d75fdd07e9af527a881b87812278e5068"16:36
openstackgerritBoris Bobrov proposed openstack/keystone: Use the right driver to get limits  https://review.openstack.org/26698916:37
openstackgerritBoris Bobrov proposed openstack/keystone: Fallback to list_limit from default config  https://review.openstack.org/28080416:37
bknudson_stevemar: 'ascii' codec can't decode byte 0xec in position 2: ordinal not in range(128)16:37
*** rcernin has quit IRC16:37
stevemarbknudson_: maybe it's getting mucked up when it's retrieved from the database?16:39
openstackgerritDavid Stanek proposed openstack/keystone: WIP handle unicode names for federated users  https://review.openstack.org/27990816:39
dstanekstevemar: ^ that's what i came up with16:39
stevemardstanek: looking now16:40
dstanekbe back in 30. going to shovel the driveway16:41
htrutahenrynash: addressed your changes in https://review.openstack.org/#/c/207218/ looks like it's ready to +A16:41
henrynashhtruta: done!16:44
htrutahenrynash: you rock!16:45
ayoungdstanek, henrynash can one of you move https://review.openstack.org/#/c/280329/  on, and I will work on getting the follow on patch to address  notmorgan 's feedback16:45
htrutahenrynash: I was thinking here... is there a place for is_domain in the token still in M ? The patches are pretty simple, but they depend on the projects acting as domains16:45
henrynashhtruta: we’re trying to get projects acting as a domain in for M still!16:46
openstackgerritayoung proposed openstack/keystone: Re-enable and undeprecate admin_token_auth  https://review.openstack.org/28032916:46
*** dmsimard has joined #openstack-keystone16:47
openstackgerritayoung proposed openstack/keystone: Disable Admin tokens set to None  https://review.openstack.org/28046716:47
dmsimardHi #openstack-keystone. Could we get the necessary +2/+A on https://review.openstack.org/#/c/280329/ ? Thanks.16:47
htrutahenrynash: I see... that's why I think I'd make sense to have the "is_domain" in the token before that, even though we don't use it in the policy16:48
htrutas/I'd/it'd16:48
openstackgerritAlexander Makarov proposed openstack/keystone: Enable support for posixGroups in LDAP  https://review.openstack.org/25852816:51
henrynashhtruta: if we can make teh patch independant, then why noy16:51
henrynashnot16:51
htrutahenrynash: we can. We just need to rebase it to master, instead of basing it into the projects acting as domains.16:52
htrutahenrynash: we are now able to create projects with is_domain=True (although they don't act like that in fact), so the changes in the token can be tested16:53
henrynashhtruta: ok, let’s do it16:55
*** subscope has quit IRC16:56
*** rderose has joined #openstack-keystone17:01
openstackgerrithenry-nash proposed openstack/keystone: Modify rules in the v3 policy sample for domain specifc roles  https://review.openstack.org/26207817:01
dmsimardstevemar: thanks <317:02
*** e0ne has quit IRC17:04
openstackgerritPandiyan proposed openstack/keystone: Add driver details in architecture doc  https://review.openstack.org/28080217:05
*** gyee has joined #openstack-keystone17:05
*** ChanServ sets mode: +v gyee17:05
arunkantstevemar: Can you look into this review..https://review.openstack.org/#/c/279828/17:05
*** dan_nguyen has joined #openstack-keystone17:07
stevemarnkinder & ayoung: can you take a quick look at: https://review.openstack.org/#/c/258528/17:09
*** aginwala has joined #openstack-keystone17:09
*** rcernin has joined #openstack-keystone17:09
stevemararunkant: i'll add dims too, it'll be good to get oslo ptl eyes on it17:09
arunkantstevemar: okay. thanks.17:10
*** d0ugal has quit IRC17:11
*** mylu has joined #openstack-keystone17:13
ayoungstevemar, so, the only objection i have is that this has nothing to do with posix17:13
stevemaramakarov ^17:14
ayoungI need to think about the right term, but it is something more like "attribute"17:14
stevemarayoung: explains17:14
ayoungamakarov, posix groups are something different17:14
*** gordc has quit IRC17:14
ayoungits a field on a group whether to treat the group as a posix group or not, not how the users are stored17:14
ayoungthat being said, the logic of the patch is good.17:15
ayoungstevemar, would like to have some of our more LDAP savvy people look at it, though.17:15
*** roxanaghe has joined #openstack-keystone17:15
amakarovayoung, tbh, I've just goolge'd it: https://www.rainingpackets.com/ldap-posixgroup-groupofnames/17:15
ayoungamakarov, yeah...that is the object class...17:16
ayoungand, I know we do the same kind of thing in IPA17:16
ayoungwhich leads me to wonder if we need to be able to mix the two together.17:17
*** mylu has quit IRC17:18
gyeestevemar, is totp a go or no-go, I am planning on working on keystoneauth1 today. But if it's a no-go, I need to reprioritize17:18
stevemargyee: i'm still waiting on docs and tests for the server side17:19
gyeestevemar, lemme help out on the server side first17:19
gyeeshould have a patch sometime today17:19
amakarovayoung, any suggestion?17:19
stevemargyee: alrighty17:19
stevemargyee: also, bknudson_ had issues with that patch :(17:19
stevemargyee: the url fix patch17:20
gyeestevemar, yeah, working on it as well17:20
ayoungamakarov, I'mn tempted to leave this patch as is.  I think it is OK17:20
amakarovayoung, ack17:20
*** su_zhang has joined #openstack-keystone17:21
ayoungamakarov, I actually am not that smart about LDAP stuff.17:21
amakarovayoung, me neither :)17:21
gyeestevemar, I should've known don't start celebrating till bknudson_ sings :)17:21
*** lhcheng has joined #openstack-keystone17:21
*** ChanServ sets mode: +v lhcheng17:21
ayoungstevemar, I'm willing to +2.  If you up yours to 2, I'll +A17:22
gyeeayoung, that posix patch works, I tested it locally as well17:23
stevemarayoung: i'd feel better if you get nkinder to take a look too :P17:24
stevemarayoung: or gyee can vouch for it :P17:24
gyeeonly thing it won't do is walk the nested groups17:24
*** jbell8 has joined #openstack-keystone17:24
gyeewe don't support nested groups anyway17:24
nkinderstevemar: I have it open.  Just waiting for a meeting to end so I can give it some attention.17:24
stevemarnkinder: you're the best!17:24
*** su_zhang has quit IRC17:26
*** su_zhang has joined #openstack-keystone17:26
*** su_zhang has quit IRC17:27
*** su_zhang has joined #openstack-keystone17:29
*** tqtran has joined #openstack-keystone17:30
*** phalmos has joined #openstack-keystone17:30
*** mylu has joined #openstack-keystone17:31
*** aginwala has quit IRC17:34
*** petertr7 is now known as petertr7_away17:34
*** dims has joined #openstack-keystone17:34
notmorganayoung: hmm17:35
*** _cjones_ has joined #openstack-keystone17:35
*** aginwala has joined #openstack-keystone17:36
*** spandhe has joined #openstack-keystone17:37
*** d0ugal has joined #openstack-keystone17:38
dstaneksigmavirus24: thoughts on https://review.openstack.org/#/c/279908 ? specifically header encoding....17:40
*** roxanaghe has quit IRC17:42
openstackgerritJorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects.  https://review.openstack.org/25327317:43
sigmavirus24dstanek: looking17:43
sigmavirus24dstanek: the comment that stevemar made is probably inspired by my recent mailing list post about swift being silly with their headers17:44
dstaneksigmavirus24: what comment?17:44
sigmavirus24in federation/utils.py17:45
dstaneksigmavirus24: ah, yeah. that was me. i didn't see your post, but maybe i should go look for it17:45
sigmavirus24dstanek: it was a reply to Victor's emails about Py3 support in swift17:46
sigmavirus24(from last week)17:46
sigmavirus24But yeah, I'm not sure any service in OpenStack actually *cares* about the HTTP RFCs because they all violate them in numerous ways (sometimes forcibly)17:46
sigmavirus24So take my concerns with a grain of salt. Also, what framework does keystone use? Straight wsgi? Webob? something else?17:47
dstaneksigmavirus24: i care! i you have a list of what keystone screws up i'd love to hear it17:47
sigmavirus24Because webob would be a good place for this, but I think always decoding a bytes object to ISO-8859-1 will cause more headaches17:47
sigmavirus24dstanek: I stopped looking after I went through glance and swift. I can dig through keystone though17:47
sigmavirus24(Just not anytime soon)17:47
*** e0ne has joined #openstack-keystone17:47
sigmavirus24dstanek: one thing most services don't do correctly is implement JSON Patch completely and so those implementations are *always* broken17:48
sigmavirus24(Regardless of the fact that there are appropriately licensed libraries for handling that)17:48
dstaneksigmavirus24: i'm in no rush as there is lots of other stuff i need to get done :-) thanks!17:49
sigmavirus24dstanek: requests plans to stop unconditionally decoding headers to ISO-8859-1 when we can17:50
stevemarapparently nothing on the agenda today17:50
notmorganstevemar: no meeting then!17:51
notmorgan:P17:51
sigmavirus24Because so many servers return data that is not encodeable to latin-1, you'll get confusing data from the headers17:51
sigmavirus24(That said, on Python 3 we have to fight httplib because httplib/http.client unconditionally does that encoding for us -_-)17:51
notmorgansigmavirus24: i hope that is going to be optional. /me is a fan of being really clear when that breaks.17:52
sigmavirus24notmorgan: you mean not unconditionally decoding headers?17:52
notmorgansigmavirus24: basically allow for unconditional decoding behavior to continue17:52
sigmavirus24If the team continues to agree that this is the best way forward, it'll happen in 3.0.0, but I don't think we'll have anyway to turn it back on because the only encoding we handle is when the user uses `r.text` and I could also be misremembering the discussion we had17:53
notmorgani'm a little disappointed by this. then again i approve that requests is opinionated. just means i might need to use urllib directly instead for my things.17:54
*** petertr7_away is now known as petertr717:54
*** phalmos has quit IRC17:54
* notmorgan wishes openstack could be a little more opinionated17:54
notmorgannot as much as requests but.. still closer.17:55
*** browne has joined #openstack-keystone17:56
dstaneksigmavirus24: that's sort of why i only decode the federation headers. i'm leaving everything else alone17:57
sigmavirus24dstanek: fair17:57
topolstevemar, no meeting today?17:58
sigmavirus24notmorgan: again, I could be thinking of a different issue, but I think what we do now is a bit harder on people who need the headers encoded in a different way since forcibly encoding the bytes causes data loss17:58
notmorgansigmavirus24: sure17:58
stevemartopol: still gonna have one17:58
notmorgansigmavirus24: thats why i said "maybe" :)17:58
stevemartopol: short one17:58
topolstevemar I thought Raleigh being snowed in was impacting you as well17:59
sigmavirus24notmorgan: we might be able to convince urllib3 to do this and then the "requests" way to access the original headers as bytes would be via the stored urllib3 response17:59
* sigmavirus24 shrugs17:59
topolstevemar a vicious dusting. Chick-Filet closed early last night17:59
*** tsymanczyk has joined #openstack-keystone18:00
samueldmqstevemar: hey, no meeting today?18:00
stevemarkeystone meeting reminder ping: ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC, tjcocozz, jorge_munoz18:00
samueldmqoops18:00
*** vgridnev has joined #openstack-keystone18:04
*** subscope has joined #openstack-keystone18:07
*** spzala has quit IRC18:07
*** spzala has joined #openstack-keystone18:08
*** spzala has quit IRC18:12
*** phalmos has joined #openstack-keystone18:13
openstackgerritHenrique Truta proposed openstack/keystone: Sub projects acting as domains  https://review.openstack.org/23554418:14
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf: Updated from global requirements  https://review.openstack.org/28086418:17
*** spzala has joined #openstack-keystone18:22
*** spandhe has quit IRC18:23
*** mylu has quit IRC18:24
*** spandhe has joined #openstack-keystone18:26
*** david-lyle has quit IRC18:27
*** jasonsb_ has quit IRC18:28
*** d0ugal has quit IRC18:28
*** d0ugal has joined #openstack-keystone18:29
openstackgerrithenry-nash proposed openstack/keystone: Modify implied roles to honor domain specific roles  https://review.openstack.org/26306418:29
openstackgerrithenry-nash proposed openstack/keystone: Modify rules for domain specific role assignments  https://review.openstack.org/26354918:30
*** e0ne has quit IRC18:33
bretondolphm: right now for mapping api there is 1 query to database per user18:34
*** ebalduf has joined #openstack-keystone18:34
bretondolphm: 1000 users in ldap -> 1000 queries to database18:34
dolphmbreton: are you seeing 1,000 queries being made to handle a single API request?18:35
*** david-lyle has joined #openstack-keystone18:35
bretondolphm: I have not checked yet, but it looks like it from the code. identity.core:_set_domain_id_and_mapping, see the part inside `elif isinstance(ref, list):`18:39
dolphmbreton: link? i'm not sure i understand your concern18:40
bretondolphm: https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L582, it calls https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L60418:42
bretondolphm: _set_domain_id_and_mapping is called to the result of list_users: https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L86518:44
*** petertr7 is now known as petertr7_away18:44
dolphmbreton: is there a MEMOIZE decorator on the lookup?18:45
bretondolphm: I don't know. Still not an option at all, because the API request fails18:46
bretondolphm: because without cache it takes more than timeout to complete18:47
bretondolphm: that's something I'm going to tackle in this and next release18:47
dolphmbreton: if all it's missing is a caching decorator, that's an easy backport as well18:48
bretondolphm: or will join rderose to ensure that this problem is gone with shadow users18:48
dolphmbreton: both!18:48
bretoncaching decorator is not an option. Cache expiration is too expensive.18:48
*** roxanaghe has joined #openstack-keystone18:48
bretonit's not 10, 15 or 20 seconds for cache miss. 300 might be not enough for large amount of users.18:49
*** roxanaghe has quit IRC18:51
*** spandhe has quit IRC18:51
dolphmbreton: can you explain what you mean by "cache expiration is too expensive"? ... and 300 what, seconds?18:51
bretondolphm: on cache miss it takes 300 seconds to fetch 10k ldap users.18:52
dolphmbreton: okay18:54
*** eandersson has quit IRC18:55
*** spandhe has joined #openstack-keystone18:56
dolphmrderose: stevemar: dstanek: shadow users?18:59
dstanekdolphm: ?18:59
dolphmdstanek: #topic18:59
lbragstadayoung some of the fernet default work hangs on this -= https://review.openstack.org/#/c/278802/19:00
*** jbell8 has quit IRC19:00
henrynashsamueldmq: could you see if you are OK with https://review.openstack.org/#/c/262078/21 now?19:00
rderoseI'm here, but need 10 min19:00
dstanekbreton: fetching that many users from ldap is just bad design19:00
lbragstadayoung and that is passing except one test - I'd like to get your feedback on it19:00
dstanekdolphm: shore19:00
ayounglbragstad, what is failing?19:00
samueldmqhenrynash: oh sure, domain specific roles, 3 patches and bp implemented ?19:00
henrynashayoung: I fixed up the doman roles with trusts….see if you are Ok with it….https://review.openstack.org/#/c/263064/1919:00
henrynashsamueldmq: yep19:01
rderosedolphm: be right back19:01
ayoungtest_delete_tokens_for_user_invalidates_tokens_from_trust19:01
rderosedolphm: are you in a room?19:01
dolphmrderose: bookstore19:01
lbragstadayoung the test makes an assertion around the fact tokens are stored somewhere - http://logs.openstack.org/02/278802/1/check/gate-keystone-python27/875f2ca/testr_results.html.gz19:01
lbragstadayoung so it coded to assume UUID19:01
dolphmrderose: in a booth19:01
bretondstanek: I agree. And is pointless in fact.19:01
stevemardolphm: can you wait 20 minutes for me to get food?19:01
* ayoung going to have to open an Etherpad just to track conversations...19:01
dolphmstevemar: maybe19:01
ayounglbragstad, OK  let me thing...19:01
henrynashayoung: of split brains19:01
ayoungthink19:01
dolphmstevemar: make it 1019:01
stevemardolphm: rather, do you mind if i quickly get food, no need to wait for me19:01
dolphmstevemar: =)19:01
stevemardolphm: if you're doing a hangout gmail chat me the link19:02
ayounglbragstad, what is supposed to trigger that?19:03
dolphmdstanek: rderose: we can do a hangout if y'all prefer ^19:03
ayoungdelete_tokens_for_user19:03
ayoungself.token_provider_api._persistence.delete_tokens_for_user(19:04
ayoung            self.trustee['id'])19:04
samueldmqhenrynash: my idea was to use this order : http://paste.openstack.org/show/487161/19:04
samueldmqhenrynash: check if it makes sense19:04
ayoungthat was a provider call.  lbragstad does anything in the outside world call .delete_tokens_for_user19:04
ayounglets see...19:04
dstanekdolphm: rderose: doens't matter. i'm just making some tea now and then i can talk about whatever19:05
samueldmqhenrynash: rules only use other rules that are above, not any that is below itself19:05
lbragstadayoung https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_auth.py#L113619:05
*** mhickey has quit IRC19:05
henrynashsamueldmq: although I had othre reviews say they wanted it exaclt the otehr way round…and wanted to see them used first, and then follow the chain19:05
dolphmnow i feel obligated to go get caffeine too19:05
dolphmbe back in 5ish19:05
ayounglbragstad, that test should only be run on a persisted backend.  With revocation events, it should be a revoke_by_user_id call19:06
ayounglbragstad, so..let's see waht actaully is failing./...19:06
ayoung   testtools.matchers._impl.MismatchError: 1 != 019:07
samueldmqhenrynash: okay that shouldn't block the patch anyway19:07
lbragstadayoung it fails this assertion https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_auth.py#L113519:08
lbragstadayoung because this isn't a token - we're using fernet19:08
ayounglbragstad, the test needs to pass, I think, if we keep the API around.  But is list tokens even a valid api with the Fernet tokens?19:08
ayoungit seems like these APIs should be no-oped19:08
lbragstadayoung so the assertion is coded to assume that there is always going to be a token written to the backned19:08
ayounglist tokens for user should return 0 for Fernet19:09
ayoungno?19:09
lbragstadayoung right19:09
henrynashsamueldmq: ok19:09
notmorganooooh update your glibc https://googleonlinesecurity.blogspot.ca/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html19:10
lbragstadayoung  I don't think that API makes sense for Fernet19:10
notmorganlbragstad: list tokens is invalid for fernet19:11
notmorganayoung: ^ cc19:11
*** mylu has joined #openstack-keystone19:11
notmorganthe correct response is afaict w/o breaking the API spec, returning a []19:11
dstanekdolphm: back19:11
notmorganin fact, list_tokens should, i hope, never leak out to the actual REST api, if id did, we did something horribly wrong19:12
notmorganbut with fernet, there is no way to list the tokens, therefore, there is nothing to do if you require a list of all tokens.19:12
ayounglbragstad, talk with henrynash about what we need to do to deal with stable driver interface, but the option there might be just to no-op those calls for Fernet.  Just make sure the revocation events get triggered for them19:13
*** daemontool has joined #openstack-keystone19:14
*** vgridnev has quit IRC19:14
samueldmqhenrynash: in https://review.openstack.org/#/c/262078/21/doc/source/policy_mapping.rst19:14
samueldmqhenrynash: I think adding "where role.domain_id is not null" makes it ahrd to read, and is different from the patter being used19:14
samueldmqhenrynash: anyone asked for it ?19:14
lbragstadayoung in that case - a revocation event should be triggered when a trust is deleted, right?19:15
henrynashsamuedlmq: well we have to have an entry for each policy line…and wanted to distinquish from teh gloabl lines above..any suggestions19:16
lbragstadayoung i'm not seeing the revoke_api used in the trust API at all.19:16
samueldmqhenrynash: maybe a comment before that block ?19:16
*** daemontool_ has joined #openstack-keystone19:16
samueldmqhenrynash: APIs for domain roles below require role.domain_id is not None19:17
samueldmqhenrynash: rather than putting in every API entry ?19:17
henrynashsamueldmq: could try that…ok, thx19:17
samueldmqhenrynash: I may also leave a comment (it's nit) that can be fixed later ?19:17
henrynashsamueldmq: let’s get it in if we can, I’l happily fix that later19:18
samueldmqhenrynash: ++19:18
dolphmdstanek: lbragstad: rderose: stevemar: i'm back - digging into https://review.openstack.org/#/c/278570/ first19:19
*** daemontool has quit IRC19:19
*** mylu has quit IRC19:20
*** mylu has joined #openstack-keystone19:21
dstanekdolphm: what is happening in the 089 migration? that is totally different19:23
dolphmdstanek: L4619:24
dolphmdstanek: it's repurposing the table19:24
dstanekdolphm: but why bother renaming?19:24
dolphmdstanek: no data to migrate?19:24
dolphmto a new table19:24
openstackgerritMerged openstack/keystone: Restricting domain_id update  https://review.openstack.org/20721819:24
dstanekbut if you don't rename then you don't do all those other destructive things19:25
dolphmdstanek: like constraints?19:25
dstanekyes19:25
dolphmdstanek: so drop L31-38, L48-54?19:26
ayounglbragstad, trying to think this through....yeah, if a trust is deleted , there should be a revocation event.  If that is not happening now, it needs to be done.  Add a bug for that, but shouildn't hold up this19:26
ayounglbragstad, beyond that,  make sure list tokens for user always returns 0 for fernet.  The fact that it is not in that test is bothering me19:27
stevemardolphm: dstanek back19:27
dstanekdolphm: tbh, i think i have to go over this again it's all completely different :-(19:27
*** rderose has quit IRC19:29
*** rderose has joined #openstack-keystone19:29
stevemardstanek: what's so destructive about it?19:29
dstanekactually it literally is... did rderose submit a brand new change id?19:29
stevemardstanek: yes19:29
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28089619:30
dolphmo, boo19:30
stevemardolphm: dstanek yeah, abandoned old one, probably for the usual reasons :P19:30
dstanekstevemar: well, it seems much harder than it need to be and it appears that the only reason to do that is to reuse the 'user' name for a new table19:31
* stevemar continues to scarf down a banh mi19:31
dstaneki actually don't like the identity - user - password breakdown19:31
notmorganstevemar: just had bacon here. Sadly, peppered bacon < maple bacon < normal bacon19:31
lbragstadayoung agreed - let me open a bug19:31
ayoungjamielennox, you still awake?  I need guidance on how to make the implied roles Client API not be stupid19:32
stevemardstanek: we could have "user" be the OTTRTA (one table to rule them all), and create a new one "sql/local" for the others?19:32
dolphmdstanek: the 3 tables was necessary to avoid duplicate users19:32
dstanekdolphm: i don't mind the 3 but i don't like the 3 picked19:32
lbragstadayoung actually - what's the case we're working for here?19:32
dolphmdstanek: ?19:32
lbragstadayoung a trust is create, a user gets a trust-scoped token, the trust is deleted, and the token is no longer valid?19:33
lbragstadcreated*19:33
dstanekfor example, instead of 'user' is't really more like 'profile' (or something else since i suck at naming) because it's the same user. user and identity to me are the same19:33
*** su_zhang has quit IRC19:33
*** roxanaghe has joined #openstack-keystone19:34
lbragstadayoung we protect against that here - https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L733-L73419:34
dolphmdstanek: stevemar: rderose: this seems like it would be easier with voice - someone start a hangout or something?19:34
dstanekdolphm: stevemar: i may need to read the rest of this patch to see what's happening19:35
dolphmdstanek: yeah, i figure we can talk through it and review together, with Ron available to answer questions, etc19:35
lbragstadayoung so the trust is validated online when we validate the token19:35
dolphmremote midcycle reviewing19:35
ayounglbragstad, if a trust is deleted, there will be no need to look fro a revocation event.19:36
ayoungbut that is new logic19:36
*** roxanaghe has quit IRC19:36
ayoungit was not that way when I orangutan lee wrote it19:37
ayoungOK, I cheated, that was not really an autocorrect error.19:37
lbragstadayoung is that case what we are trying to use revocation events + trusts for though?19:37
lbragstadif a trust is deleted, a user shouldn't be able to use their trust-scoped fernet token anymore19:37
ayounglbragstad, right.  And with jorge_munoz 's work, we'll get that check done during validation if it is not done alreauyd19:38
ayounglbragstad, look through his patches, please19:39
ayoungbetter if you can review them as well.19:39
dolphmdstanek: stevemar: rderose: https://hangouts.google.com/call/bsrs4bla7rx6tryxtx2qozaprua19:39
lbragstadayoung we already check that we fernet when we validate a token19:39
*** rderose has quit IRC19:39
lbragstadwith fernet*19:39
ayoungright...so, do you have everything you need?19:39
lbragstadayoung I think so - but I wanted to double check that is the case we were solving for19:40
lbragstadayoung so I won't open a bug19:40
*** mylu has quit IRC19:40
*** rderose has joined #openstack-keystone19:40
ayoungYeah, we should be good19:40
*** petertr7_away is now known as petertr719:41
dolphmstevemar: are we still pursuing minimal downtime at all for mitaka?19:42
*** roxanaghe has joined #openstack-keystone19:42
*** mylu has joined #openstack-keystone19:43
ayounghenrynash, ok, I know we were talking about something I had been reviewing...19:46
ayounglet me pop it off the stack19:46
dolphmlbragstad: (on shadow users) do you expect the same migration to ever be run more than once?)19:47
lbragstadayoung thanks19:48
lbragstaddolphm I don't *think* so?19:48
samueldmqhenrynash: approved, will look at the others later today19:48
lbragstaddolphm rderose protects against that case I believe by checking the existence of the table19:48
dolphmlbragstad: makes sense in a dev environment, but we don't need to do that in the final release19:49
dolphmlbragstad: extra behavior / complexity risks introducing bugs19:49
lbragstaddolphm makes sense19:49
lbragstaddolphm OSA never runs into a case where they run a migration twice do they?19:49
dolphmlbragstad: no one should19:49
ayounghenrynash, so in https://review.openstack.org/#/c/263064/19/keystone/token/providers/common.py  I think that maybe the logic should not be in the token controller for expanding out the roles.19:50
dolphmthey're just not designed to19:50
ayounghenrynash, I know I had it there, too19:50
stevemardolphm: no, bumped that to N19:50
lbragstaddolphm makes sense19:50
lbragstaddolphm in that case - make it simple as possible :)19:50
dolphmlbragstad: "if you need to run a migration again, you restore from a database back first" - rderose19:50
dolphmlbragstad: ++19:50
lbragstaddolphm rderose completely agree19:50
*** petertr7 is now known as petertr7_away19:51
dstanekdolphm: ok, did a quick pass without executing the code19:51
dstanekso as a cloud customer i have a single identity and multiple users?19:52
dstanekthat seems backward. i have a single user(profile) that i can access through multiple identities19:53
dstanekdolphm: stevemar: ^19:53
*** mylu has quit IRC19:53
dolphmdstanek: stevemar: i made a hangout if you want to join19:53
dstaneksure19:54
dolphmdstanek: stevemar: https://talkgadget.google.com/hangouts/_/bsrs4bla7rx6tryxtx2qozaprua?authuser=0&hl=en19:54
stevemardolphm: yes please19:54
openstackgerritayoung proposed openstack/keystone: Disable Admin tokens set to None  https://review.openstack.org/28046719:54
henrynashsamueldmq: thx19:56
*** spandhe has quit IRC19:59
openstackgerritayoung proposed openstack/keystone: Disable Admin tokens set to None  https://review.openstack.org/28046720:00
notmorganayoung: lgtm20:01
*** e0ne has joined #openstack-keystone20:02
*** spandhe has joined #openstack-keystone20:03
*** petertr7_away is now known as petertr720:04
dolphmintegrated with what20:05
*** e0ne has quit IRC20:05
*** aginwala has quit IRC20:05
*** aginwala has joined #openstack-keystone20:08
*** jaosorior has quit IRC20:09
ayoungedmondsw, I'm stuck on how to do the keystoneclient part of implied roles and I blame you20:14
*** arunkant has quit IRC20:14
edmondswayoung, do you have a reason? ;)20:14
ayoungif it was a separate object, including the resource name, It would be simple, but NOOOO~! you had to go all RESTFUL on me20:14
edmondswha20:14
ayoungedmondsw, actually, I just needed an excuise to talk it over with someone20:15
ayoungand jamielennox is asleep20:15
edmondswi wasn't your first choice? I'm hurt now... I think...20:15
ayoungso...here is the role.py file starting point: http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/v3/roles.py20:15
ayoungedmondsw, you should not be20:15
edmondswlol20:15
*** sdake_ has joined #openstack-keystone20:15
ayoungeveryone knows that jamielennox is the king of all things client20:15
edmondswtru dat20:16
ayoungSo...the thing that is wonky here is that the clinet kindof has this pattern where you have a resource and all of the methods mnatch the HTTP methods20:16
ayoungfor example20:16
ayounghttp://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/v3/roles.py#n88  is GET20:16
ayoungfor implied roles, we need to do things around these methods.20:17
ayoungNot sure if it should be a separate python method or not,20:17
*** sdake has quit IRC20:17
edmondswnot all of them line up with HTTP methods... e.g. http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/v3/roles.py#n13520:17
*** arunkant has joined #openstack-keystone20:17
ayounghttp://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3/identity-api-v3.rst#n5155  is the create.20:18
ayoungright...grant is a create for the role assignments.20:18
ayoungedmondsw, this needs to flow down to the CLI, too, which is in a separate project...20:18
*** david-lyle has quit IRC20:18
ayoungso if there are mechanisms that automate the mapping from CLI params to calls I want to honor them20:19
*** ebalduf has quit IRC20:19
ayoungopenstack help role  gives20:19
ayoung  role add   role create   role delete  role list  role remove  role show20:19
ayoungand then ^^ is kindof hidden20:19
ayoungit would be20:19
ayoung role add  vs role create20:20
ayoungso...lets start at this end20:20
ayoungwould it be role imply?20:20
ayoungdon;t want to confuse things with add20:21
edmondswyou're trying to tie two roles together, saying role x implies role y?20:22
edmondswI would think that should be "role update"20:22
edmondswthis was one of my original comments... that the way you create an implied role shouldn't be PUT /roles/{id}/implies/{id}, it should be PUT /roles/{id}20:23
ayoungtrue...we don't have a nupdate20:23
edmondswthe role implications should be data represented on the role... drop that "implies" json block into a PUT /roles/{id} along with anything else you want to update about the role (e.g. could change its name at the same time if you wanted)20:25
ayoungexcpet that roles were supposed to be immutable20:26
edmondswwhy?20:26
ayoungthis is an association between two roles20:26
edmondswlinks are put into entities all the time20:26
ayoungwhy immutable?20:26
edmondswyeah20:26
ayounga role is little more than a string. Having the role Id in there was always strange20:27
edmondswwe could say some characteristics of roles are immutable, without saying they all are20:27
ayoungedmondsw, you don't think like a relational database person, do you?20:28
edmondswayoung you don't think like a REST guy, do you?20:28
ayoungedmondsw, I guess not20:28
edmondswbefore I did security, I was the API lead for our product20:28
ayoungedmondsw, its the whole hierarchical versus relational argument all over again20:29
edmondswit takes some getting used to20:29
ayoungyou want to be able to vary the relationships separate from the objects they relate.  Favor immutable is actually more a programming construct, although the "never erase anything from the database" approach also falls in there20:30
ayoungthe reason what you suggest works here is because inference rules form a DAG, which works well in a hierarchical scheme such as REST20:31
*** sdake_ has quit IRC20:32
edmondswI gave you that option as well in my comments on patch 61: https://review.openstack.org/#/c/242614/61/keystone/assignment/routers.py20:32
edmondswPOST /role_inferences20:32
*** sdake has joined #openstack-keystone20:32
ayoungedmondsw, yeah, I was more prone to go with that...forget now who talked me out of it...20:32
ayoungedmondsw, so what you are saying is that I have only myself to Blame?20:33
*** mylu has joined #openstack-keystone20:33
edmondswweelll... you said it... ;)20:33
ayoungOK...I'm going to go with a new verb, and we can argue it out in the review20:34
edmondswbtw, you'd love the conversation on policy going on in #openstack-nova20:36
edmondswayoung ^20:36
*** spzala has quit IRC20:36
*** ebalduf has joined #openstack-keystone20:38
*** trevorjay has quit IRC20:40
*** mylu has quit IRC20:41
*** subscope has quit IRC20:42
openstackgerritguang-yee proposed openstack/keystone: wsgi: fix base_url finding  https://review.openstack.org/22646420:44
dolphmstevemar: https://review.openstack.org/#/c/278570/14/keystone/common/sql/migrate_repo/versions/089_rename_user_table_to_identity_table.py,unified L4320:45
*** aginwala has quit IRC20:46
*** aginwala has joined #openstack-keystone20:49
dolphmstevemar: dstanek: https://etherpad.openstack.org/p/keystone-shadow-users20:49
*** gyee has quit IRC20:54
*** clenimar has quit IRC20:55
*** gordc has joined #openstack-keystone20:55
*** jsavak has joined #openstack-keystone20:58
*** spandhe has quit IRC21:00
*** raildo is now known as raildo-afk21:01
*** spandhe has joined #openstack-keystone21:04
*** jbell8 has joined #openstack-keystone21:05
*** jorge_munoz has quit IRC21:07
*** mhickey has joined #openstack-keystone21:10
henrynashayoung: sorry to bug you on this one, but could you take a look at https://review.openstack.org/#/c/263064/ to see if you are OK with how I am handling trusts21:10
ayounghenrynash, bug away.21:10
ayounghenrynash, so...I kindof feel my code that is based on was a bit of a hack21:11
ayoungdidn't think it would go through unchallenged21:11
ayounghenrynash, and the explicit  assignment_list = self.assignment_api.list_role_assignments  afterwards  adds to the badness21:12
*** jorge_munoz has joined #openstack-keystone21:12
ayounghenrynash, so...can we somehow tag those interfaces as private even though they are called between two different controllers?21:12
ayounghenrynash, I think it is good as is21:13
ayounghenrynash, you see what I did in the previous patch, though, right?  Using the refs = [{'role_id': role['id']} for role in trust['roles']]  is really clunky21:14
*** jsavak has quit IRC21:14
henrynashayoung: so I do think we may want to refactor some of this….I agree….but maybe that is for us to come back in and do21:14
ayoungagreed21:14
ayounglets get this in.21:14
ayoungthe damage was done in a committed patch21:15
ayounghenrynash, suspect we should expand implied roles in the trust driver, but./..unified delagation21:16
ayounghenrynash, also  tomorrow, can we discuss the client interface for DSRs and Implied ROles?21:16
*** daemontool__ has joined #openstack-keystone21:17
henrynashayoung: sure21:17
ayounghenrynash, cool.  I have to go pick up my kids here in  aminute, or I'd subject you to it now21:18
ayoungvacation week...camps21:18
*** fawadkhaliq has quit IRC21:18
*** daemontool_ has quit IRC21:20
henrynashayoung: :-)21:20
*** roxanaghe has quit IRC21:23
*** sdake_ has joined #openstack-keystone21:24
openstackgerritMerged openstack/pycadf: Updated from global requirements  https://review.openstack.org/28086421:25
*** sdake has quit IRC21:25
*** rderose has quit IRC21:26
*** su_zhang has joined #openstack-keystone21:26
*** rderose has joined #openstack-keystone21:26
*** mhickey has quit IRC21:34
*** dims has quit IRC21:37
openstackgerritMerged openstack/keystone: Clean up configuration documentataion on v2 user CRUD  https://review.openstack.org/28075521:38
*** daemontool has joined #openstack-keystone21:38
openstackgerritMerged openstack/keystone: Don't describe trusts as an extension in configuration doc  https://review.openstack.org/28076121:39
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28089621:41
*** daemontool__ has quit IRC21:42
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/28089621:43
*** smurke has joined #openstack-keystone21:47
dolphmjamielennox: any idea why this code https://github.com/sumantmurke/rally/blob/gnocchi_gclient_using_v3_api/rally/osclients.py#L425-L442 would bail with http://cdn.pasteraw.com/arum9e2repugrmltuieh8fwe5gtcfsu ? (why is it looking for v3 stuff it's pretty explicitly using v2 everywhere? cc- smurke21:47
dolphmjamielennox: if you change it back to v3, then you'll also need to provide a project_domain_name (or project_domain_id) similar to this line https://github.com/sumantmurke/rally/blob/gnocchi_gclient_using_v3_api/rally/osclients.py#L43921:50
*** dims has joined #openstack-keystone21:50
dolphmsmurke: ^ sorry jamielennox21:50
*** gyee has joined #openstack-keystone21:50
*** ChanServ sets mode: +v gyee21:50
jamielennoxdolphm: no i can't think of any reason for that21:52
dolphmsmurke: try project_domain_id='default' with v321:53
jamielennoxor you can do the Password plugin, no versioned url and use default_domain_id='default'21:54
dolphmsmurke: so: username + password + user_domain_name + project_name + project_domain_id='default'21:54
smurkedolphm: Thanx21:54
dolphmjamielennox: please can the plugins please assume a user_domain_id and project_domain_id of 'default' unless a user_domain_* or project_domain_* is specified, please?21:55
*** roxanaghe has joined #openstack-keystone21:55
jamielennoxdolphm: for a couple of reasons, not really, but that's what default_domain_id is for21:55
dolphmjamielennox: you *can* pass a versioned URL to a Password plugin though, right? it doesn't have to be unversioned21:55
jamielennoxdolphm: just export OS_DEFAULT_DOMAIN_ID='default' in bashrc and never think about it again21:56
dolphmjamielennox: default_domain_id in keystone.conf?21:56
jamielennoxdolphm: no client side21:56
dolphmjamielennox: why force users to do that if it's going to be the case for 90% ?21:56
*** roxanaghe has quit IRC21:56
jamielennoxdolphm: OSC does do that, so for the 90% it's ok21:56
dolphmthat forces everyone to do busy work all the time, and it's just another hurdle to debug - resulting in crappy UX21:56
dolphmjamielennox: *everything* should assume the 'default' domain for user & project context though, unless one is specified. why just OSC?21:57
*** roxanaghe has joined #openstack-keystone21:57
jamielennoxbut given that we still can't have service users in the non-default domain i know a lot of deployments put customers in non-default domain21:57
dolphmalso, OSC does not assume anything if you still have to specify it separately21:57
jamielennoxdolphm: no, OSC will assume default_domain_id='default' if the user doesn't specify anything else21:58
jamielennoxi don't think they do it in exactly that way but it boils down to the same thing21:58
dolphmjamielennox: okay, so what's different about plugins?22:01
dolphmslash, why should plugins behave differently?22:02
*** notmorgan changes topic to "mitaka-3 feature freeze on FEB 29 - please prioritize reviews accordingly! | Mitaka-3: https://launchpad.net/keystone/+milestone/mitaka-3"22:03
*** ebalduf has quit IRC22:03
*** spandhe has quit IRC22:05
*** daemontool has quit IRC22:05
ayoungdolphm, what if we made that something that could be queried, and part of the negotiate response?22:06
*** mylu has joined #openstack-keystone22:07
ayoungGET /v2.0/domain  returns {'name': 'Default', 'id' : 'default'}22:07
*** spandhe has joined #openstack-keystone22:08
*** aginwala has quit IRC22:08
jamielennoxdolphm: i guess it grew out of not trying to hide domains as a v3 concept, times before where i've tried to cut down on the amount of auth information i've been told it doesn't matter because it's either configured via some CM system or provided by an accrc/clouds.yaml file where the provider can influence the variables22:09
jamielennoxi know the clouds i've seen here do a domain per customer (customer != user)22:10
jamielennoxso specifying a accrc with the default_domain_id/name of the user is going to eliminate almost all the user dealing with domains22:10
jamielennoxas it's rare that a user will be dealing with projects outside their domain22:11
jamielennoxthough i guess this doesn't help for v2/v322:11
jamielennoxayoung: i don't really want to add anything to /v222:11
ayoungjamielennox, neither do I, but this is the outcome of the cross-project meeting22:12
ayoungthis has been a thorn in our side for a while, dolphm is right here, and this is the cleanest way to expose the domain data to the client.22:12
ayoungGuessing that it is "default" will break when the users change the config22:13
ayoungthat might be a rare occurance, but I can actually see it happening in this scenario:22:13
ayoung1.  Use installer to get thing srunning22:13
ayoung2.  Add in LDAp support into a domain specific backend22:13
ayoung3.  change default domain to be the LDAP backed domain22:13
ayoung4.  Break everything and have pissed off operators22:13
ayoungdolphm, if the client could query the value from the Keystone server, would that serve your needs?22:14
*** mylu has quit IRC22:14
*** petertr7 is now known as petertr7_away22:17
*** dave-mccowan has quit IRC22:26
dolphmayoung: i don't need / want a query for that22:31
dolphmi'm in general super opposed to GET /service-configuration type calls22:31
*** mylu has joined #openstack-keystone22:32
ayoungdolphm, OK.  I'm not going to go to bat for it.  But I don't like the "assume it is default" approach either22:32
ayoungdolphm, any suggesting how to fix it, or do we just full-press to get people to V3 and wash our hands of it?22:34
ayoungI'm not 100% certain that we can't work around my use case now22:34
ayoungif the whole install is done V3, you could probably hack the database to move the service users out of "default" and into some Dom Specifi Backe End22:35
jamielennoxayoung: not as far as i'm aware, there are still some services that expect and auth with v2 so you have to have those in the default domain22:38
jamielennoxthere aren't many though22:38
openstackgerritRon De Rose proposed openstack/keystone: Shadow users - Separate user identities  https://review.openstack.org/27857022:38
*** henrynash has quit IRC22:40
openstackgerritRon De Rose proposed openstack/keystone: Shadow users - Separate user identities  https://review.openstack.org/27857022:41
*** gordc has quit IRC22:43
*** dims has quit IRC22:47
openstackgerritSteve Martinelli proposed openstack/keystone: wsgi: fix base_url finding  https://review.openstack.org/22646422:48
*** daemontool has joined #openstack-keystone22:48
*** Nakato has quit IRC22:50
*** Nakato has joined #openstack-keystone22:50
*** diazjf has quit IRC22:55
openstackgerritRoxana Gherle proposed openstack/keystone: Update websso doc with WEBSSO_KEYSTONE_URL option  https://review.openstack.org/28097422:55
*** ninag has quit IRC22:57
*** pece has quit IRC22:57
ayoungjamielennox, so, you, me and dolphm have a mutually exclusive set of requirements here23:00
*** aginwala has joined #openstack-keystone23:00
*** sigmavirus24 is now known as sigmavirus24_awa23:00
*** spandhe has quit IRC23:03
rderosedstanek: are you still on?23:07
*** sdake_ has quit IRC23:09
openstackgerritayoung proposed openstack/python-keystoneclient: Implied Roles  https://review.openstack.org/28098323:10
ayoungjamielennox, does ^^ looks sane?23:10
jamielennoxayoung: english or not i don't like that you switch from X_implied to delete_implication - otherwise at first glance it looks fine23:12
samueldmqayoung: I was going to ask: "hasn't this merged already?!?'23:17
*** slberger has left #openstack-keystone23:17
*** rcernin has quit IRC23:18
samueldmqayoung: I thought it was a server patch23:18
*** rderose has quit IRC23:18
ayoungjamielennox, I'm open to suggestions.  What would be the preffered language there>23:19
ayoung?23:19
jamielennoxjust delete_implied i think23:19
samueldmqayoung: commented there23:19
* samueldmq 's afk for a bit, brbr23:20
*** pushkaru has quit IRC23:20
ayoungand yes, I know it needs tests.  I am about to try it on a Kolla setup...lets' see what happens.23:20
*** pushkaru has joined #openstack-keystone23:20
*** phalmos has quit IRC23:20
*** spandhe has joined #openstack-keystone23:20
*** mylu has quit IRC23:24
*** jbell8_ has joined #openstack-keystone23:28
*** jbell8_ has quit IRC23:29
*** DuncanT_ has joined #openstack-keystone23:30
*** gyee_ has joined #openstack-keystone23:30
*** andrewbogott_ has joined #openstack-keystone23:30
*** dave-mccowan has joined #openstack-keystone23:31
*** tpeoples_ has joined #openstack-keystone23:31
*** mylu has joined #openstack-keystone23:31
*** BrAsS_mO- has joined #openstack-keystone23:35
*** EmilienM_ has joined #openstack-keystone23:35
*** cburgess has joined #openstack-keystone23:35
*** wasmum- has joined #openstack-keystone23:35
*** clayton_ has joined #openstack-keystone23:36
*** gyee has quit IRC23:37
*** jbell8 has quit IRC23:37
*** ekarlso has quit IRC23:37
*** wasmum has quit IRC23:37
*** clayton has quit IRC23:37
*** andrewbogott has quit IRC23:37
*** tpeoples has quit IRC23:37
*** EmilienM has quit IRC23:37
*** dobson has quit IRC23:37
*** jrist has quit IRC23:37
*** mdavidson has quit IRC23:37
*** cburgess_ has quit IRC23:37
*** BrAsS_mOnKeY has quit IRC23:37
*** DuncanT has quit IRC23:37
*** johnthetubaguy has quit IRC23:37
*** clayton_ is now known as clayton23:37
*** EmilienM_ is now known as EmilienM23:37
*** EmilienM is now known as Guest2883623:37
*** dobson has joined #openstack-keystone23:37
*** roxanaghe has quit IRC23:38
*** andrewbogott_ is now known as andrewbogott23:40
*** tpeoples_ is now known as tpeoples23:40
*** Guest28836 has quit IRC23:41
*** Guest28836 has joined #openstack-keystone23:41
*** roxanaghe has joined #openstack-keystone23:41
*** Guest28836 is now known as EmilienM23:42
*** mdavidson has joined #openstack-keystone23:43
*** DuncanT_ is now known as DuncanT23:43
*** dims_ has joined #openstack-keystone23:44
*** pushkaru has quit IRC23:44
*** jrist has joined #openstack-keystone23:44
*** andrewbogott has quit IRC23:45
*** andrewbogott has joined #openstack-keystone23:45
*** mylu has quit IRC23:47
*** ekarlso has joined #openstack-keystone23:47
*** johnthetubaguy has joined #openstack-keystone23:47
*** ekarlso has quit IRC23:48
*** ekarlso has joined #openstack-keystone23:48
*** mylu has joined #openstack-keystone23:50
*** sdake has joined #openstack-keystone23:53
*** browne has quit IRC23:56
*** mylu has quit IRC23:56

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