Tuesday, 2015-05-12

*** samueldmq_ has joined #openstack-keystone00:00
*** bknudson has joined #openstack-keystone00:00
*** ChanServ sets mode: +v bknudson00:00
*** dims has joined #openstack-keystone00:00
*** ericksonsantos has joined #openstack-keystone00:15
*** blewis has quit IRC00:16
*** blewis has joined #openstack-keystone00:18
*** erickson has quit IRC00:18
*** iamjarvo has joined #openstack-keystone00:25
*** ankita_wagh has joined #openstack-keystone00:33
*** samleon has quit IRC00:33
*** ankita_w_ has quit IRC00:35
*** erickson has joined #openstack-keystone00:36
*** ericksonsantos has quit IRC00:39
*** packet has joined #openstack-keystone00:44
*** lhcheng has quit IRC00:48
Raildo_Quicky doubt, is there some size limit for a patch? for exemple, if a change has more than 600 LOC, I need to break this in more than one.00:53
*** diegows has quit IRC00:53
*** iamjarvo has quit IRC00:53
bknudsonRaildo_: changes should be split up if they can be.00:55
bknudsonmake each patch a logical unit00:55
bknudsonreviews will go faster00:55
*** ChanServ changes topic to "Liberty Development Open | Review Liberty Specs | See you at the summit!"00:55
-openstackstatus- NOTICE: Gerrit has been downgraded to version 2.8 due to the issues observed today. Please report further problems in #openstack-infra.00:55
Raildo_bknudson, right... I was thinking about it, sometimes that is huge changes, and this make difficult to review and it's difficult to the reviewer see if the change can be splitted.00:57
*** ankita_wagh has quit IRC01:05
*** ankita_wagh has joined #openstack-keystone01:06
*** gyee has quit IRC01:12
*** Raildo_ has quit IRC01:17
*** ankita_wagh has quit IRC01:17
*** ankita_wagh has joined #openstack-keystone01:17
*** redrobot has quit IRC01:25
*** stevemar has joined #openstack-keystone01:25
*** ChanServ sets mode: +v stevemar01:25
*** redrobot has joined #openstack-keystone01:26
*** redrobot is now known as Guest2030601:26
*** dstanek has quit IRC01:26
*** dstanek has joined #openstack-keystone01:26
*** ChanServ sets mode: +v dstanek01:26
*** alexsyip has quit IRC01:27
*** _cjones_ has quit IRC01:28
*** blewis has quit IRC01:33
*** ankita_wagh has quit IRC01:36
*** ankita_wagh has joined #openstack-keystone01:36
*** browne has quit IRC01:39
*** zzzeek has quit IRC01:40
*** ankita_wagh has quit IRC01:41
openstackgerritMerged openstack/keystone: Remove support for loading auth plugin by class  https://review.openstack.org/17190601:42
*** iamjarvo has joined #openstack-keystone01:46
openstackgerritBrant Knudson proposed openstack/keystone: Use stevedore for auth drivers  https://review.openstack.org/18210201:52
openstackgerritBrant Knudson proposed openstack/keystone: Short names for auth plugins  https://review.openstack.org/18210701:52
openstackgerritBrant Knudson proposed openstack/keystone: Tests don't override default auth methods/plugins  https://review.openstack.org/18213701:52
*** sigmavirus24 is now known as sigmavirus24_awa01:54
*** ankita_wagh has joined #openstack-keystone01:55
*** ankita_wagh has quit IRC01:55
*** ankita_wagh has joined #openstack-keystone01:56
*** ericksonsantos has joined #openstack-keystone01:59
*** packet has quit IRC02:00
openstackgerritBrant Knudson proposed openstack/keystone: Update sample config file  https://review.openstack.org/18213802:00
*** erickson has quit IRC02:02
*** erickson has joined #openstack-keystone02:03
*** ericksonsantos has quit IRC02:03
*** ericksonsantos has joined #openstack-keystone02:05
*** bknudson has quit IRC02:08
*** erickson has quit IRC02:09
*** ericksonsantos has quit IRC02:11
*** browne has joined #openstack-keystone02:13
*** samueldmq_ has quit IRC02:14
*** hightall has joined #openstack-keystone02:14
hightallhow can I update user password through rest api?02:15
hightallI debug "keystone user-password-update", but I can not see where is the new password written.02:16
hightallOnly see "PUT /v2.0/users/35b3026e368c4bbba57765c417b69a79/OS-KSADM/password"02:16
*** lhcheng has joined #openstack-keystone02:18
*** richm has quit IRC02:18
*** ChanServ sets mode: +v lhcheng02:18
*** yasu_ has joined #openstack-keystone02:19
*** lhcheng has quit IRC02:19
*** sigmavirus24_awa is now known as sigmavirus2402:21
hightallanybody can help?02:28
*** spandhe has quit IRC02:33
stevemarhightall, the new password won't be in the logs02:36
*** ajayaa has joined #openstack-keystone02:36
hightallstevemar, so I need look at the code02:37
stevemarhightall, the owning user can just create a request to the documented API02:38
hightallstevemar, yes I know it, but I want to force reset user's password through admin, when user forget the password.02:39
stevemarhightall, should be the same request02:40
stevemarthe policy should allow for admin or owning user02:40
*** dims has quit IRC02:45
*** packet has joined #openstack-keystone02:45
*** packet has quit IRC02:47
hightallstevemar, I have seen the code in keystoneclient, and the body is {"user": {"id": base.getid(user), "password": password}}03:00
*** davechen has joined #openstack-keystone03:00
stevemarnkinder, ping03:01
nkinderstevemar: hey03:01
stevemarnkinder, anyway we could meetup a tinch earlier03:01
nkinderstevemar: sure.  When were you thinking?03:01
stevemari leave at 4pm on wednesdays for rec league sports03:01
stevemar1 hr earlier is fine with me03:02
stevemaror literally all of tomorrow :P03:02
nkinderI'm swamped tomorrow03:03
nkinderI'll move it to be a bit earlier on Wed.03:03
stevemarcool with me, thanks a lot03:04
nkinderno problem03:04
*** davechen1 has joined #openstack-keystone03:07
*** lhcheng has joined #openstack-keystone03:08
*** ChanServ sets mode: +v lhcheng03:08
*** davechen has quit IRC03:08
*** lhcheng has quit IRC03:11
*** davechen has joined #openstack-keystone03:12
*** ankita_wagh has quit IRC03:12
*** davechen1 has quit IRC03:14
*** dstanek has quit IRC03:16
*** dstanek has joined #openstack-keystone03:19
*** ChanServ sets mode: +v dstanek03:19
*** stevemar has quit IRC03:31
*** ankita_wagh has joined #openstack-keystone03:32
*** lhcheng has joined #openstack-keystone03:38
*** ChanServ sets mode: +v lhcheng03:38
*** lhcheng_ has joined #openstack-keystone03:40
*** lhcheng has quit IRC03:42
openstackgerritDave Chen proposed openstack/keystone: Add missing part for `token`  https://review.openstack.org/18214703:42
openstackgerritDave Chen proposed openstack/keystone: Add missing part for `token` object  https://review.openstack.org/18214703:45
*** davechen has left #openstack-keystone03:48
*** mabrams has joined #openstack-keystone04:01
*** sigmavirus24 is now known as sigmavirus24_awa04:05
*** spandhe has joined #openstack-keystone04:11
*** spandhe_ has joined #openstack-keystone04:12
*** spandhe has quit IRC04:16
*** spandhe_ is now known as spandhe04:16
*** _cjones_ has joined #openstack-keystone04:28
*** ajayaa has quit IRC04:29
*** dims has joined #openstack-keystone04:33
*** _cjones_ has quit IRC04:33
*** dims has quit IRC04:38
*** lhcheng_ has quit IRC04:43
*** yasu_ has quit IRC04:52
*** stevemar has joined #openstack-keystone04:54
*** ChanServ sets mode: +v stevemar04:54
*** markvoelker has joined #openstack-keystone04:54
*** ayoung has quit IRC05:06
*** ericksonsantos has joined #openstack-keystone05:07
*** ericksonsantos has quit IRC05:11
openstackgerritDave Chen proposed openstack/keystone: Add missing part for `token` object  https://review.openstack.org/18214705:12
*** iamjarvo has quit IRC05:13
*** davechen has joined #openstack-keystone05:13
*** lhcheng has joined #openstack-keystone05:16
*** ChanServ sets mode: +v lhcheng05:16
*** ajayaa has joined #openstack-keystone05:23
*** arunkant has quit IRC05:48
*** topol has joined #openstack-keystone05:58
*** ChanServ sets mode: +v topol05:58
*** ankita_wagh has quit IRC06:02
*** arunkant has joined #openstack-keystone06:03
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/17933106:06
*** hugokuo has quit IRC06:07
*** dstanek has quit IRC06:08
*** dstanek has joined #openstack-keystone06:09
*** ChanServ sets mode: +v dstanek06:09
*** hugokuo has joined #openstack-keystone06:09
*** ankita_wagh has joined #openstack-keystone06:11
*** mflobo has quit IRC06:14
*** markvoelker has quit IRC06:15
*** mflobo has joined #openstack-keystone06:16
*** afazekas_ has joined #openstack-keystone06:16
*** ankita_w_ has joined #openstack-keystone06:17
*** ankita_w_ has quit IRC06:17
*** markvoelker has joined #openstack-keystone06:18
*** ankita_w_ has joined #openstack-keystone06:18
*** ankita_wagh has quit IRC06:21
*** topol has quit IRC06:29
*** spandhe has quit IRC06:39
*** lhcheng_ has joined #openstack-keystone06:39
*** lhcheng has quit IRC06:43
*** kiran-r has joined #openstack-keystone06:50
*** kiran-r has quit IRC06:55
*** stevemar has quit IRC06:57
*** lhcheng_ has quit IRC07:00
*** browne has quit IRC07:15
*** junkao has joined #openstack-keystone07:20
*** ankita_w_ has quit IRC07:20
*** ankita_wagh has joined #openstack-keystone07:20
*** ankita_wagh has quit IRC07:26
*** jistr has joined #openstack-keystone07:33
*** jaosorior has joined #openstack-keystone07:38
*** openstackstatus has quit IRC07:52
*** openstack has joined #openstack-keystone07:53
*** openstackstatus has joined #openstack-keystone07:53
*** ChanServ sets mode: +v openstackstatus07:53
*** e0ne has joined #openstack-keystone08:17
*** e0ne is now known as e0ne_08:17
*** kiran-r has joined #openstack-keystone08:18
*** junkao has quit IRC08:22
*** mabrams has quit IRC08:26
*** davidckennedy has joined #openstack-keystone08:33
*** jimbaker has quit IRC08:42
*** ericksonsantos has joined #openstack-keystone08:44
*** e0ne_ is now known as e0ne08:46
*** e0ne is now known as e0ne_08:46
*** jimbaker has joined #openstack-keystone08:46
*** jimbaker has quit IRC08:46
*** jimbaker has joined #openstack-keystone08:46
*** e0ne_ is now known as e0ne08:55
*** tellesnobrega has quit IRC08:59
*** raildo has quit IRC09:00
*** htruta has quit IRC09:00
*** samueldmq has quit IRC09:00
*** ericksonfgds has quit IRC09:00
*** hightall has quit IRC09:11
*** aix has joined #openstack-keystone09:16
openstackgerritDavid Charles Kennedy proposed openstack/keystone-specs: Updated endpoint enforcement spec  https://review.openstack.org/17479909:18
*** fhubik has joined #openstack-keystone09:22
*** ericksonsantos has quit IRC09:22
openstackgerritDave Chen proposed openstack/keystone: Add notes for the SQLite database  https://review.openstack.org/18220509:23
*** hightall has joined #openstack-keystone09:25
*** hightall has quit IRC09:29
openstackgerritDave Chen proposed openstack/keystone: Upgrade Foreign key in Endpoint with ondelete='CASCADE'  https://review.openstack.org/17976709:30
*** diabloneo_ has joined #openstack-keystone09:34
*** diabloneo_ has quit IRC09:34
*** diabloneo has joined #openstack-keystone09:35
*** kiranr has joined #openstack-keystone09:37
*** jimbaker has quit IRC09:37
*** fhubik is now known as fhubik_afk09:40
*** ajayaa has quit IRC09:40
*** kiran-r has quit IRC09:40
*** jimbaker has joined #openstack-keystone09:41
*** jimbaker has quit IRC09:41
*** jimbaker has joined #openstack-keystone09:41
*** davechen has left #openstack-keystone09:45
*** kiranr is now known as kiran-r09:50
*** ajayaa has joined #openstack-keystone09:53
*** kiranr has joined #openstack-keystone09:56
*** kiran-r has quit IRC09:58
*** kiranr has quit IRC10:00
*** mabrams has joined #openstack-keystone10:02
*** diabloneo has quit IRC10:07
*** ericksonsantos has joined #openstack-keystone10:08
*** e0ne is now known as e0ne_10:21
*** ericksonsantos has quit IRC10:22
*** diabloneo__ has joined #openstack-keystone10:26
*** ericksonsantos has joined #openstack-keystone10:26
*** kiran-r has joined #openstack-keystone10:27
*** diabloneo__ has quit IRC10:27
*** diabloneo has joined #openstack-keystone10:28
*** jsheeren has joined #openstack-keystone10:30
*** dims has joined #openstack-keystone10:33
*** ajayaa has quit IRC10:34
*** kiran-r has quit IRC10:37
*** e0ne_ is now known as e0ne10:39
*** kiran-r has joined #openstack-keystone10:41
*** fhubik_afk is now known as fhubik10:47
*** ajayaa has joined #openstack-keystone10:48
*** ericksonfgds has joined #openstack-keystone10:53
*** amakarov_away is now known as amakarov10:53
*** ericksonsantos has quit IRC10:54
*** links has joined #openstack-keystone11:04
*** ajayaa has quit IRC11:04
*** tellesnobrega has joined #openstack-keystone11:31
*** ericksonfgds has quit IRC11:34
*** samueldmq has joined #openstack-keystone11:34
*** jistr is now known as jistr|class11:46
*** jistr|class is now known as jistr11:47
*** jistr is now known as jistr|class11:50
*** jistr|class is now known as jistr11:57
*** e0ne is now known as e0ne_12:00
*** dims_ has joined #openstack-keystone12:03
*** dims has quit IRC12:06
dstanekmarekd: hi12:15
*** raildo has joined #openstack-keystone12:15
*** jsheeren has quit IRC12:15
dstanekso, if i sit in a review too long (take my time and test it) I get logged out12:16
*** aix has quit IRC12:17
*** gordc has joined #openstack-keystone12:18
*** htruta has joined #openstack-keystone12:21
marekddstanek: hi12:24
*** aix has joined #openstack-keystone12:28
*** iurygregory has joined #openstack-keystone12:29
*** e0ne_ is now known as e0ne12:34
*** dims_ has quit IRC12:40
*** dims has joined #openstack-keystone12:42
*** mestery has joined #openstack-keystone12:43
*** radez_g0n3 is now known as radez12:49
*** fhubik is now known as fhubik_afk12:56
*** fhubik_afk is now known as fhubik13:00
*** vhoward has joined #openstack-keystone13:00
*** jistr is now known as jistr|mtg13:04
*** vhoward has left #openstack-keystone13:05
*** richm has joined #openstack-keystone13:06
*** kiran-r has quit IRC13:06
*** iamjarvo has joined #openstack-keystone13:09
*** lmtaylor1 has joined #openstack-keystone13:12
*** iamjarvo has quit IRC13:13
davidckennedyjamielennox - looking at keystone middleware bug https://bugs.launchpad.net/keystonemiddleware/+bug/120792213:21
openstackLaunchpad bug 1207922 in keystonemiddleware "auth_token middleware always use v2.0 to request admin token" [High,Confirmed] - Assigned to Jamie Lennox (jamielennox)13:21
davidckennedyCurrently the Identity servier instantiates the appropriate client but still gets revoked list from v213:21
openstackgerritMerged openstack/keystone: Add missing part for `token` object  https://review.openstack.org/18214713:22
davidckennedyWhy is that.  Shouldn't be too hard to delegate to the request_strategy, and if v2 is disabled getting the revoked list will bomb the middleware right?13:23
*** richm has quit IRC13:24
*** hightall has joined #openstack-keystone13:25
*** mattfarina has joined #openstack-keystone13:38
raildohey, in a reseller patch, I need to add a new parameter "is_domain"in the get_project_by_name method, and I want to use this parameter as a kwars, since I can set a default value to it. but I found a cache problem, "ValueError: dogpile.cache's default key creation function does not accept keyword arguments."13:43
raildotrace error: http://pastebin.com/index/7WX3HL1C13:43
*** jsavak has joined #openstack-keystone13:43
*** links has quit IRC13:44
raildoanyone can help me with this?13:44
*** lufix has joined #openstack-keystone13:45
samueldmqraildo, can you share the code as well ?  :)13:45
raildowhen I put the lbragstad suggestion I got this error13:46
*** vhoward has joined #openstack-keystone13:46
*** iamjarvo has joined #openstack-keystone13:46
lbragstadraildo: interesting13:46
lbragstadraildo: we can't pass a kwarg to another api within Keystone?13:47
raildolbragstad, I believe that we can, the problem is that the cache doesn't handle with a kwarg13:48
raildolbragstad, and I don't know why.13:48
lbragstadsounds like a bug in dogpile13:48
samueldmqraildo, how do you pass that argument ? I think lbragstad was talking about passing it as is_domain=is_domain13:49
raildosamueldmq, exactly if I pass in this way, I have this error.13:49
*** browne has joined #openstack-keystone13:50
raildosamueldmq, since the dogpile cache for get_project_by_name doesn't know how to handle with a kwarg. =/13:50
raildolbragstad, if  don't use this as a kwarg, I need to set the default value in every call to the manager, right? or handle with thin in the  manager level.13:52
samueldmqraildo, remove the @MEMOISE annotation, and use the cache mechanism as in create_project13:52
samueldmqraildo, https://review.openstack.org/#/c/158372/51/keystone/resource/core.py13:52
samueldmqlbragstad, cc ^ makes sense ?13:52
*** mestery has quit IRC13:53
lbragstadraildo: digging into the patch again13:53
*** e0ne is now known as e0ne_13:53
*** markvoelker has quit IRC13:53
samueldmqbut it should be cehcking/getting from the cache instead of setting13:54
*** e0ne_ is now known as e0ne13:55
*** hightall has quit IRC13:57
*** bknudson has joined #openstack-keystone13:57
*** ChanServ sets mode: +v bknudson13:57
*** fhubik is now known as fhubik_afk13:59
lbragstadraildo: have you seen this at all? https://bitbucket.org/zzzeek/dogpile.cache/issue/24/cache-invalidation-for-class-or-instance14:00
raildolbragstad, I had seen and later I come here to see if someone have passed for this.14:07
*** zzzeek has joined #openstack-keystone14:15
lbragstadraildo: and that's because of the call to cache.get_memoization_decorator()14:16
lbragstadthat's where this all blows up?14:16
*** stevemar has joined #openstack-keystone14:17
*** ChanServ sets mode: +v stevemar14:17
raildolbragstad, yes14:18
*** fhubik_afk is now known as fhubik14:18
*** fhubik is now known as fhubik_afk14:20
*** fhubik_afk is now known as fhubik14:22
*** topol has joined #openstack-keystone14:23
*** ChanServ sets mode: +v topol14:23
*** sigmavirus24_awa is now known as sigmavirus2414:25
*** ericksonsantos has joined #openstack-keystone14:30
*** blewis has joined #openstack-keystone14:32
davidckennedyjamielennox ^^ I see the issues are more complicated as the auth_token plugin makes its own mind up about where it's going to authenticate the auth token anyway.  This code is a rollercoaster.14:32
stevemarmarekd, added an image for SSO \o/14:33
*** thedodd has joined #openstack-keystone14:34
*** ericksonsantos has quit IRC14:35
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/17842614:35
*** spandhe has joined #openstack-keystone14:37
*** spandhe_ has joined #openstack-keystone14:38
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/18232314:39
*** jistr|mtg is now known as jistr14:39
*** Guest20306 is now known as redrobot14:39
*** spandhe has quit IRC14:41
*** spandhe_ is now known as spandhe14:41
*** emagana has joined #openstack-keystone14:42
*** blewis has quit IRC14:45
*** fhubik is now known as fhubik_afk14:51
*** fhubik_afk is now known as fhubik14:51
*** e0ne is now known as e0ne_14:51
*** fhubik is now known as fhubik_afk14:51
dstanekdavidckennedy: jamielennox probably won't be on for a while14:56
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/18232314:57
*** e0ne_ is now known as e0ne14:58
*** rwsu has joined #openstack-keystone14:59
*** mabrams has quit IRC15:00
*** browne has quit IRC15:00
*** lufix has quit IRC15:04
davidckennedydstanek yes, thanks.  Seems I can spend as much time as I like looking through this code....15:05
*** kiran-r has joined #openstack-keystone15:08
*** richm has joined #openstack-keystone15:09
*** fhubik_afk is now known as fhubik15:11
*** kiranr has joined #openstack-keystone15:11
*** kiran-r has quit IRC15:13
*** fhubik has quit IRC15:14
openstackgerritBrant Knudson proposed openstack/keystone: Update sample config file  https://review.openstack.org/18234115:14
*** afazekas_ has quit IRC15:15
*** ayoung has joined #openstack-keystone15:17
*** ChanServ sets mode: +v ayoung15:17
*** _cjones_ has joined #openstack-keystone15:19
*** rlt_ has joined #openstack-keystone15:20
marekdstevemar: thanks \o/15:22
stevemarmarekd, slowly but surely it'll get done15:24
marekdstevemar: i wouldn't worry about that.15:25
marekddo we have a meeting today?15:25
stevemarmarekd, just the regular keystone meeting15:25
*** kiranr has quit IRC15:26
*** mattamizer has joined #openstack-keystone15:27
*** blewis has joined #openstack-keystone15:27
*** _cjones_ has quit IRC15:29
*** _cjones_ has joined #openstack-keystone15:30
marekdstevemar: that's what i asked about :-)15:30
openstackgerritMerged openstack/keystonemiddleware: Add keystone v3 API to fetch revocation list  https://review.openstack.org/18017215:32
stevemarmarekd, i see you looking at the slides15:33
marekdstevemar: yes15:33
*** mattamizer has quit IRC15:35
*** lhcheng has joined #openstack-keystone15:39
*** ChanServ sets mode: +v lhcheng15:39
*** gyee has joined #openstack-keystone15:41
*** ChanServ sets mode: +v gyee15:41
marekd^^ west coast is waking up slowly15:42
*** ccrouch has quit IRC15:42
openstackgerritIhar Hrachyshka proposed openstack/oslo.policy: Expose base check classes as part of public API  https://review.openstack.org/17668315:45
*** Bjoern__ has joined #openstack-keystone15:46
*** spandhe_ has joined #openstack-keystone15:47
gyeemarekd, g'morning!15:47
marekdgyee: good afternoon!15:48
*** spandhe has quit IRC15:49
*** spandhe_ is now known as spandhe15:49
*** links has joined #openstack-keystone15:50
*** jistr has quit IRC15:50
*** blewis has quit IRC15:51
*** josecastroleon has quit IRC15:54
stevemarmarekd, hehe15:55
stevemarmarekd, yeah, i know it's lunch time when i see gyee and lhcheng sign on15:55
marekdstevemar: yeah, i know i should not be in the office when they sign on :P15:56
*** lufix has joined #openstack-keystone15:56
*** lufix has joined #openstack-keystone15:56
stevemarmarekd, time to head home!15:56
* gyee drops stevemar and marekd a hang loose sign15:56
marekdwill stay here for a while15:57
*** mtreinish has quit IRC15:58
marekdstevemar: did you actually even confirmed that openid connect doesn't support profiles for pure http user agents?15:58
*** ericksonfgds has joined #openstack-keystone15:58
*** rwsu has quit IRC15:58
*** rwsu has joined #openstack-keystone15:59
*** mtreinish has joined #openstack-keystone16:00
stevemarmarekd, you mean browserless flow?16:00
marekdstevemar: yes16:00
stevemarmarekd, i have someone working on that internally, he thinks it's do-able16:00
marekdstevemar: so he works on what exactly, SP, RP? or just a client?16:01
*** ankita_wagh has joined #openstack-keystone16:03
lhchengstevemar, stevemar: good morning!16:04
*** thedodd has quit IRC16:04
lhchengmarekd: good morning16:04
*** thedodd has joined #openstack-keystone16:04
marekdlhcheng: hello16:04
* lhcheng still waking up16:04
* marekd stevemar got 2x combo16:05
lhchengwell, there's really two stevemar. one that start works in the morning and the other one that starts work in the evening16:06
*** Bjoern__ is now known as BjoernT16:06
*** ericksonfgds is now known as ericksonsantos16:06
*** iamjarvo has quit IRC16:08
*** thedodd has quit IRC16:09
stevemarmarekd, he works on a product team, but wants the functionality16:11
*** openstackgerrit_ has quit IRC16:11
marekdstevemar: Kilo is the version where roughly all actions for federated users were CADF'ied, right?16:14
*** spandhe_ has joined #openstack-keystone16:15
*** thedodd has joined #openstack-keystone16:16
stevemarfor any user16:16
stevemarmarekd, ^16:16
*** alexsyip has joined #openstack-keystone16:17
*** spandhe has quit IRC16:17
*** spandhe_ is now known as spandhe16:17
*** davidckennedy has quit IRC16:18
gyeemarekd, about Sam's email, he's not changing the protocol16:23
gyeestill using SAML16:23
marekdgyee: but wants to put it as attribute in some JSON structure16:23
marekdso mod_shib and any other tool would be unusable, right?16:24
*** iamjarvo has joined #openstack-keystone16:24
*** iamjarvo has quit IRC16:24
*** spandhe has quit IRC16:24
*** BjoernT has left #openstack-keystone16:25
*** iamjarvo has joined #openstack-keystone16:25
marekdgyee: that what i understood from the spec draft he had sent (See Workflows)16:26
gyeelemme re-read the stuff16:26
*** browne has joined #openstack-keystone16:33
marekdgyee: for the openstack onyeco system it could ease many things, but imho this is not really lightweight k2k, it's just token that is signed and encrypted :-)16:34
gyeemarekd, yeah, you're right, the path would have to change, that's no good16:34
*** afazekas_ has joined #openstack-keystone16:35
marekdsticking with SAML just because we would reuse few lines of code and a library that nobody likes is pointless.16:36
gyeebut we have to use SAML right?16:36
marekdgyee: no we don't.16:37
gyeelike what, jwt? :)16:37
openstackgerritMerged openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/17842616:37
*** mestery has joined #openstack-keystone16:37
*** mestery has quit IRC16:38
marekdgyee: the reason we used saml last time with k2k was that joe savak insited on standardized protocol. I raised some questions, and still raise them: how can you communicate your cloud with non openstack sevice - keystoneclient will do that?16:38
marekdgyee: i think morganfainberg's just  closed the discussion.16:40
gyeemarekd, "non openstack service"?16:40
*** spandhe has joined #openstack-keystone16:41
marekdgyee: yeah, joe had an idea that private cloud provider may want to federated with some service, say ticketing as a service (whatever it is) and he would use his existing keystone to act as a IdP.16:42
*** afazekas_ has quit IRC16:42
marekdgyee: anyway, read morgans reply16:43
jsavakthat joe - full of crazy ideas.16:44
*** ankita_wagh has quit IRC16:44
marekdjsavak: revolution, not evolution :-)16:45
jsavakrevolution looks like evolution in hindsight sometimes. : )16:45
*** spandhe has quit IRC16:45
gyeeKeystone is not a real IdP :)16:46
gyeeit is an IdP proxy, really16:46
marekdgyee: yeah, but provides standardized way (SAML) of exposing some data to trusted peers16:46
marekdjsavak: for the records i am now quite thankful that we did k2k at that time, as with some extra work on other services, this will help us bursting into different clouds.16:47
jsavakkeystone as an idp proxy, enabling federation of identity into openstack and out of openstack16:47
jsavakmarekd - i agree : )16:48
rodrigodsthink weak link in k2k is the SP, so it should have robust verification IMO16:48
*** emagana has quit IRC16:48
gyeeKeystone is an IdP Decorator :)16:48
dstanekgyee: don't say that. i hate decorators16:49
marekddstanek: syntactic sugar, nothing more :P16:49
gyeedesign pattern, will get you past most job interviews16:49
marekdi doubt it.16:49
dstanekgyee: not if you say that Python decorators are a way to implement the decorator pattern :-P16:50
*** emagana has joined #openstack-keystone16:50
gyeedamn, I almost got away with that one16:51
gyeejsavak, in that case, it has to be more than just saml16:52
jsavakgyee, it should be extensible -16:52
marekdgyee: like another protocol ?16:52
jsavakwsfed, oauth216:52
gyeeright, pluggable protocol16:53
*** lmtaylor1 has quit IRC16:53
*** samleon has joined #openstack-keystone16:54
marekdgyee: do you think adding oidc would solve sam's problems?16:54
marekdgyee: i doubt it.16:54
gyeemarekd, like rodrigods said, we need robust validation16:55
marekdgyee: the only thing i don't like in apache modules concept is that they don't overlap with keystone logic.16:55
gyeeproxies are way of life in any production deployment16:55
marekdgyee: agree16:56
marekdgyee: i bet somebody, somewhere had this problem already.16:56
gyeemarekd, everybody have this problem :)16:56
gyeealso, REST API and session affinity does sound pretty16:57
gyeeisn't REST APIs sessionless? :)16:57
lbragstadgyee: I hope so16:57
marekdit is, you simply move your scalability problem from fronend to backend  :P16:57
marekdgyee: for the record, i'd be happy to evaluate new ways of such data layers, but to me this will not be 'lightweight k2k' :-)16:59
marekdand this will not be open standard.16:59
marekdprobably token on steroids.16:59
morganfainbergFor the record: open standard pleas let's use those.17:00
morganfainbergLet's not NIH things.17:00
morganfainbergIf at all possible.17:00
gyeemarekd, isn't PKI token on steroids?17:00
gyeemorganfainberg, yeah I agree, stick with open standard is a requirement17:01
*** ankita_wagh has joined #openstack-keystone17:02
*** emagana has quit IRC17:02
*** mtreinish has quit IRC17:02
*** ptoohill has quit IRC17:02
*** mtreinish_ has joined #openstack-keystone17:02
*** Guest25580 is now known as dan17:02
marekdmorganfainberg: don't get me wrong - i am *not* writing any spec right now. I basically share your concerns, as much as I would like to have something better than sam or more integrated into keystone (with use of good 3rd party lib).  For sure i will not push for new protocol because "i know how to do this right, they don't "17:02
*** ptoohill has joined #openstack-keystone17:02
*** mtreinish_ is now known as mtreinish17:02
*** emagana has joined #openstack-keystone17:02
gyeeSAML is perfectly fine right now17:03
gyeeits the deployment part we need to get better at17:04
marekdgyee: as long as we don't need to dig too much into it17:05
morganfainbergmarekd: I really do not want to have a non open standard here. Just my view. And if we can solve this without implementing it all ourselves - I'm much happier. But I don't want to have to go to some people and explain why this non-standard is not an problem.17:05
marekdlooks like nobody wants to have a non-standard solution, so we are all ok .17:06
*** iamjarvo has quit IRC17:08
stevemarmarekd, can you look @ slide 19 for a sec?17:08
marekdstevemar: i am now17:09
samleonmorganfainberg, marekd, yeah, this is a non standard way, but it's not something to replace the current protocol, but just an alternative17:13
*** links has quit IRC17:14
samleonit basically just provides clients another 'simple' way if they decided to have less complex configuration17:14
morganfainbergsamleon: i don't think it's a good alternative if we're implementing all the code ourselves17:14
morganfainbergsamleon: my answer stays the same, i'm against doing a non-open standard here.17:15
morganfainbergsamleon, marekd: lets hold off on this and see what ayoung and nkinder have come up with using mellon17:16
*** lufix has quit IRC17:16
*** lufix has joined #openstack-keystone17:17
morganfainbergbut let me say that if we do the "simple version", 1st: most people will move to it because it's easier - and now we have a whole slew of potential CVEs to keep up on and track. maintaining security code like this is not something we as keystone should really be in the business of.17:17
morganfainbergor well not move to it, but start with it17:18
marekdmorganfainberg: i am not pushing for that!17:18
morganfainbergand then moving to a more robust solution will be hard17:18
morganfainbergmarekd: i know you're not, but i want to make sure we're not headed that way with this convo17:18
dstanekthe hardest part about securing a system isn't the crypto it's the process of using the crypto correctly17:18
samleonmorganfainberg, yeah i agree17:18
dstanekwe should be very careful in this area17:18
gyeeyeah man, being there, done that17:18
gyeestill have burn marks17:19
morganfainbergwhen people say "it provides a simple way" - that sets off tons of red flags17:19
morganfainbergi mean, tons.17:19
morganfainbergunless the simple way is talking about chef or puppet recipes17:19
morganfainbergthen i smirk because it's simple for some things and some people and hard for others -- but not really our concern17:20
*** iamjarvo has joined #openstack-keystone17:20
morganfainbergwe have lots of smart puppet and chef people to make that part better :)17:20
*** harlowja has quit IRC17:22
dstanekmorganfainberg: we are still having a meeting right?17:22
morganfainbergdstanek: yep17:22
*** harlowja has joined #openstack-keystone17:22
morganfainbergdstanek: hopefully it'll be super short17:22
ayoungreading up17:22
dstanekcook, then i'll go a grab some lunch now17:22
morganfainbergdstanek: i have no agenda besides "hi, see you at the summit"17:22
dstanekmorganfainberg: "not if i see you first"17:22
ayoungsamleon, having trouble knowing where to start in the backlog17:23
samleonayoung, sorry did not put you in the loop17:23
ayoungsamleon, No problem.17:24
ayoungsamleon, is this about Shib?17:24
samleonayoung, i basically sent out an email last regarding some concerns for the issues we were facing with shib and had some proposes17:24
samleonayoung, i can forward you the email if you are interested17:25
samleonwith an initial 'specs' for the propose17:25
openstackgerritMerged openstack/keystone: Updated from global requirements  https://review.openstack.org/18232317:25
*** hemna has joined #openstack-keystone17:25
ayoungsamleon, please do17:26
morganfainbergsamleon: next time I highly recommend posting the spec to gerrit for review, or using a ML topic :)17:26
morganfainbergsamleon: you can mark it WIP or get more people involved. but privated emails like this end up missing some key people like ayoung and nkinder at times :)17:27
morganfainberg(the exception is clearly security bugs and the like)17:27
ayoungmorganfainberg, yep17:28
samleonmorganfainberg, ayoung, yeah, I will do that, and ayoung is included in the email now ;-)17:29
ayoungmorganfainberg, time to revisit http://adam.younglogic.com/2013/07/a-vision-for-keystone/17:29
morganfainbergsamleon: lets move this convo to an open place vs. just adding people to the thread17:29
samleonmorganfainberg, yep, let me do that17:30
morganfainbergsamleon: either post the RST or start a new thread on the ML17:30
morganfainbergif you do the latter just summarize the previous convos17:30
ayoungsamleon, let me read quick, and I can help short circuit the conversation17:31
ayoungsamleon, so...my origianl proposal along these lines was to use PKI tokens17:32
samleonmorganfainberg, what's RST?17:32
ayoungsamleon, RST is the doc format we use for specs17:32
morganfainberg.rst ? the format for the spec that was attached17:32
marekdsamleon: the one you had used :P17:32
samleonoh, sorry, it's in cap ;-)17:32
ayoungsamleon, and the PKI format was deemed not appropriate for reasons I do not agree with17:32
ayoungbut, that is water under the bridge17:32
ayoungsamleon, SAML,  JWT, Keystone...the format is less important than the document contents17:33
ayoungnow,  I would argue that the Keystone V3 tokens  API defines the minimal amount of data we need to share17:34
ayoungconverting that to SAML makes sense in that it is the best supported standard there is17:34
morganfainbergsamleon as a file extension .rst is fine, as an initialism describing the format, people use RST17:34
ayoungJWT was not quite there when we started17:34
ayoungsamleon, so..since we started with SAML, let us at least get SAML working17:35
samleonmorganfainberg, got that17:35
ayoungwe are not going to trash it yet, and the overhead is...meh17:35
ayoungits a pain in the kiester, but there are no good options yet17:35
ayoungsamleon,  for example http://adam.younglogic.com/2014/06/why-popen-for-openssl-calls/17:36
ayoungwhich is no longer the case...but  anyway17:36
ayoungsamleon, so,  if we are going to do anything besides SAML, I would argue for Keystone tokens in PKIZ format17:37
ayoungthe issues around that have to do with certificate exchange and mapping to Keystone users, but I think we can use the work gyee 's team is doing for X509 Tokenless to deal with mapping17:38
*** tellesnobrega_ has joined #openstack-keystone17:38
ayoungso really, it is a question of cert management17:38
samleonayoung, ++17:38
morganfainbergayoung: and my biggest complaint about PKIZ tokens is really justifying the protocol when explaining to everyone why we didn't use SAML or similar17:38
*** tellesnobrega_ has quit IRC17:39
morganfainbergayoung: and as much as i wish that wasnt an issue, it sadly is.17:39
ayoungmorganfainberg, Not going to argue it.17:39
marekdmorganfainberg: is it a justified issue and concern?17:39
morganfainbergayoung: i know, that argument sailed a while ago17:39
marekdis PKIZ worse/ less usable / less secure than SAML?17:39
ayoungmarekd, comparable17:39
morganfainbergmarekd: no, it is an unknown17:39
ayoungmarekd, it is a document format.  Period17:40
morganfainbergmarekd: talk to security guys17:40
ayoungSAML is a protocol17:40
ayoungand a docment format17:40
morganfainbergmarekd: unknowns are scary and painful17:40
morganfainbergmarekd: even if they really arent17:40
morganfainbergif we did the whole ietf formal process, this would be less of an issue.17:40
morganfainbergbut is there a benefit for us to do that?17:40
marekddon't know. was just asking.17:41
morganfainbergit wouldn't have been something we can do in the term we wanted federated id17:41
ayoungwhen it comes down to brass tacks, they are both documents signed using  PKI17:41
ayoungif the cert management is done right, they are comparable.  If it is not done right, they are both suspect17:41
morganfainbergayoung: correct. and i'm fine with saying we should go and ietf our protocol/document exchange17:41
morganfainbergand run it ourself17:41
ayoungmarekd, I wanted to push for distribtued signing, and splitting things along domain lines17:42
ayoungkeystoneX can sing for DomX in my cloud, and only DomX17:42
morganfainbergbut i really like having a set of knowns that people are comfortable with.17:42
ayoungDoes it matter if it is in SAML or PKIZ format?17:42
morganfainbergeven if they are roughly equivalent.17:42
morganfainbergSAML is already a known.17:42
marekdayoung: what stopped you from doing that?17:42
ayoungmarekd, 2 things17:42
ayoung1.  jsavak needed something that met with morganfainberg 's criteria above.  2.  I was working on other priorities17:43
marekdayoung: it does matter - as you said PKIZ is a format, so you can adjust and tweak workflow to your needs. If you break workflow with SAML - it's not SAML anymore.17:43
ayoungmarekd, the way either are used in this case it becomes a bearer token17:43
ayoungyou can't make a silk purse out of a sow's ear17:44
ayoungand you can't build a secure system out of passing around symmetric secrets17:44
ayoungmarekd, Federation uses SAML properly17:44
ayoungit is not a bearer token if the Service gives you a nonce that is part of the aserrtion17:45
ayoungWebSSO, I should state17:45
ayoungI'm stil undecided on ECP....17:45
ayoungbut, let's assume ECP also does the right thing...17:45
marekdayoung: agreed. For our needs we had to start using extensions because SAML didn't assume there are browserless clients who may want to use that.17:45
ayoungwhat the user needs from Keystone is not authentication, but authorization17:45
morganfainbergmarekd: PKIZ would end up being wraped into a protocol since we'd be using it between keystones of unknown code level - we would have to define it the same way SAML needs to be defined17:45
morganfainbergyou can't "just change it" or the other end may not understand it17:46
morganfainbergit's all the same boat(s).17:46
morganfainbergjust starting from different places17:46
*** chlong has quit IRC17:46
*** e0ne is now known as e0ne_17:47
ayoungmorganfainberg, I'm not going to go into deisgn right now...I had a different vision and I stepped out of the way due to practical considerations.  I don't  regret that.   But I can't really talk through the issues without going in to hwo I think it should have been designed17:47
ayoungWe have other use cases that we are not yet supporting17:48
marekdmorganfainberg: if the PKIZ is just a format and you want to use it between peers running your software you can do eerything. What stops you from wrapping your PKIZ token with a JSON structure?17:48
morganfainbergayoung: i was commented only on marekd's assertion pkiz as a transport17:48
ayoungmarekd, GAH17:48
ayoungmarekd, PKIZ IS a JSON FORMAT!17:48
morganfainbergayoung: i think we're all in the same general mindset at the moment.17:48
ayoungtake JSON,  sign it, compress it, and base64 encode it17:48
gyeepkiz is not a transport17:48
ayounggyee, HTTP is a transport17:49
* morganfainberg is going to a coffee shop - shoddy internet17:49
ayoungthe thing that PKIZ gives you is commitment to the data in the document mathcing the OpenStack view of authorziation.  Nothing more.17:49
morganfainbergi might be a few minutes to start the meeting17:49
ayoungmorganfainberg, want me to kick it off?17:50
morganfainbergif someone else wants to start it, please feel free to (hint ayoung or gyee )17:50
ayoungWill do17:50
morganfainbergagenda is up.17:50
morganfainbergreally i have exactly 1 item: hi everyone, see you at the summit, safe travels17:50
gyeeayoung, currently there's no mechanism in pkiz to guard replay17:50
morganfainbergtry and keep it short - if i miss the whole thing because it lasted 5 minutes id be happy17:50
marekdmorganfainberg: cool17:50
gyeedo we have a wiki on the vancouver hot spots?17:51
gyeelike how to get around?17:51
morganfainberggyee: someone sent a ML thread on it to -dev i think17:51
*** jaypipes has joined #openstack-keystone17:52
jaypipesayoung: ping, oh sir. ? about LDAP. Does Keystone support global cross-DC LDAP read/write with both auth and assignment in LDAP?17:53
morganfainbergjaypipes: keystone does not support Assignment LDAP - it is deprecated and going away17:53
ayoungjaypipes, even if it does, it shouldn't17:53
morganfainbergjaypipes: assigment being resources (projects/domains) and roles/assigment of role-user-project17:54
ayoungjaypipes, Galera sucks that bad?17:54
*** haneef has joined #openstack-keystone17:54
gyeemorganfainberg, I don't see that email, outlook probably filtered it out17:54
morganfainbergjaypipes: and it shouldn't do R/W LDAP identity. but that is a different thing17:54
morganfainbergand a separate argument i'm not willing to make *yet*17:54
gyeeI need to have a serious conversation with IT guys, they keep filtering out the good shit!17:54
ayoungmorganfainberg, does galera really suck that bad that people want LDAP for replication?17:55
jaypipeslol, thx ayoung and morganfainberg :) was just checking, cuz I wasn't sure. I never recommend using LDAP for writeable anything, but you know, solutions architects... that think they know best.17:55
morganfainbergjaypipes: :)17:56
jaypipesayoung: and no, Galera rocked for all large cross-DC deployments I was ever involved in.17:56
*** e0ne_ is now known as e0ne17:56
morganfainbergYeah galera is good until high latency17:56
gyeeayoung, do you know anyone running galera with more than 2 DCs? :)17:56
morganfainbergThen it's "eh ok with some potential ickyness"17:56
morganfainbergBut still not "oh god why" level of bad17:57
ayoungjaypipes, to be honest, I can see why people would want LDAP;  its a  database tuned for REad only eventual consistency, with a decent replciation story. Which sortof matches the openstack use case, but it confuses too many people, since LDAP is , for just about everyone else, readonly from an Openstack deployment17:57
morganfainbergayoung: I *really* like galera17:57
dstanekgyee: dolphm and lbragstad have been doing testing in this area17:57
gyeedstanek, how many sites?17:57
morganfainberggyee: not 8017:57
morganfainberggyee: a couple sites iirc17:58
dstanekgyee: i think 3 or 4 DCs, but you'd have to ask them for sure17:58
dstanekmorganfainberg: 80 DCs?17:58
lbragstadwe did it across three17:58
morganfainbergdstanek: was an ask I had at one point.17:58
morganfainbergI laughed at people for it.17:58
morganfainbergjaypipes: 100% what ayoung said btw.17:58
morganfainbergjaypipes: :)17:59
*** e0ne has quit IRC17:59
*** chlong has joined #openstack-keystone17:59
jaypipesmorganfainberg, ayoung; At AT&T, we actually used LDAP -- for the sysadmin deployment stuff :) For tenant/user identity/assignment, we used Galera.18:01
jaypipesthat way, we used LDAP for replicating the small list of sysadmin credentials to the baremetal hosts and that's it.18:01
dolphmlbragstad: we did 5 last time18:01
jaypipesuse LDAP for what it's good for, and use Galera for what it's good for.18:02
lbragstaddolphm: ++ yep, we successfully done it with five.18:02
morganfainbergjaypipes: about how I'd design things.18:02
lbragstadthe most recent deployment (30+ keystone nodes) spanned 318:02
jaypipesmorganfainberg: great minds...18:02
jaypipeswhen I left T, we were replicated multi-writer across 12 regions throughout the U.S., which each region's Keystone endpoint pointing to the nearest Galera cluster node housed inside that DC.18:03
lbragstadjaypipes: that makes sense18:04
lbragstadjaypipes: what did the replication footprint look like without tokens?18:04
lbragstador, excluding the token operations?18:04
jaypipeslbragstad: virtually nothing.18:05
jaypipeslbragstad: near 99% read activity (which is perfect for Galera loads across a WAN, actually)18:05
lbragstadjaypipes: did you have issues with schema upgrades?18:06
jaypipeslbragstad: since, if you think about it, how many times do you create a user/tenant record or role record vs. reading that information?18:06
jaypipeslbragstad: nope.18:06
lbragstadjaypipes: did you use the percona toolkit at all?18:06
lbragstadTOI or RSU?18:06
jaypipeslbragstad: RSU18:06
jaypipeslbragstad: we would take the API services down for a little while during the few schema migrations we needed to do.18:07
lbragstadso you did incur some downtime18:07
jaypipeslbragstad: even on a largish user/tenant collection, it's not like the Keystone DB is large...18:07
jaypipeslbragstad: yup. needed some anyway to restart/upgrade services.18:07
lbragstadcool, I just tried using the percona toolkit upgrade tool18:08
lbragstadfor the first time18:08
jaypipeslbragstad: and we used only the memcache token UUID driver.18:08
lbragstadthat must have helped18:08
jaypipeslbragstad: with the downside that folks needed to log into each region's dashboard to do shit on that region.18:08
jaypipesit was a downside we were OK with.18:08
lbragstadthat makes sense18:09
gyeejaypipes, it more than just keystone data right? you mean there's virtually nothing from keystone or other services if we take out the token data?18:10
*** samleon has quit IRC18:12
lbragstadgyee: how do you mean?18:16
gyeelbragstad, there's got to be more than just keystone data right? or the database is not shared18:16
*** iamjarvo has quit IRC18:17
jaypipesgyee: sorry, I'm not following you...18:18
lbragstadoh, if you have like nova and keystone sharing the same database?18:18
ayounggyee, so, yes, for K2K with SAML, the SAML assertion is not subject to a replay attack, but the tokens on either side of the wire are.  Perhaps that is sufficient security18:18
jaypipesgyee: we happen to have the image registry database in the same Galera cluster, but that's not necessary.18:18
dolphmgyee: keystone should have it's own DB in a multi-region scenario, no?18:18
lbragstadyeah, I would imagine a production environment would isolate them18:18
jaypipeslbragstad, gyee: ah, yes, Nova, Neutron, Cinder, and those services have a separate internal-to-a-region Galera cluster that does not bleed across failure domains, yes.18:19
lbragstadjaypipes: ++18:19
dolphmjaypipes: sharing with the image registry makes sense18:19
jaypipesdolphm: yeah, it's very similar data patterns. heavy read, low write, mostly PK lookups and inserts.18:19
gyeedolphm, jaypipes, lbragstad, shared db have its advantages too18:19
*** palendae has joined #openstack-keystone18:20
gyeeotherwise, separate HA, monitoring, replication, etc has cost too18:20
jaypipesgyee: not sure I'm following you...18:21
dolphmgyee: i assume you mean per-region HA of things that might otherwise be HA'd across regions?18:22
lbragstadgyee: but that's stuff that can be mitigated by bandwidth and compute power18:22
*** leveldoc has joined #openstack-keystone18:22
dolphmlbragstad: so, $18:22
lbragstadlol yes18:22
gyeeno, not HA across region18:23
gyeeper region18:23
*** rlt_ has quit IRC18:23
dolphmlow cost, HA, scale: choose any 2! ;)18:23
*** iurygregory has quit IRC18:24
dolphmgyee: i think we're on the same page18:25
leveldochi all...18:25
jaypipeshi Stephan :)18:25
leveldoclooking to understand plans for LDAP integration in Keystone.18:26
leveldochi Jay :)18:26
dolphmlbragstad: so what's the zero-downtime schema upgrade strategy you're looking at?18:26
leveldocAssignment LDAP going away?18:26
dolphmleveldoc: it's almost gone already!18:26
jaypipesleveldoc: dolphm, ayoung, morganfainberg are all good resources for you :)18:26
leveldocwhy is a r/w LDAP backend the wrong thing to do?18:26
ayoungI lie!18:26
leveldocayoung: hah!18:26
lbragstaddolphm: well, I had requests going against the existing deployment then just dropped a column and added a new one using the percona toolkit18:27
*** geoffarnold has joined #openstack-keystone18:27
ayoungleveldoc, 2 reasons18:27
dolphmleveldoc: what and why do you want keystone to write to LDAP?18:27
ayoungleveldoc, from my perspective, most people are using LDAP for Read only.18:27
ayoungso supporting R/W is an edge case that has little bang for the buck18:27
ayoungfor the operators standpoint, it menas using something that is not the norm18:27
lbragstaddolphm: the migration was simple but I wanted to see if performance took a hit18:28
dolphmlbragstad: i assume it did?18:28
*** blewis has joined #openstack-keystone18:28
dolphmlbragstad: wut18:28
lbragstaddolphm: ... yeah18:28
dolphmlbragstad: i assume you hit a table that was being read from?18:28
leveldocayoung: OK... so in other words we don't see enough usage of this feature18:28
lbragstadrpm didn't budge18:28
ayoungleveldoc  the User list is a corporate asset, not part of the openstack deployment18:28
dolphmlbragstad: what did you change?18:28
lbragstadthroughput didn't move18:28
ayoungKeystone should consume that list, but not manage it;18:28
lbragstadI added a column to the user table18:29
ayoungI don't add empolyees to my corporate LDAP via horizon18:29
dolphmlbragstad: "dropped a column" (what column?)18:29
lbragstaddolphm: which consisted of 240k users.18:29
dolphmayoung: behind the times, man18:29
leveldocayoung: understood - I get that and that's fine. What about role assignments and service users that have no place in the corporate directory?18:29
ayoungI use  a more full bodies workflow that knows about things like Kerberos principals and imaginary numbers and rainbows and capricorns.18:29
lbragstaddolphm: sorry, I didn't drop it, I added a column18:29
ayoungleveldoc, if LDAP is Read Only, you have a real problem18:29
ayoungyou can't manage projects18:29
dolphmleveldoc: those belong in SQL, right?18:30
ayoungand the assignemt code assumes it lives in the same server as the identity code18:30
ayoungsince, in the past, those two backends were unified18:30
leveldocwhy would these things belong in SQL?18:30
*** amakarov is now known as amakarov_away18:30
dolphmleveldoc: you just suggested they don't belong in LDAP18:30
ayoungleveldoc, assignments are Openstack specific data18:30
leveldocroles, groups, rights have always been managed by a directory server18:30
ayoungleveldoc, not cross-app they aren;'t18:30
dolphmleveldoc: where do you want service users and openstack authorization metadata to live?18:30
leveldocof course they are :)18:30
leveldocthat's the point of an LDAP server18:31
dolphmleveldoc: and you want keystone to write that stuff to your LDAP server?18:31
leveldocthat my rights, groups and access controls are properly propagated throughout my infrastructure18:31
ayoungleveldoc, the way Keystone uses them, the user comes with a set of groups.  That is input.  Openstack requires an additional layer of authorization18:31
ayoungleveldoc, if you want to set up a new server, you should not need to go talk to HR18:31
jaypipeslbragstad: I was wrong earlier. we used TOI.18:32
jaypipeslbragstad: during a downtime.18:32
lbragstadjaypipes: ah, sweet18:32
leveldochmm. OK so I think that this is probably best explained in person, or it's going to take all day typing it up in IRC18:32
dolphmleveldoc: can you explain what & why you want keystone to write to LDAP?18:32
lbragstadjaypipes: so you're app didn't have to deal with being backwards compatible with two schemas.18:32
jaypipeslbragstad: correct.18:33
lbragstadjaypipes: good to know18:33
dolphmis nova backwards compatible at all during schema upgrades? i know there's interest, but i don't know where the state of things has landed between pipe dream and reality18:34
lbragstadjaypipes: so, the identity api was talking to an ldap backend, right?18:35
leveldocI'd ultimately like Keystone to manage RBAC in LDAP, not in policy.json. This implies that my projects are in there. An object oriented database is better suited for role assignments and access rights management, which is why directory servers exist. These permissions, groups, roles, etc. that pertain to OpenStack can be written to a directory server and then consumed much easier from it.18:35
lbragstadjaypipes: so all users were living in ldap, which took care of that replication?18:35
leveldocI'm not suggesting to write to the corporate directory server, mind you - that's just silly. :)18:35
ayoungleveldoc, https://blog-nkinder.rhcloud.com/?p=13018:36
jaypipeslbragstad: no, only the sysadmin credentials for the baremetal nodes were in LDAP. We didn't use LDAP and Keystone together at all.18:36
ayoungThe rest is commentary.  GO and study18:36
lbragstadjaypipes: and this was all globally replicated?18:37
dolphmleveldoc: even if you deploy a second LDAP environment for keystone to read from (i've heard of people doing just that, but it's never been their first choice of solutions), why do you want to manage it through keystone?18:37
jaypipeslbragstad: yes. the LDAP store was tiny ... just a handful of sysadmin credentials. less than 30 people, AFAICR18:38
*** ksavich has joined #openstack-keystone18:38
jaypipesdolphm: I can walk you through what is rolling-upgrade possible in Nova.18:38
jaypipesdolphm: jerdfelt almost completed the online schema migration stuff, but we still need to comlpete it this cycle.18:39
dolphmjaypipes: how is it tested?18:39
jaypipesdolphm: the rolling compute node upgrade stuff, or the online schema migration stuff?18:40
dolphmjaypipes: online migrations18:40
dolphmjaypipes: or rather, the interaction between nova and a live migration18:41
jaypipesdolphm: one sec18:42
jaypipesdolphm: have you seen/read this? http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/online-schema-changes.html18:43
leveldocayoung: the blog entry covers authentication. I'm talking about assigment.18:43
*** jsavak has quit IRC18:43
dolphmjaypipes: i have not, i was hoping you could point me to something, thanks!18:43
jaypipesdolphm: no problemo. :)18:43
ayoungleveldoc, yes..  And the LDAP assignment code assumes that both are in the same backend18:43
leveldocdolphm: roles, permissions, etc. do not belong in a policy.json file. They belong in a policy server, IMHO and keystone should manage the appropriate permissions because they concern openstack?18:44
lbragstadjaypipes: so that spec will go through and make all existing migrations for nova "online capable"?18:44
*** iamjarvo has joined #openstack-keystone18:44
*** iamjarvo has quit IRC18:44
leveldocayoung: OK so assignment backend still remains pluggable then?18:45
jaypipeslbragstad: nope.18:45
ayoungleveldoc, yes18:45
dolphmleveldoc: keystone doesn't own policy.json in the first place. you could certainly write a policy driver for oslo.policy that reads from LDAP18:45
jaypipeslbragstad: it applies to new ones.18:45
*** jsavak has joined #openstack-keystone18:45
morganfainbergleveldoc: are you going to be at the summit?18:45
*** iamjarvo has joined #openstack-keystone18:45
ayoungleveldoc, even more so now with keystone. ROles and projects are in two different backends now18:45
leveldocmorganfainberg: yes... planning to get in touch with you guys there anyway18:45
dolphmmorganfainberg: when is our first pod-like timeslot?18:45
lbragstadjaypipes: ah, so each migration has a state, and it's this specs job to figure out how to expand or contract to that state from another given state?18:45
morganfainbergleveldoc: great! i think we have some stuff that will help you and you can see where we are going on this18:46
morganfainbergdolphm: uhm.. checking18:46
leveldocmorganfainberg: awesome. looking forward to engaging more18:46
jaypipeslbragstad: well, no, the spec describes the overall framework for splitting new DB schema migrations into things that can be run while the DB is online, things that can be batched during a downtime, and things that can run after the migration but when the DB is back online.18:46
leveldocayoung: awesome, that's what I wanted to hear. :) Looking forward to meeting you guys at the summit.18:47
ayoungCome to my talk18:47
morganfainbergdolphm: http://libertydesignsummit.sched.org/event/2625474f5b6a797403fe562ad8e776da18:47
jaypipesayoung: conf whore.18:48
ayoungjaypipes, while what you say is true, in this case my talk also happens to be relevant18:48
jaypipesjust pulling your leg.18:48
ayounghmmm  (116) now subtract out the keystone cores....18:49
ayoungcrud...I better finish this presentation18:49
*** iamjarvo_ has joined #openstack-keystone18:50
*** iamjarvo_ has quit IRC18:50
*** iamjarvo_ has joined #openstack-keystone18:50
lbragstaddolphm: the way the migration I tried earlier works, is that it creates a new shadow table with the new schema, sets up a trigger to copy all writes from the old table to the new one, and then start copying over data from the old table to the new table incrementally. Once it's done, it renames the new table and deletes the old one.18:51
*** afazekas_ has joined #openstack-keystone18:51
*** e0ne has joined #openstack-keystone18:51
*** Rockyg has joined #openstack-keystone18:53
*** iamjarvo has quit IRC18:53
*** afazekas_ has quit IRC19:03
*** ayoung has quit IRC19:03
* samueldmq missed the meeting :/ looking the logs19:03
*** ayoung has joined #openstack-keystone19:05
*** ChanServ sets mode: +v ayoung19:05
*** dguerri is now known as _dguerri19:06
*** lmtaylor1 has joined #openstack-keystone19:06
*** samleon has joined #openstack-keystone19:07
*** SunnyRainbow has joined #openstack-keystone19:08
samueldmqayoung, hi, need me to take a look at the policy presentation, anything related ?19:09
ayoungsamueldmq, heh...still wokring on it19:09
ayoungsamueldmq, appreciate the offer, but I suspect I'll be reworking it right up til the actual presentation19:10
samueldmqayoung, nice, let me know if you want me to take a look19:10
samueldmqayoung, oh ok then :)19:10
ayoungwill do...19:10
*** geoffarnold has quit IRC19:11
*** afazekas_ has joined #openstack-keystone19:13
*** afazekas_ has quit IRC19:15
*** afazekas_ has joined #openstack-keystone19:16
*** openstackgerrit_ has joined #openstack-keystone19:16
morganfainberglbragstad: interesting19:17
*** aix has quit IRC19:18
dolphmlbragstad: smart19:21
*** afazekas_ has quit IRC19:22
jsavaklbragstad: bodacious19:23
*** openstackgerrit_ has quit IRC19:25
morganfainbergayoung: having to learn the new gerrit ui is weird19:26
dstaneklbragstad: have you started to think about the code issues we talked about yesterday?19:27
*** jsavak has quit IRC19:31
*** jaosorior has quit IRC19:32
*** ayoung has quit IRC19:35
*** ayoung has joined #openstack-keystone19:36
*** ChanServ sets mode: +v ayoung19:36
ayoungsamueldmq, rodrigods as of Kilo; Role assignement inheritance is either on the parent OR all the children, but not both,  correct?19:37
ayoungor rather19:37
ayoungsamueldmq, rodrigods as of Kilo; Role assignement is either on the parent OR inherited by all the children, but not both,  correct?19:37
*** _dguerri is now known as dguerri19:38
*** thedodd has quit IRC19:38
*** jsavak has joined #openstack-keystone19:39
*** thedodd has joined #openstack-keystone19:41
stevemarwas there no meeting today?19:41
stevemaror was it just cut short/19:41
lbragstadmorganfainberg: dolphm jsavak what's bodaciously smart and interesting?19:41
lbragstadstevemar: there was, but it was short19:42
morganfainberglbragstad: the shadow table thing19:42
rodrigodsayoung, correct19:42
lbragstadmorganfainberg: oh yeah.. pretty slick19:42
raildolbragstad, morganfainberg can you talk about the cache problem now? :)19:42
morganfainbergcache problem?19:43
*** iurygregory has joined #openstack-keystone19:43
raildomorganfainberg, ops, I forgot that I don't had explained for you.19:43
openstackgerritMerged openstack/oslo.policy: Remove support for Python 3.3  https://review.openstack.org/18176719:44
raildomorganfainberg, lbragstad suggested here: https://review.openstack.org/#/c/158372/51/keystone/auth/controllers.py  handle with the is_domain as a kwarg19:45
*** markvoelker has joined #openstack-keystone19:45
raildomorganfainberg, but when I try do this, the get_project_by_name https://review.openstack.org/#/c/158372/51/keystone/resource/core.py19:45
morganfainbergyou can't use kwargs with caching19:46
gyeelbragstad, you read from both tables during upgrade19:46
*** turul_ has joined #openstack-keystone19:46
morganfainbergthe cache decorator can't handle them19:46
morganfainbergfor many many hard-to-fix reasons19:46
raildoyeap... this is the problem19:46
morganfainbergin short: don't19:46
morganfainbergi'll describe at the summit why it doesn't work [will take 5 mins at the summit] and like 20 to type it out ;)19:46
morganfainbergbut it's based on how python processes default arguments and how you consume argspec for memoization via a decorator19:47
raildomorganfainberg, wow... i can wait for the summit :P19:47
morganfainbergdefault args are not passed to the method, but are part of "locals"19:47
morganfainbergand caching becomes hard with that.19:47
raildothe other problem is that this method is a public API call for v2, so I don't know if put is_domain as a obligated parameter is the right way19:48
raildomorganfainberg, so, maybe can I still setting the default value as hard-coded in the manager level?19:49
morganfainbergraildo: you'll see how we do it in some cases where the manager calls self._<same method, but memoized>19:49
morganfainbergwhere the argspec doesn't have default args19:50
*** afazekas has quit IRC19:50
morganfainbergso manager.get_thing(default_arg=None)19:50
morganfainbergand that calls self._get_thing(default_arg)19:50
morganfainbergand self._get_thing is memoized vs the main manager method you'd call elsewhere19:50
raildomorganfainberg, ok, i get it. thanks :)19:51
*** gyee has quit IRC19:52
stevemarlink for working group sessions?19:53
samueldmqayoung, you're right on that sentence19:54
bknudsonany thoughts on keystoneclient / keystonemiddleware release? changes have been piling up.19:55
ayoungbknudson, after the summit19:55
bknudsonI don't think anything's waiting on it, just don't like to see lots of changes piling up19:55
morganfainbergbknudson: yeah lets do that today or tomorrow.19:55
ayounglet's not spend the summit fixing something19:55
morganfainbergor post summit19:56
morganfainbergbut after tomorrow no go19:56
bknudsonI hope it doesn't take us a week to recover from a botched release19:56
morganfainbergjamielennox: KSA - how close are we to a pre-release to pypi19:56
morganfainbergbknudson: it shouldn't... but if we're all at the summit we have other things to do than "fix" a botched release19:56
morganfainbergunless we make henrynash handle it :P19:57
bknudsonwell, since I think it'll be 2.0 of keystoneclient it might be more difficult to back it off19:57
morganfainbergbknudson: then maybe we wait for the end of the summit?19:57
bknudsony, might as well wait until after the summit19:58
morganfainbergbknudson: sounds good.19:58
morganfainbergbknudson: maybe we'll release on friday before people hop on planes >>19:58
bknudsonthat would also be a good time to upgrade gerrit, too.19:58
morganfainbergi'll suggest it to the infra folks20:00
lbragstadgyee I don't think so, the second table has a different name20:02
*** topol has quit IRC20:03
*** ayoung has quit IRC20:07
*** lufix has quit IRC20:09
*** iamjarvo_ has quit IRC20:12
*** iamjarvo has joined #openstack-keystone20:16
*** iamjarvo has quit IRC20:16
*** iamjarvo has joined #openstack-keystone20:17
*** ayoung has joined #openstack-keystone20:19
*** ChanServ sets mode: +v ayoung20:19
*** ayoung has quit IRC20:21
*** ayoung has joined #openstack-keystone20:21
*** sendak.freenode.net sets mode: +v ayoung20:21
*** lmtaylor1 has quit IRC20:28
*** markvoelker has quit IRC20:30
*** lmtaylor1 has joined #openstack-keystone20:30
samueldmqmorganfainberg, did you see bug #1207922 ?20:31
openstackbug 1207922 in keystonemiddleware "auth_token middleware always use v2.0 to request admin token" [High,Confirmed] https://launchpad.net/bugs/1207922 - Assigned to Jamie Lennox (jamielennox)20:31
samueldmqmorganfainberg, I think this is what causes devstack to fail when we have v3 only20:31
jamielennoxthat should be closed...20:31
samueldmq( at least one of the things )20:31
samueldmqjamielennox, oh great ..  fix released ?20:32
jamielennoxsamueldmq: if you use auth plugins then it should do the right thing20:32
jamielennoxit was just that the old admin_user etc options are v2 specific20:33
samueldmqjamielennox, cool .. but we can't use the admin user on v3 ?20:33
samueldmqjamielennox, how devstack is supposed to create data before any project/user/role assignment exists ?20:33
*** leveldoc has quit IRC20:34
samueldmqin a v3 only environemnt20:34
*** leveldoc has joined #openstack-keystone20:34
*** openstackgerrit has quit IRC20:37
*** openstackgerrit has joined #openstack-keystone20:37
richmsamueldmq: take a look a nkinder's scripts https://github.com/nkinder/rdo-vm-factory/blob/master/rdo-domain-setup/vm-post-cloud-init-rdo.sh20:38
richmsamueldmq: never mind20:38
richmthat's not what it is doing20:38
jamielennoxsamueldmq: i don't think that's different between v2 and v320:39
richmsamueldmq: but you can use admin_token to bootstrap the v3 stuff - once the v3 policy is in place, it is recommended to use v3 auth20:39
richmyou can continue to use the admin_token, but you'll have to hack your v3 policy to add is_admin:1 in a few places20:39
*** radez is now known as radez_g0n320:44
jamielennoxrichm: samueldmq was doing the v3 only gate job we talked about20:44
jamielennoxif you are looking for more current information20:44
*** rlt_ has joined #openstack-keystone20:44
samueldmqrichm, jamielennox k got it ... I will try again and see what it gives .. but I remember it was saying me a domain_id must be specified to get the token .. and there was no data created ..20:45
samueldmqmaybe it's just the way devstack is using it which is wrong20:45
jamielennoxsamueldmq: are you using the v3 policy file or the original one?20:45
samueldmqjamielennox, the original one ...20:45
jamielennoxthen that's weird20:46
jamielennoxusing the ADMIN_TOKEN?20:46
samueldmqjamielennox, richm btw, the patches for the gate jobs can be found here https://review.openstack.org/#/q/status:open+branch:master+topic:identity-v3-only-jobs,n,z20:46
samueldmqmorgan gave a +1 in the devstack change20:46
jamielennoxsamueldmq: looking at https://review.openstack.org/#/c/179663/5/stackrc20:49
jamielennoxdirectly above your change is IDENTITY_API_VERSION, would we not want to incorporate that somehow?20:49
bknudsonjamielennox: I made the same comment20:49
samueldmqjamielennox, yes and we do now, see https://review.openstack.org/#/c/179663/5/lib/keystone20:50
samueldmqexport IDENTITY_API_VERSION=320:50
samueldmqbknudson, cc ^20:50
samueldmqbknudson, I included this after your comment20:50
bknudsonit's still confusing20:50
bknudsonwhy not have IDENTITY_API_VERSION=v3-only ?20:51
jamielennoxbknudson: that value is used in openrc and other places so you would have to strip the -only from it20:51
bknudsontranslate it however you want.20:51
bknudsonI don't think devstack even works if you set it to 320:52
*** e0ne has quit IRC20:52
jamielennoxi really doubt it20:52
bknudsonshould just get rid of the option if it doesn't work20:53
*** iamjarvo has quit IRC20:53
*** e0ne has joined #openstack-keystone20:53
jamielennoxsamueldmq: i'll comment on the review but i want to get rid of https://github.com/openstack-dev/devstack/blob/master/lib/keystone#L42920:54
jamielennoxI don't want to append /v3 to the keystone catalog url, just be the root keystone url20:54
jamielennoxi'm not sure if that will be more or less problems20:55
samueldmqjamielennox, yes sure ;; other changes to make devstack work properlyu will follow this patch20:55
bknudsonv3 isn't going to work in the catalog since clients don't know what version the keystone endpoint supports20:55
samueldmqjamielennox, and effectivelly use it20:56
bknudsonthey think the identity endpoint is v2.020:56
samueldmqbut if we specify no version, it defaults to v3 somehow, rihgt ?20:56
bknudsonif there's no version in the catalog or if there is a version clients are going to assume it's v2.20:57
bknudsonbecause that's what it's always been20:57
jamielennoxright some things will break with removing /v2.020:58
bknudsonunless clients have all been updated to fetch the endpoint to discover what version it is20:58
jamielennoxbut we're supposed to list the root url and then services query that and discover what versions are available20:58
jamielennoxif just update to /v3 then things that assume /v2.0 will still break and we will be in the same problem in future20:59
samueldmqgetting a multiple choices ? and choosing the verison20:59
jamielennoxsamueldmq: commented21:00
*** lhcheng has quit IRC21:00
*** gyee has joined #openstack-keystone21:01
*** ChanServ sets mode: +v gyee21:01
jamielennoxi made another on the choice of flag name, i wouldn't -1 it based on that but it feels a little wrong at the moment21:01
samueldmqjamielennox, nice thanks for your review, will take a look21:01
*** iamjarvo has joined #openstack-keystone21:01
openstackgerritVictor Stinner proposed openstack/python-keystoneclient: Remove discover and iso8601 dependencies  https://review.openstack.org/17768721:02
*** e0ne has quit IRC21:03
samueldmqjamielennox, hmm .. I kinda hate you ... you're good with names :)21:03
samueldmqjamielennox, IDENTITY_DISABLE_V2 looks better21:03
*** iamjarvo has quit IRC21:04
jamielennoxme? i'm terrible with names21:04
*** lhcheng has joined #openstack-keystone21:04
*** ChanServ sets mode: +v lhcheng21:04
jamielennoxthat was probably the 3rd one i typed into that comment21:04
*** ankita_w_ has joined #openstack-keystone21:05
samueldmqjamielennox, regarding the urls that should not be versioned in the catalog in v3 ...21:06
jamielennoxsamueldmq: that's something i've been trying to do for a while21:06
jamielennoxif it breaks other things in devstack we can do it as a seperate change21:06
samueldmqjamielennox, do you think that is part of that patch ? I think that is much more the patches that will be coming in order to make devstack work properly with v3 only21:06
samueldmqjamielennox, yeah it's already broken as it is ... devstack need other changes21:07
*** jsavak has quit IRC21:07
*** stevemar has quit IRC21:08
*** iamjarvo has joined #openstack-keystone21:08
*** iamjarvo has quit IRC21:08
*** iamjarvo has joined #openstack-keystone21:09
openstackgerritVictor Stinner proposed openstack/python-keystoneclient: Remove unused fixtures  https://review.openstack.org/18245321:09
*** iamjarvo has quit IRC21:09
*** ankita_wagh has quit IRC21:09
samueldmqjamielennox, bknudson sorry need to go afk for a bit21:09
lbragstaddstanek: catching up now, what questions did you have about our code discussion yesterday?21:10
jamielennoxsamueldmq: np, are you at summit?21:11
*** ayoung has quit IRC21:12
*** gyee has quit IRC21:13
*** gyee has joined #openstack-keystone21:15
*** ChanServ sets mode: +v gyee21:15
*** rlt_ has quit IRC21:22
*** chlong has quit IRC21:24
*** ayoung has joined #openstack-keystone21:25
*** ChanServ sets mode: +v ayoung21:25
*** iamjarvo has joined #openstack-keystone21:26
*** iamjarvo has quit IRC21:26
*** blewis has quit IRC21:27
*** haneef has quit IRC21:28
dstanekjamielennox: yes, samueldmq will be there21:28
jamielennoxdstanek: thanks21:28
*** iamjarvo has joined #openstack-keystone21:29
*** haneef has joined #openstack-keystone21:29
openstackgerritDolph Mathews proposed openstack/python-keystoneclient: Handle attempts to "filter" list() calls by globally unique IDs  https://review.openstack.org/18245921:29
*** SunnyRainbow has quit IRC21:30
*** emagana has quit IRC21:30
*** emagana has joined #openstack-keystone21:30
*** mattfarina has quit IRC21:35
*** lmtaylor1 has left #openstack-keystone21:40
*** ayoung has quit IRC21:41
openstackgerritDolph Mathews proposed openstack/keystone: Improve error message when tenant ID does not exist  https://review.openstack.org/13125521:43
*** lhcheng_ has joined #openstack-keystone21:49
*** lhcheng has quit IRC21:49
*** iamjarvo has quit IRC21:55
*** ksavich has quit IRC22:09
*** wasmum has quit IRC22:09
*** ankita_w_ has quit IRC22:10
*** ksavich has joined #openstack-keystone22:12
*** ankita_wagh has joined #openstack-keystone22:13
*** jaypipes has quit IRC22:13
*** wasmum has joined #openstack-keystone22:16
*** bknudson has quit IRC22:18
*** josecastroleon has joined #openstack-keystone22:23
*** markvoelker has joined #openstack-keystone22:24
*** thedodd has quit IRC22:24
*** Rockyg has quit IRC22:24
*** josecastroleon has quit IRC22:24
*** dims_ has joined #openstack-keystone22:28
*** dims has quit IRC22:30
*** iamjarvo has joined #openstack-keystone22:31
*** iamjarvo has quit IRC22:31
*** ksavich has quit IRC22:41
*** ericksonfgds has joined #openstack-keystone22:50
*** lhcheng_ is now known as lhcheng22:56
*** ChanServ sets mode: +v lhcheng22:56
*** emagana has quit IRC23:06
*** jimbaker has quit IRC23:07
dstaneksqlalchemy-migrate is super frustrating - i just want to know why it doesn't like it when sqlite dbs have fks23:08
*** markvoelker has quit IRC23:08
*** mestery has joined #openstack-keystone23:09
*** jimbaker has joined #openstack-keystone23:11
*** jimbaker has quit IRC23:11
*** jimbaker has joined #openstack-keystone23:11
*** SunnyRainbow has joined #openstack-keystone23:12
*** chlong has joined #openstack-keystone23:15
* morganfainberg glares at internets23:26
* morganfainberg is back... for a 3rd time23:26
*** SunnyRainbow has quit IRC23:38
openstackgerritMorgan Fainberg proposed openstack/keystone-specs: Updated endpoint enforcement spec  https://review.openstack.org/17479923:45
sigmavirus24morganfainberg: go home, you don't need more internet =P23:46
morganfainbergsigmavirus24: hahahaha23:46
morganfainbergsigmavirus24: coffee shop wifi is better than home wifi today23:46
morganfainbergand i've only been dropped 4 times here23:46
sigmavirus24all the more reason to go home23:46
jamielennoxyep, that's the universe telling you to stop working23:56

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