Monday, 2014-09-08

bknudsondolphm: do you have a bot that posts rechecks?00:07
*** gokrokve has joined #openstack-keystone00:09
*** gokrokve has quit IRC00:14
*** amirosh has quit IRC00:17
*** amirosh has joined #openstack-keystone00:18
*** amirosh has quit IRC00:22
*** diegows has joined #openstack-keystone00:24
*** oomichi has joined #openstack-keystone00:35
bknudsondolphm: I brought up the pip failures in -infra... they seem to have some idea of which systems are worse than others at least.01:01
*** gokrokve has joined #openstack-keystone01:09
*** gokrokve has quit IRC01:14
morganfainbergYorikSar, ping me here tomorrow and i can describe a bit more in detail the interruption(s)01:26
morganfainberglbragstad, dolphm, not sure if we can "fix" this one https://bugs.launchpad.net/keystone/+bug/1328067 I think we want to mark this as "wont fix" for keystone server, it isn't really fixable. (we could change the "placeholder" to "DO NOT USE THIS ID").01:36
uvirtbotLaunchpad bug 1328067 in python-keystoneclient "Token with "placeholder" ID issued" [Medium,Triaged]01:36
morganfainberglbragstad, dolphm, we can fix middleware to not ever pass the id extracted from the body to the underlying service. and client if it use the id from the body, that should be fixed.01:37
morganfainbergI did try and extra the id from the V2 token at one point, it's a serious mess.01:37
lbragstadmorganfainberg: I'm fine with bumping it01:41
morganfainberglbragstad, i'm trying a quick fix for it now, but i think it wont be API compatible01:41
lbragstadthat makes sense01:41
morganfainbergand until we dump V2 api... it wont *ever* be fixable.01:41
morganfainbergthough i *think* we might be better served stopping issueing V2 tokens completely and just figuring out how to convert V2 tokens to V3 tokens and make it some kind of middleware01:42
morganfainbergbut that also might break PKI v2 users... now that i think about it01:42
jamielennoxi have a client patch that addresses this01:44
lbragstadmorganfainberg: lol I think you just defined the ultimate double edged sword01:45
jamielennoxoh - and it's merged already https://review.openstack.org/#/c/113415/01:45
jamielennoxnot going to be useful to heat until it's made use of in auth_token i guess01:45
morganfainbergjamielennox, ++ ok so we can mark as "fix committed" for client01:45
morganfainbergmiddleware likely needs to be tagged in that bug01:46
morganfainbergand in keystone i *think* we just need to say wont fix :(01:46
morganfainberglbragstad, i'll post my fix with a big fat warning "THIS MAY BE API INCOMPATIBLE" if it passes unit tests.01:49
morganfainberglbragstad the move to the token model in the server may have solved all the issues with needing the id in the token body.01:49
lbragstadsounds good01:54
*** dims has joined #openstack-keystone01:54
openstackgerritA change was merged to openstack/python-keystoneclient: Work toward Python 3.4 support and testing  https://review.openstack.org/11880201:59
*** HenryG_ is now known as HenryG02:01
openstackgerritA change was merged to openstack/keystone: Fix dn_startswith  https://review.openstack.org/11947802:02
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove the token id from V2 token body  https://review.openstack.org/11967302:07
morganfainberglbragstad, ^02:09
lbragstadmorganfainberg: perfect, thanks!02:10
openstackgerritDave Chen proposed a change to openstack/keystone: Inaccurate description found in keystone's docs  https://review.openstack.org/11682002:10
*** nkinder has joined #openstack-keystone02:32
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Sets a default timeout for cached data  https://review.openstack.org/11358602:33
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove unused cache functions from token.core  https://review.openstack.org/11967902:40
*** diegows has quit IRC02:41
*** rushiagr_away is now known as rushiagr02:52
*** dims has quit IRC02:56
*** oomichi is now known as oomichi_away02:57
*** nkinder has quit IRC02:59
*** oomichi_away has quit IRC03:02
*** rushiagr is now known as rushiagr_away03:03
*** rushiagr_away is now known as rushiagr03:05
*** gokrokve has joined #openstack-keystone03:09
*** amirosh has joined #openstack-keystone03:10
*** amirosh has quit IRC03:11
*** amirosh has joined #openstack-keystone03:12
*** gokrokve has quit IRC03:14
*** rushiagr is now known as rushiagr_away03:16
*** amirosh has quit IRC03:16
*** swartulv has quit IRC03:23
*** stevemar has quit IRC03:28
openstackgerritA change was merged to openstack/keystone: Add docs for enabling endpoint policy  https://review.openstack.org/11853003:43
*** stevemar has joined #openstack-keystone03:44
morganfainberglbragstad, well it looks like removing the ID from the v2 token doesn't break anything. though it still is likely not API compatible03:45
morganfainbergstevemar, ohhai03:45
jamielennoxmorganfainberg: makes sense, the services should be using the output from auth_token middleware and it uses the value from the headers not from within the token03:51
morganfainbergjamielennox, yep03:52
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Proper handling of catalog err cond w/os-token and os-endpoint  https://review.openstack.org/11868204:08
*** gokrokve has joined #openstack-keystone04:09
*** rushiagr_away is now known as rushiagr04:11
*** gokrokve has quit IRC04:14
*** amirosh has joined #openstack-keystone04:41
*** amirosh has quit IRC04:42
*** amirosh has joined #openstack-keystone04:43
openstackgerritA change was merged to openstack/keystone: Add characterization test for group role assignment listing  https://review.openstack.org/11947904:43
stevemarmorganfainberg, ahoy hoy04:45
*** amirosh has quit IRC04:47
*** ncoghlan has joined #openstack-keystone04:56
*** ajayaa has joined #openstack-keystone05:18
*** ukalifon1 has joined #openstack-keystone05:26
*** amirosh has joined #openstack-keystone06:09
*** gokrokve has joined #openstack-keystone06:09
*** ajayaa has quit IRC06:11
*** amerine has joined #openstack-keystone06:12
*** gokrokve has quit IRC06:14
*** amerine has quit IRC06:17
*** ajayaa has joined #openstack-keystone06:38
*** ajayaa has quit IRC07:08
*** jaosorior has joined #openstack-keystone07:09
openstackgerritJuan Antonio Osorio Robles proposed a change to openstack/keystone: Refactor assignment expansion related functions  https://review.openstack.org/11936307:13
*** stevemar has quit IRC07:13
*** ajayaa has joined #openstack-keystone07:21
*** afazekas_ has joined #openstack-keystone07:22
*** ncoghlan is now known as ncoghlan_afk07:24
*** ajayaa has quit IRC07:33
*** ncoghlan_afk is now known as ncoghlan07:34
*** nsaje_ has left #openstack-keystone07:51
*** ajayaa has joined #openstack-keystone07:55
*** Daviey has quit IRC08:01
*** gokrokve has joined #openstack-keystone08:09
*** henrynash has joined #openstack-keystone08:12
*** gokrokve has quit IRC08:14
*** Daviey has joined #openstack-keystone08:17
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Keystone part of a PoC for Horizon/Keystone WebSSO  https://review.openstack.org/10609608:25
*** andreaf_ is now known as andreaf08:29
*** aix has joined #openstack-keystone08:39
*** KanagarajM has joined #openstack-keystone08:43
*** amirosh has quit IRC08:50
*** amirosh has joined #openstack-keystone08:51
*** amirosh has quit IRC08:55
*** gokrokve has joined #openstack-keystone09:09
*** ncoghlan has quit IRC09:11
*** BAKfr has joined #openstack-keystone09:11
*** gokrokve has quit IRC09:13
*** bvandenh has joined #openstack-keystone09:32
*** bdossant has joined #openstack-keystone10:03
*** gokrokve has joined #openstack-keystone10:09
*** gokrokve has quit IRC10:14
*** rm_work has quit IRC10:15
*** rm_work|away has joined #openstack-keystone10:22
*** rm_work|away is now known as rm_work10:22
*** rm_work has joined #openstack-keystone10:22
*** dims has joined #openstack-keystone11:00
*** Alexander has joined #openstack-keystone11:01
*** Alexander is now known as Guest6033211:02
*** Guest60332 has left #openstack-keystone11:03
*** amirosh has joined #openstack-keystone11:06
*** gokrokve has joined #openstack-keystone11:09
*** gokrokve has quit IRC11:14
*** dims has quit IRC11:16
*** dims has joined #openstack-keystone11:16
*** dims_ has joined #openstack-keystone11:17
*** dims has quit IRC11:21
*** alexander__ has joined #openstack-keystone11:33
*** diegows has joined #openstack-keystone11:35
*** x-eye_ has joined #openstack-keystone11:37
*** alexander__ has quit IRC11:38
*** topol has joined #openstack-keystone11:38
*** x-eye_ has quit IRC11:40
*** amakarov has joined #openstack-keystone11:46
*** gokrokve has joined #openstack-keystone12:09
*** gokrokve has quit IRC12:14
*** KanagarajM has quit IRC12:15
*** dims_ has quit IRC12:16
*** dims has joined #openstack-keystone12:16
openstackgerrithenry-nash proposed a change to openstack/keystone: Fix LDAP group role assignment listing  https://review.openstack.org/11948012:20
*** dims_ has joined #openstack-keystone12:20
*** dims has quit IRC12:21
*** bjornar has joined #openstack-keystone12:29
bjornarHello guys. I am experiencing around 200ms load time for the "POST /v2.0/tokens" call12:29
openstackgerritAlexander Makarov proposed a change to openstack/keystone: LDAP additional attribute mappings validation  https://review.openstack.org/11859012:39
*** ayoung has joined #openstack-keystone12:40
*** topol has quit IRC12:43
*** radez_g0n3 is now known as radez12:51
*** vhoward has joined #openstack-keystone13:04
*** gokrokve has joined #openstack-keystone13:09
*** richm1 has joined #openstack-keystone13:11
*** gokrokve has quit IRC13:13
*** joesavak has joined #openstack-keystone13:14
*** bknudson has quit IRC13:25
dstanekhenrynash: ping13:28
henrynashdstanek: hi13:28
dstanekhenrynash: i just saw that you took over https://bugs.launchpad.net/keystone/+bug/121701713:28
uvirtbotLaunchpad bug 1217017 in keystone "dependency injection fails to init domain-specific identity drivers" [Medium,New]13:28
dstanekhenrynash: i just commented on it - take a look and let me know if that makes sense13:28
henrynashdstanek: actually, I didn’t realize that you had worked on it allready…so I didn’t mean to take it from udner your feet13:28
henrynashdtsanek: I just felt responsible since I did the multi-domain stuff!13:29
dstanekhenrynash: no i just did a little research yesterday13:30
dstaneki've been browsing the bugs this weekend so that i can pick up a few this week13:30
henrynashdstanek: and I agree with your comment….I knew in the back of my mind i needed to update the sql driver to handle the dymamic configs13:30
dstanekthe complicated part is that there needs to be either a way to fall back to the global config or explicit documentation saying that we don't do that13:31
openstackgerritAlexey Miroshkin proposed a change to openstack/keystone: Prevent domains creation for the default LDAP+SQL  https://review.openstack.org/11685813:32
dstanekfor instance, the reported  only has the driver listed in the config and not any of the other options13:32
*** bdossant has quit IRC13:33
*** bdossant has joined #openstack-keystone13:42
*** bdossant has quit IRC13:42
*** r-daneel has joined #openstack-keystone13:45
*** bknudson has joined #openstack-keystone13:46
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes code comment to be more accurate  https://review.openstack.org/11976013:46
*** sigmavirus24_awa is now known as sigmavirus2413:58
*** gokrokve has joined #openstack-keystone14:00
*** nkinder has joined #openstack-keystone14:00
samuelmzhenrynash, ping14:04
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add characterization test for cleanup role assignments for group  https://review.openstack.org/11963014:09
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix delete group cleans up role assignments with LDAP  https://review.openstack.org/11963114:09
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix using local ID to clean up user/group assignments  https://review.openstack.org/11962914:09
*** Daviey has quit IRC14:10
*** Daviey has joined #openstack-keystone14:25
*** topol has joined #openstack-keystone14:25
*** zzzeek has joined #openstack-keystone14:28
*** ajayaa has quit IRC14:29
*** david-lyle has joined #openstack-keystone14:30
*** afaranha has quit IRC14:33
openstackgerritYuriy Taraday proposed a change to openstack/keystonemiddleware: Add a pool of memcached clients  https://review.openstack.org/11977414:33
*** thiagop has quit IRC14:34
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Correct typos in keystone/common/base64utils.py docstrings  https://review.openstack.org/11977514:34
*** samuelmz has quit IRC14:34
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Correct typos in keystone/common/base64utils.py docstrings  https://review.openstack.org/11977514:35
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Correct typos in keystone/common/base64utils.py docstrings  https://review.openstack.org/11977514:35
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Correct typos in keystone/common/base64utils.py docstrings  https://review.openstack.org/11977514:35
*** saipandi has joined #openstack-keystone14:37
*** amirosh has quit IRC14:59
*** amirosh has joined #openstack-keystone15:00
YorikSarmorganfainberg: Eh... Why use ' everywhere? :)15:01
morganfainbergYorikSar, it's the general style for keystone15:02
morganfainbergYorikSar, https://github.com/openstack/keystone/blob/master/HACKING.rst#keystone-specific-commandments15:02
YorikSarmorganfainberg: ' is for constants and stuff, " is for text :)15:02
YorikSarmorganfainberg: Oh...15:02
morganfainbergYorikSar, """ is for docstrings, everywhere else (unless there is a reason to use ") should be '15:03
morganfainbergYorikSar, for readability if you have apostophes or similar it's ok to use " but we try and keep quotation consistent15:04
YorikSarmorganfainberg: I wonder what brought to writing this down in the doc...15:04
YorikSarmorganfainberg: Why don't use ''' for docstrings?15:04
morganfainbergYorikSar, i think that is actually a broader python ism15:04
*** amirosh has quit IRC15:04
morganfainbergYorikSar, http://legacy.python.org/dev/peps/pep-0257/15:05
YorikSarmorganfainberg: Huh...15:06
YorikSarmorganfainberg: Ok, that's the longest conversation I ever had about choosing between ' and " :)15:06
morganfainberghehe15:07
morganfainbergayoung, dolphm, https://review.openstack.org/#/c/119673/ possible solution for bug 1328067 but need a pair of eyes to know if that is breaking api compatibility.15:08
uvirtbotmorganfainberg: Error: Could not parse data returned by Launchpad: The read operation timed out15:08
morganfainberguvirtbot, poor poor bot,15:09
uvirtbotmorganfainberg: Error: "poor" is not a valid command.15:09
ayoungmorganfainberg, sorry, can't context switch....I'm writing Error handling Macros in C for python_kerberos....15:09
dolphmmorganfainberg: yeah, the ID certainly needs to be in the response, but you can persist it however youw ant15:09
morganfainbergdolphm, the issue is PKI tokens decoded will no longer contain the id15:10
morganfainbergdolphm, but live-validation would still contain the id (normal response)15:10
YorikSarmorganfainberg: About config options... Won't people hit us if we add some config args this late in the cycle?..15:10
morganfainbergdolphm, and issue body15:10
morganfainbergYorikSar, keystonemiddleware is a bit separate from the named releases, and it shouldn't matter if we aren't changing current option defaults15:11
dolphmmorganfainberg: so which responses are missing the ID then - on token issuance?15:11
morganfainbergYorikSar, this is something that should be configurable when we release it.15:11
morganfainbergdolphm, cms token decode15:11
YorikSarmorganfainberg: Oh, ok then. I'll add all args there are in Keystone patch.15:11
morganfainbergYorikSar, yeah middleware is a bit easier in some regards than Keystone server15:12
* YorikSar wonders how that sentence should've looked like in English...15:12
morganfainbergYorikSar, close enough ;)15:12
YorikSarmorganfainberg: So that's a backdoor, right? Whatever we can't do in Keystone we do in middleware and then just import in Keystone ;)15:12
morganfainbergYorikSar, not really. auth_token doesn't get imported by keystone15:13
*** jorge_munoz has joined #openstack-keystone15:13
morganfainbergYorikSar auth_token is used by other services.15:13
*** aix has quit IRC15:13
YorikSarmorganfainberg: Huh?.. But how we'll reuse pool from keystonemiddleware in Keystone then?15:14
morganfainbergYorikSar so the options you're adding to keystonemiddleware are available to deploying nova.15:14
*** cjellick has joined #openstack-keystone15:14
YorikSarmorganfainberg: Yeah, they'll all be in paste.ini iiuc15:14
*** cjellick has quit IRC15:15
*** aix has joined #openstack-keystone15:15
morganfainbergYorikSar, lets talk about that. i think we are just going to need the code in both places for now. in K we can split the pool code into it's own package15:15
*** diegows has quit IRC15:15
*** stevemar has joined #openstack-keystone15:15
*** cjellick has joined #openstack-keystone15:15
morganfainbergwe just *cant* do it for J because we're past the dependency freeze15:15
YorikSarmorganfainberg: Actually, there is keystonemiddleware in Keystone's requirements.txt, so we can reuse it...15:15
morganfainbergYorikSar, the only reason for that is because of some compat stuff for moving middleware, i'm not convinced we should make it a public interface in middleware.15:16
morganfainbergYorikSar, and if it isn't a public interface in middleware, keystone should not depend on it15:16
*** afazekas_ has quit IRC15:17
morganfainbergYorikSar, in short, i don't *want* people to use the pool from keystonemiddleware long term. if keystone depends on it we can't ever remove it.15:17
morganfainbergYorikSar, well eventually we might but as long as someone is using Juno Keystone, the middleware wont be able to remove that code.15:17
YorikSarmorganfainberg: If we won't have keystonemiddleware remove from requirements we can safely use a small piece of 'private' API from Keystone, just for one cycle...15:18
morganfainbergYorikSar, no, because middleware can/will be updated in the future and used by people deploying Juno15:18
YorikSarmorganfainberg: Oh, but if we do so, we won't be able to upgrate keystonemiddleware, I get it.15:19
morganfainbergYorikSar, yep15:19
morganfainbergYorikSar, so lets just put the code in both places until next cycle.15:19
YorikSarmorganfainberg: That... Makes me sad. Another copypaste?15:19
morganfainbergYorikSar, sadly15:19
morganfainbergYorikSar, but it's less debt to cleanup / carry forward than making the kyestonemiddleware dependency more permanent15:20
YorikSarmorganfainberg: Yeah. Btw, will we be able to switch to external lib in stable/juno?15:20
morganfainbergYorikSar, no15:20
morganfainbergdolphm, ah need to add the token_ids back in during validate of PKI, looks like i missed that.15:21
ayoungmorganfainberg, yeah...don't do that15:21
morganfainbergayoung, ?15:21
ayoungremove "placeholder"15:22
YorikSarmorganfainberg: Will _MemcachedCachePool ok as class name instead of _RealCachePool?15:22
ayoungmorganfainberg, maybe change the string?15:22
morganfainbergYorikSar, like i said that was a NIT, you don't need to change it.15:22
morganfainbergYorikSar, it was a "i don't like this name,but eh, i wont block this patch if you don't change it"15:22
morganfainbergYorikSar, :)15:22
ayoungsomething like "A token ID here is impossible due to the incompleteness theorem"15:22
YorikSarmorganfainberg: I don't like _RealCachePool too, just didn't want to spend too much time thinking about it.15:22
ayoungor "blame Godel"  for short?15:23
morganfainbergayoung, there is no reason to put anything there - we already override it and put other things in on token body response15:23
ayoungI don;t want to change the body of the token, as then the result will not match the hash15:23
dstanekcan we mark https://bugs.launchpad.net/keystone/+bug/1262057 as won't fix since the xml middleware is deprecated?15:23
uvirtbotLaunchpad bug 1262057 in keystone "XML middleware will try to convert everything even if it's not json" [Undecided,Incomplete]15:23
morganfainbergayoung, too late, we do it already15:24
ayoungmorganfainberg, story of Keystone, isn't it?15:24
ayoung"too late, we need to live with this decision"15:24
morganfainbergayoung, issue_v2_token, issues token, replaces id in body, we return that modified body15:24
morganfainbergayoung, thankfully v3 tokens do not have that issue.15:24
ayoungyeah...15:24
ayoungmorganfainberg, I wrote that code... I've repressed those memories15:25
ayoungdimly recall it being needed by something15:25
morganfainbergif i could get away with it, i would only issue v3 tokens.15:25
morganfainbergayoung, mostly it is needed internal to keystone, moving to the tokenmodel solved a lot of that15:25
morganfainbergayoung, and a fix to middleware will solve any chance of an issue of it being passed to the underlying services behind the middleware15:26
morganfainberg(mostly not used)15:27
ayoungmorganfainberg, you want to bet on that?  There are Java implementations that consume Keystone out there....15:27
ayoungTHink we can really just change this?15:27
morganfainbergayoung, this is why it is marked -2 and needed other eyes on it.15:27
morganfainbergayoung, to the java impl consume PKI or uuid?15:27
morganfainbergayoung, i honestly don't know if we can fix it, but this is a stab at fixing it before we say "nope wont fix"15:28
ayoungheh15:30
ayoungthe Java is just at reminder that we can't just fix things in middleware.15:31
*** gokrokve_ has joined #openstack-keystone15:31
morganfainbergayoung, this is tagged as a juno rc1 bug. so need to figure out if we want to say "wont fix" and the fix will be when v2 tokens are dropped15:32
morganfainbergi am inclined to say the answer is wont fix.15:33
ayoungmorganfainberg, how bad is the bug? Is ita acutally breaking something, or is it just people going "why does my token_id say placeholder?"15:33
morganfainbergayoung, well, heat at least was trying to extract the token id from the token body15:33
ayoungyeah...they worked around it a long while ago15:34
ayoungbut....15:34
morganfainbergayoung, it is invalid data in the token.15:34
ayoungdepends on how you squint at tit15:34
ayoungat it15:34
morganfainbergayoung, so i'd say the bug is ugly, but may be something we need to fix.15:34
morganfainbergerm don't need to fix15:34
ayoungthe token_id doesn't belong inside the token itself15:34
*** gokrokve has quit IRC15:34
ayoungbut we didn';t write the format, we inherited it...15:35
morganfainbergayoung, correct.15:35
morganfainbergayoung, like i said, ugly, but maybe nothing we need/can fix15:35
ayoungyep15:36
morganfainbergayoung, it is invalid data (proof based on the fact that we replace the data and return something that wont hash to the same id)15:36
ayoungsure15:36
morganfainbergayoung, so i'm 100% content to abandon and mark the bug as wont fix/cant fix. just needed to do the due diligence of "can this be fixed before we bail on it"15:37
morganfainbergand the code change was minimal.15:37
ayoungmorganfainberg, heh, if Horizon used that value instead of hashing themselves, we probably would have a better story now, wouldn't we15:37
morganfainberglol15:37
*** mikedillion has joined #openstack-keystone15:40
*** rodrigods has joined #openstack-keystone15:42
*** bvandenh has quit IRC15:42
amakarovmorganfainberg, greetings, i have a bug fix for review, but it has low priority - what to do next? I'm not so familiar with workflow yet, are low-priority bug fixes ignored for now, near the deadline? :)15:42
morganfainbergamakarov, depends on the bug.15:42
morganfainbergamakarov, low priority fixes doesn't mean we don't want them.15:42
morganfainbergamakarov, often times extra low prio/wishlist bugs make their way in even towards the end because the code is written and the benefit of fixing the bug is absolutely there.15:43
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Refactor LDAP backend using context manager for connection  https://review.openstack.org/11813815:44
amakarovmorganfainberg, so I just leave my patch there and take another one, or have to ask somebody to review it? I don't want to be noisy :)15:47
morganfainbergamakarov, this one: https://review.openstack.org/#/c/118590/ ?15:47
morganfainbergamakarov, there is no harm in asking in IRC for reviews :)15:48
openstackgerritYuriy Taraday proposed a change to openstack/keystonemiddleware: Add a pool of memcached clients  https://review.openstack.org/11977415:49
YorikSarmorganfainberg: gtg, will be back later today. I've added config options there ^15:49
morganfainbergYorikSar, thank you very much!15:49
morganfainbergamakarov, and i think it is reasonable to expect some reviews on that code in the near term. like i said, the code is there and fixing bugs isn't a bad thing :)15:50
*** jaosorior has quit IRC15:52
amakarovmorganfainberg, point taken, thanks :) Yes it was my very own bug to try contribution :) There is a malfunctioning feature covered with a wrong test. I hope it may be somewhat useful.15:52
morganfainbergamakarov, so i'll provide some immidiate comment feedback on the patch, some things i'm seeing (e.g. unrelated whitespace changes) that will need to be else where. i've also tagged nkinder on the review since he has helped a lot on LDAP related stuff.15:53
nkindermorganfainberg, amakarov: I'll take a look at it a bit later today.15:54
amakarovnkinder, thanks - I'm new to opensource and any feedback would be vary valuable for me now15:55
morganfainbergamakarov well welcome then!15:57
*** stevemar has quit IRC15:58
*** stevemar has joined #openstack-keystone15:59
*** gyee has joined #openstack-keystone15:59
*** mikedillion has quit IRC16:04
*** BAKfr has quit IRC16:07
*** andreaf is now known as andreaf_16:09
*** wwriverrat1 has joined #openstack-keystone16:09
*** wwriverrat1 has left #openstack-keystone16:09
*** mikedillion has joined #openstack-keystone16:09
*** wwriverrat has quit IRC16:11
*** rushiagr is now known as rushiagr_away16:14
*** samuelmz has joined #openstack-keystone16:17
*** samuelmz has quit IRC16:27
*** rodrigods has quit IRC16:27
*** gokrokve has joined #openstack-keystone16:28
*** mikedillion has quit IRC16:28
openstackgerritBrad Topol proposed a change to openstack/keystone: Clean up federated identity audit code  https://review.openstack.org/11980416:29
*** samuelmz has joined #openstack-keystone16:30
*** mikedillion has joined #openstack-keystone16:30
*** gokrokve_ has quit IRC16:31
*** gokrokve has quit IRC16:32
openstackgerritBrant Knudson proposed a change to openstack/keystone: Refactor keystone-all and http/keystone  https://review.openstack.org/6227516:39
*** wwriverrat1 has joined #openstack-keystone16:42
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/11162016:49
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/11914216:49
*** gokrokve has joined #openstack-keystone16:53
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/11625516:54
openstackgerritAlexander Makarov proposed a change to openstack/keystone: LDAP additional attribute mappings validation  https://review.openstack.org/11859016:54
*** sigmavirus24 is now known as sigmavirus24_awa17:00
*** marcoemorais has joined #openstack-keystone17:00
*** jsavak has joined #openstack-keystone17:02
*** rkofman has quit IRC17:03
*** rkofman has joined #openstack-keystone17:04
*** joesavak has quit IRC17:04
*** diegows has joined #openstack-keystone17:05
*** rushiagr_away is now known as rushiagr17:06
*** amakarov has quit IRC17:09
*** htruta has joined #openstack-keystone17:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds pipeline hints to the example paste config  https://review.openstack.org/11982717:10
*** gyee has quit IRC17:12
*** amirosh has joined #openstack-keystone17:12
Morgan_Hmm irc cloud is pretty nice.17:13
*** harlowja_away is now known as harlowja17:14
*** jaosorior has joined #openstack-keystone17:18
*** joesavak has joined #openstack-keystone17:24
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds hint about filter placement to extension docs  https://review.openstack.org/11983417:24
stevemardstanek, thanks17:25
stevemardstanek, do you mind adding your last patch to this chain? https://review.openstack.org/#/c/119159/17:27
*** jsavak has quit IRC17:27
dstanekhey stevemar17:28
stevemaror review the chain :) and i'll rebase your stuff later :)17:28
dstanekstevemar: yeah i can based that on yours17:28
Morgan_dstanek: I'm going to be building an experimental functional gate job that will let us live test against ldap. I'll bug you when it's time to start migrating tests to functional (looking at the restful cases). If you have ideas there.17:28
dstanekMorgan_: sounds good17:29
*** gyee has joined #openstack-keystone17:29
openstackgerritDolph Mathews proposed a change to openstack/keystone: correct typos  https://review.openstack.org/11983817:30
openstackgerritDolph Mathews proposed a change to openstack/identity-api: fix a/an typos  https://review.openstack.org/11983917:32
openstackgerritDolph Mathews proposed a change to openstack/python-keystoneclient: fix typos  https://review.openstack.org/11984117:34
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add a functional tests for role assignments  https://review.openstack.org/11984317:38
*** ayoung has quit IRC17:41
*** amirosh has quit IRC17:41
*** amirosh has joined #openstack-keystone17:42
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add a functional tests for role assignments  https://review.openstack.org/11984317:44
*** gyee has quit IRC17:46
*** amirosh has quit IRC17:47
samuelmzhenrynash, ping17:52
*** ayoung has joined #openstack-keystone17:52
henrynashsamuelmz: hi17:52
samuelmzhenrynash, hi17:53
samuelmzhenrynash, concerning your comment at https://review.openstack.org/#/c/116682/4/keystone/assignment/controllers.py17:53
samuelmzhenrynash, you are proposing to call list_role_assignments on the backend by passing user_id, group_id, project_id and domain_id, right?17:54
samuelmzhenrynash, so at the backend (SQL in this example), we should do something like this (http://paste.openstack.org/show/108406/)17:55
henrynashsamuelmz: or you pass add the assignment type to what you pass into the backend17:56
samuelmzhenrynash, the assignmenttype representation is specific to backend17:57
samuelmzhenrynash, for sql we have class AssignmentType: USER_PROJECT = 'UserProject' ...17:57
dolphmdstanek: https://review.openstack.org/#/c/114305/ ??17:57
samuelmzhenrynash, but we could have an AssignmentType class at controller class .. and then every backend would use it17:58
henrynashsamuelmz: so yes, that’s the tradoff…but I’d actually argue that assignment type is a concept that is not backend specific…teh fact that we happen to store it in an SQL table is, hwoever, specific17:58
lbragstadhenrynash: fyi I tried adding a test for the user-role-assignment bug you're subscribed to17:58
dstanekdolphm: that's based on the script i use to do the updates17:59
*** wwriverrat1 has left #openstack-keystone17:59
dolphmdstanek: what does your script add to oslo's thing?18:00
henrynashsamuelmz: but you can do it eitehr way…18:00
samuelmzhenrynash, hm.. +1 for putting this in the controller18:00
samuelmzhenrynash, but how would we represent this? like we're doing in the sql?18:00
dstanekdolphm: i just saw your comment18:00
henrynashsamuelmz: you mean, how would you represent it in other backend (e.g. LDAP), or how would you represent this in the controller?18:01
dstanekdolphm: it actually uses olso's update, but does all the git stuff to have bknudson style comments in the commit message; it runs update, figures out what changed and then commits18:01
samuelmzhenrynash, if so, we should convert UserProject to ['user','project'] to create metadata-user-project on kvs ...18:01
henrynashlbragstad: and did it dow thie issue?18:01
samuelmzhenrynash, yes, that's the point18:01
lbragstadhenrynash: I wasn't able to recreate it using v318:02
henrynashsamuelmz: yes, you would map AssignmentType to some local storage mechanism that was appropriate18:02
henrynashsamuelmz: (but don’t worry about kvs backend, we deleting it in Kilo-1 :-) )18:03
samuelmzhenrynash, ok :)18:03
samuelmzhenrynash, and what about ldap?18:03
henrynashlbragstad: ok..thanks for info18:03
henrynashsamuelmz: well, It’s mapped into the oobject types and tree I guess18:04
*** raildo has joined #openstack-keystone18:04
samuelmzhenrynash, yes, I mean.. do you have plans to delete ldap?18:04
henrynashsamulemz: NO!18:04
samuelmzhenrynash, :-)18:04
lbragstadhenrynash: no problem, I left a paste of my test and the test up for review in the bug report.18:05
samuelmzhenrynash, I asked this because I saw we could use ldap enabling federation18:05
henrynashsamuelmz: so I’m not saying defintley expose AssignmentType….but just consider that as an option….18:05
henrynashsamuelmz: so, in the long run, yes, I agree that the ldap identity driver will go away…but it’s probably a long time18:06
dolphmdstanek: lol sounds like it's worth reviewing then :)18:06
samuelmzhenrynash, I think we could keep the way in which it's being done18:06
samuelmzhenrynash, I mean  exposing or not  AssignmentType is another refactoring,18:07
henrynashsamuelmz: ok, no18:07
raildoI think I have the same doubt that samuelmz18:07
henrynashsamuelmz:….I meant: OK, np18:07
dstanekdolphm: i had to ditch the old VM where i kept this locally, so i pushed to gerrit so i could easily share with my new VM18:07
samuelmzhenrynash, cool :) I dont like the idea of mixing lots of things in a single patch18:07
samuelmzhenrynash, thanks18:07
henrynashsamuelmz: yw18:07
*** sigmavirus24_awa is now known as sigmavirus2418:09
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds pipeline hints to the example paste config  https://review.openstack.org/11982718:15
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds hint about filter placement to extension docs  https://review.openstack.org/11983418:15
dstanekstevemar: ^18:15
stevemardstanek, :D thanks !18:16
*** david-lyle has quit IRC18:17
*** david-lyle has joined #openstack-keystone18:20
*** aix has quit IRC18:21
dolphmdstanek: can you file a bug for this and target rc1? https://review.openstack.org/#/c/118640/18:22
dolphmdstanek: just want to make sure that lands18:23
dolphmdstanek: and evaluate it for backporting18:23
openstackgerritA change was merged to openstack/identity-api: fix a/an typos  https://review.openstack.org/11983918:24
*** cjellick has quit IRC18:26
*** cjellick has joined #openstack-keystone18:26
topoldolphm, you there18:28
openstackgerritDolph Mathews proposed a change to openstack/keystone: Enable filtering of services by name  https://review.openstack.org/11090418:28
dolphmtopol: o/18:28
topoldolph, so for auditing of federated identity we took out the pending because we felt it was unnecessary. I noticed for standards authenticate we still have a pending audit record. Should I submit a patch to pull that out as well so that we are consistent?18:30
*** vhoward has left #openstack-keystone18:30
*** afaranha has joined #openstack-keystone18:30
topoldolphm^18:30
dolphmtopol: didn't we pull it out of federated because there was no work being done between PENDING and the result?18:30
afaranhadstanek: Hello, I'm reviewing a patch that you submited and in line 34: https://review.openstack.org/#/c/119834/2/doc/source/extensions/oauth1.rst you put an extra new line.18:31
*** rushiagr is now known as rushiagr_away18:32
topoldolphm, I thought the reasoning was that pending was only for long running operations and we felt the fed authenticate was quick18:33
topollong running = operation they may take a lot of time (like starting a VM)18:33
dolphmtopol: that's right -- so local auth wouldn't be long running either18:34
dolphmtopol: +1 for removing it then18:34
topoldolphm, that was my thought. So Iwas gonna submit a patch to remove it18:34
topoldolphm, K, I assume it needs a bug as well since it is something external that someone may notice a difference18:35
dolphmtopol: ++18:35
dstanekafaranha: i did that on purpose so that it matches the other extension docs18:35
topoldolphm, Im on it. Thanks18:35
afaranhadstanek: Do you mean keep the pattern?18:38
*** edmondsw has joined #openstack-keystone18:44
*** mikedillion has quit IRC18:49
dolphmmorganfainberg: this review fixes a "typo" in one of your comments, but i don't think it was a typo. since you wrote it, you be the judge: https://review.openstack.org/#/c/117902/18:49
morganfainbergdolphm, that is a typo, but not the one that is being fix18:50
morganfainbergdolphm, should be 'in a sane manner' not in same manner18:50
*** openstackgerrit has quit IRC18:51
dolphmmorganfainberg: thank you!18:52
morganfainbergdolphm, commented on the patch as well.18:52
*** rodrigods has joined #openstack-keystone18:53
*** rodrigods has quit IRC18:53
*** rodrigods has joined #openstack-keystone18:53
morganfainbergdolphm, posted a version that fixes the correct typo18:53
morganfainbergdolphm, left the original author though.18:53
morganfainbergdolphm, so patchset 2.18:54
dolphmmorganfainberg: +2. there's another review out there that rewrites that bit of the comment18:54
morganfainbergah18:54
dolphmi don't know what's going on with all the trivial comment changes18:54
morganfainbergrace to rebase18:54
*** jorge_munoz has quit IRC18:55
*** jorge_munoz has joined #openstack-keystone18:56
morganfainbergLOL https://bugs.launchpad.net/keystone/+bug/996912 wow19:01
uvirtbotLaunchpad bug 996912 in keystone "Wrong exception caught for admin checking in ec2" [Medium,Triaged]19:01
morganfainbergthat has been around for a while19:01
*** mikedillion has joined #openstack-keystone19:04
*** openstackgerrit has joined #openstack-keystone19:06
*** openstackgerrit has quit IRC19:06
*** openstackgerrit has joined #openstack-keystone19:06
*** marcoemorais has quit IRC19:09
*** marcoemorais has joined #openstack-keystone19:10
openstackgerritDolph Mathews proposed a change to openstack/keystone: Updates package comment to be more accurate.  https://review.openstack.org/11432619:14
bknudsonwhat is keystone-manage saml_idp_metadata ?19:20
dolphmdstanek: this one is waiting for you https://review.openstack.org/#/c/117523/19:22
*** marcoemorais has quit IRC19:22
dolphmbknudson: it signs a bunch of keystone.conf options as a saml doc so keystone can later serve it as a static file, basically19:22
dolphmmarekd: stevemar: need docs ^19:22
*** marcoemorais has joined #openstack-keystone19:23
bknudsonok19:23
stevemardolphm, on it19:23
*** ukalifon1 has quit IRC19:24
bknudsonthere's a docstring in the command handler. I'll use that in the man page.19:24
stevemarbknudson, dolphm dstanek i have about 5 or so doc related changes, can i get a review for them? It's getting a PITA to rebase if I want to add new docs for k2k federation19:26
joesavakstevemar - you rock.19:26
openstackgerritBrant Knudson proposed a change to openstack/keystone: Update man pages  https://review.openstack.org/11988819:32
dstanekafaranha: since i was changing that line and it was too long i decided to break it up19:35
dstanekdolphm: neat, i'll take a look19:35
dstanekstevemar: sure.19:35
dolphmk2k doc series starts here https://review.openstack.org/#/c/118532/19:36
*** amcrn has joined #openstack-keystone19:40
*** wwriverrat1 has joined #openstack-keystone19:41
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update paste pipelines in configuration docs  https://review.openstack.org/11853319:51
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update the revocation configuration docs  https://review.openstack.org/11853619:51
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update the revocation configuration docs  https://review.openstack.org/11853619:55
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Make the extension docs a top level entry in the landing page  https://review.openstack.org/11915919:55
stevemardolphm is padding his review stats20:01
stevemar-2 all the things!20:01
dolphmstevemar: pretty much20:01
*** wwriverrat1 has left #openstack-keystone20:01
dolphmstevemar: ONLY TEN REVIEWS TO GO UNTIL I CAN HAVE SANITY AGAIN20:01
dolphmthis has taken all day20:01
*** gyee has joined #openstack-keystone20:03
dstanekdolphm: why do you not like this one? https://review.openstack.org/#/c/11499720:07
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Make the extension docs a top level entry in the landing page  https://review.openstack.org/11915920:08
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Adds pipeline hints to the example paste config  https://review.openstack.org/11982720:08
dolphmdstanek: oh, hrm. probably a mistake, let me review20:09
dolphmalso probably not the only mistake i made20:09
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Adds hint about filter placement to extension docs  https://review.openstack.org/11983420:09
dstanekdolphm: i'm tearing into why i don't like the details right now, but i think if it's fixed up it will be good to have20:09
openstackgerritguang-yee proposed a change to openstack/keystone: Use id attribute map for read-only LDAP  https://review.openstack.org/11765820:10
dstanekwe made a decision to only validate v3 right? i don't remember why, but i remember reading that from somewhere20:11
*** tim_r has quit IRC20:13
*** tim__r has joined #openstack-keystone20:13
dolphmlbragstad: ^20:15
bknudsondo we have validation of the extensions?20:15
dstanekdolphm: lbragstad: i'm thinking because v2 is deprecated..maybe?20:15
lbragstadbknudson: not yet, core api has validation20:16
*** arunkant has quit IRC20:17
lbragstaddstanek: I believe so20:17
dstaneklbragstad: not in keystone.identity though20:17
lbragstaddstanek: but I don't think I could dig up the conversation20:17
lbragstadright20:17
lbragstadkeystone core api - identity20:17
dstanek= good times!20:18
gyeebknudson, nkinder, can you guys take another look? https://review.openstack.org/#/c/117658/20:18
nkindergyee: yep, will do20:19
nkindergyee: may take me a bit, as I'm heading into a meeting in 10 minutes.20:19
gyeenkinder, no problem, thanks!20:19
*** arunkant has joined #openstack-keystone20:20
*** Haneef has joined #openstack-keystone20:20
dstaneklbragstad: https://review.openstack.org/#/c/114997 adds some user validation to identity20:22
nkindergyee: ok, I got to it early...20:22
Haneefayoung:  I have an idea  on how to use v3 polcy file without breaking backward compatability.  Can I assign https://blueprints.launchpad.net/keystone/+spec/update-policy-to-cloud to myself and work on it?  I don't want to create one more blueprint20:22
nkindergyee: changes look good, but there are some additional tests that I think should be added20:23
nkindergyee: I mentioned them in my comment for patch 7 (not inline)20:23
ayoungHaneef, have you seen henrynash 's work on assigning policy to endpoint this release?20:23
Haneefayoung:  ok. I will have a look at it and get back to you20:24
gyeenkinker, k, I'll see if I can add them20:26
*** r-daneel has quit IRC20:27
*** r-daneel has joined #openstack-keystone20:28
openstackgerritA change was merged to openstack/keystone: Avoid conversion of binary LDAP values  https://review.openstack.org/11945720:38
openstackgerritBrant Knudson proposed a change to openstack/keystone: Remove trailing space from string  https://review.openstack.org/11990520:42
*** HenryG has quit IRC20:48
lbragstaddstanek: I saw that a while back, shouldn't be too bad to refactor now that the rest of the validation stuff for the core api is in20:49
dstaneklbragstad: probably only take a few minutes to fix my issues - i'm not going to do it right now to give the author a chance20:51
lbragstaddstanek: yep, that's a good plan20:52
dstaneklbragstad: i'll probably send an email in a few - because if would be nice to have that fixed up so that we can validate other identity calls20:52
lbragstad++20:53
morganfainbergdstanek, ping - actually sec.20:57
dstanekmorganfainberg: pong20:57
morganfainberghaha so the bug about things caching forever20:57
morganfainberginvalid20:57
morganfainbergi think20:58
morganfainberg2x checking20:58
*** marekd has quit IRC20:59
morganfainbergdstanek, yeah already have an override in the [cache] section21:00
*** HenryG has joined #openstack-keystone21:00
morganfainbergdstanek, https://github.com/openstack/keystone/blob/master/keystone/common/config.py#L293-L297 and https://bitbucket.org/zzzeek/dogpile.cache/src/1c753914b335b4391bc5847a87b7c52ca81c2bc6/dogpile/cache/region.py?at=master#cl-96021:01
morganfainbergdstanek, we can probably mark this https://bugs.launchpad.net/keystone/+bug/1355919 as invalid21:02
uvirtbotLaunchpad bug 1355919 in keystone "By default when caching is enabled, objects will be cached forever" [Medium,In progress]21:02
openstackgerritBrant Knudson proposed a change to openstack/keystone: Move test_binary_attribute_values  https://review.openstack.org/11992821:03
*** stevemar has quit IRC21:03
*** stevemar has joined #openstack-keystone21:04
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove unused cache functions from token.core  https://review.openstack.org/11967921:05
stevemardstanek, do you have a suggestion for the os-revoke stuff? you're right, it's only for icehouse or newer21:05
*** amcrn has quit IRC21:05
*** topol has quit IRC21:06
*** topol has joined #openstack-keystone21:06
dstanekmorganfainberg: we don't use that default do we?21:08
dstanekmorganfainberg: that's what i was adding here: https://review.openstack.org/#/c/113586/4/keystone/assignment/core.py21:08
morganfainbergdstanek, that is the default it is added to the cache region config21:08
dstanekstevemar: maybe just something about is being the new default in the example config?21:08
morganfainbergdstanek, https://github.com/openstack/keystone/blob/master/keystone/common/cache/core.py#L9121:09
morganfainbergwhich is used if expiration_time is none on any calls in the cache region, including the decorators21:09
*** arborism has joined #openstack-keystone21:10
*** arborism is now known as amcrn21:11
dstanekmorganfainberg: hmmm...where does dogpile.cache use that default value?21:12
dstanekmorganfainberg: the bug is probably invalid if dogpile.cache is taking care of it, but i think the code should be merged to make it explicit21:13
morganfainbergdstanek, i want to get out of the logic being in keystone instead move it more towards dogpile21:14
dstanekthere is a lot of indirection when using dogpile.cache and i think this will come up again21:14
morganfainbergdstanek, if at all possible.21:14
dstanekthe logic of which config values to use?21:14
morganfainbergdstanek, i think if we just made our cache layer use a get_expiration_fn that had reasonable docstring saying "dogpile enforces the default" would be sufficient21:15
*** edmondsw has quit IRC21:15
morganfainbergotherwise it is *pointless* to have the default handled like dogpile is meant to21:15
morganfainbergso we're always overriding it.21:15
morganfainbergsimilar to how the should_cache_fn works21:15
*** marcoemorais has quit IRC21:17
dstanekmorganfainberg: you just saying to remove the " or CONF.cache_time" from our functions?21:17
morganfainbergdstanek, no, use the same way we do should_cache_fn(<section>) instead of lambdas21:18
morganfainberghttps://github.com/openstack/keystone/blob/249d83529af0c746c6980aa0dbd2287bc8de345e/keystone/common/cache/core.py#L15521:18
morganfainberghave a docstring that says "the default is set with XXX option on the region"21:18
morganfainbergand use that instead of the lambdas/separate functions in each module21:18
dstanekmorganfainberg: that would work21:20
*** jdennis has quit IRC21:20
morganfainbergdstanek, i'll post that up, i'm about 50% of the way there already21:20
stevemardstanek, what about this? http://paste.openstack.org/show/108480/21:28
*** david-lyle has quit IRC21:28
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes formatting error in debug log statement  https://review.openstack.org/11864021:29
dstanekdolphm, bknudson: i changed to commit message to add a reference to the bug i just created ^21:30
dstaneks/to/the/21:30
bknudsondstanek: who was asking for a bug?21:31
bknudsonoh, it actually fails?21:31
dstanekbknudson: dolphm asked earlier21:31
bknudsondstanek: it doesn't actually fail?21:31
dstanekbknudson: yes, i was getting a typeerror21:32
dstanekstevemar: i think that sounds good now21:32
bknudsondstanek: well, now I want a unit test!21:32
dstanekbknudson: i can add one :-)21:32
bknudsondstanek: LOG.debug raises if there's an extra argument?21:33
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update the revocation configuration docs  https://review.openstack.org/11853621:33
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Make the extension docs a top level entry in the landing page  https://review.openstack.org/11915921:33
stevemardstanek, ^21:34
stevemarand if you could hit the rebase button on your changes :)21:34
dstanekbknudson: http://paste.openstack.org/show/108488/21:35
dstanekthat's basically what i saw21:35
bknudsonok. I'm surprised we don't see that all the time.21:36
bknudsonso that does show that the code isn't covered by unit tests21:36
dstanekbknudson: or maybe that it doesn't run at a debug level?21:42
bknudsondstanek: the coverage report shows that it is covered... so maybe it's not at debug?21:44
*** mikedillion has quit IRC21:46
*** dims_ has quit IRC21:48
*** dims has joined #openstack-keystone21:49
*** dims has quit IRC21:53
openstackgerritBrant Knudson proposed a change to openstack/keystone: Move unit tests from test_backend_ldap  https://review.openstack.org/11992821:55
*** dims has joined #openstack-keystone21:56
bknudsonp LOG.isEnabledFor(logging.DEBUG) -- True ... so it should be logged.22:01
*** dims has quit IRC22:03
*** jasondotstar has quit IRC22:03
bknudsondstanek: LOG.debug() must just print it out rather than propagating the exception.22:03
*** dims has joined #openstack-keystone22:03
*** marcoemorais has joined #openstack-keystone22:03
bknudsonhttps://docs.python.org/2/library/logging.html#logging.Handler.handleError22:06
*** dims has quit IRC22:08
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Make the default cache time more explicit in code  https://review.openstack.org/11358622:10
morganfainbergdstanek, ^22:10
bknudsonapparently you're supposed to set logging.raiseExceptions to False in production.22:10
*** stevemar has quit IRC22:12
*** miqui has joined #openstack-keystone22:13
rm_workCan you guys tell me what you think of this workflow? This is the current proposed workflow for Neutron-LBaaS --> Keystone/Barbican interaction: http://i.imgur.com/zVq3Iut.png22:15
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Make the default cache time more explicit in code  https://review.openstack.org/11358622:17
*** topol has quit IRC22:23
*** jorge_munoz has quit IRC22:24
*** amcrn_ has joined #openstack-keystone22:30
*** amcrn has quit IRC22:32
openstackgerritBrant Knudson proposed a change to openstack/keystone: Tests raise exception if logging problem  https://review.openstack.org/11994622:35
rm_workayoung / dolphm: So, I think I had talked to you guys in the past about the plan to use Trusts and Impersonation to interface between LBaaS and Barbican -- can you take a look at this (fairly simplistic) workflow and tell me if it makes sense to you? http://i.imgur.com/GQlXnbv.png22:36
*** gokrokve has quit IRC22:48
*** bknudson has quit IRC22:49
*** jaosorior has quit IRC22:52
*** marcoemorais has quit IRC22:55
*** marcoemorais has joined #openstack-keystone22:55
*** marcoemorais has quit IRC22:56
*** joesavak has quit IRC22:56
*** marcoemorais has joined #openstack-keystone22:56
nkinderrm_work: I know I chatted with you before about that22:59
nkinderrm_work: the diagram is missing some info about how the trust is used22:59
nkinderrm_work: there are two distinct operations - creation of a trust and execution of a trust22:59
rm_workyeah23:00
rm_workok so #4 is the creation (I did say "23:00
rm_workok so #4 is the creation (I did say "create a Trust")23:00
rm_work#5 is the execution of the Trust23:00
rm_workI assumed executing the trust still requires Impersonation?23:00
nkinderrm_work: yeah, but is the flow always "create and execute" at the same time?23:00
rm_worknkinder: essentially23:01
nkinderrm_work: or can those be disjointed?23:01
rm_workwell23:01
*** amcrn_ is now known as amcrn23:01
rm_workit's more like UPSERT23:01
rm_workCreate Trust if not already created23:01
nkinderrm_work: if they happen at the same time, you might as well just use the users ticket directly against barbican to get the SSL cert/key23:01
rm_worknkinder: in THIS scenario it is in-line23:01
rm_workbut then we will need to skip directly to step #5 in the future23:01
nkinderok, if there is possibly a trust already and you execute it at some point in the future, then the trust makes sense23:02
rm_workwith no user interaction23:02
rm_workso this is the initial setup of the LB23:02
nkinderrm_work: ok, so in the diagram I would have LBaaS->Keystone (create trust)23:02
nkinderthen LBaaS->Keystone (execute trust)23:02
rm_workhow exactly does the trust "execution" work?23:02
nkinderthen LBaaS->Barbican (forward trust token)23:02
rm_workah ok23:02
nkinderrm_work: it's just like getting a token23:02
rm_workit's a Keystone token GET23:03
rm_workgot it23:03
openstackgerritguang-yee proposed a change to openstack/keystone: Use id attribute map for read-only LDAP  https://review.openstack.org/11765823:03
nkinderbut it's a different resource23:03
nkinderyeah, more or less23:03
nkinderyou pass it a trust id to execute23:03
rm_workk23:03
*** marcoemorais1 has joined #openstack-keystone23:04
nkinderrm_work: maybe calling out "create trust if it doesn't exist" would make it more clear too just to show that the creation is optional23:04
rm_workk23:04
rm_worknkinder: "5. LBaaS executes the Trust with Keystone to receive an Impersonation Key" ?23:06
rm_workdoes that make sense?23:06
*** marcoemorais1 has quit IRC23:06
rm_workor am I still getting it wrong23:06
rm_workI know there is a line between Trusts and Impersonation but I am not exactly sure where it leis23:06
*** marcoemorais1 has joined #openstack-keystone23:06
rm_work*where it is23:06
nkinders/impersonation key/trust token/23:06
rm_workok23:06
*** dguitarbite has joined #openstack-keystone23:07
rm_workso with the Trust token, when we hit Barbican, we'll be in the user's Project scope?23:07
rm_workor will we ALSO need to do Impersonation23:07
nkinderrm_work: yes, the users project scope and the roles that they defined when the trust was created23:07
rm_workwe need both the user's roles and also our "admin" roles to do the operations we want23:07
nkinderimpersonation just sets the user in the token to the user AFAIK23:07
nkinderrm_work: which barbican keys off of IIRC23:08
rm_workok, I will have to test23:08
nkinderso you will need a trust token with impersonation23:08
*** marcoemorais has quit IRC23:08
morganfainbergnkinder, yes impersonation = you are that user, vs just have the roles of that user23:08
rm_worknkinder: is that a single operation?23:08
nkinderrm_work: it's an option when creation the trust23:08
nkindercreating23:08
rm_workah23:08
rm_work"Trust With Impersonation" boolean? :P23:08
nkinderso the user would stay as the LBaaS user with the users roles without impersonation23:08
nkinderwith impersonation just sets the user in the trust token too23:09
rm_workso, we don't technically need their *roles* at all, I believe? if we were to impersonate them?23:09
rm_workso maybe we don't even need Trusts, JUST impersonation?23:09
nkinderrm_work: yeah, not with barbican23:09
nkinderwell, you need the ability to impersonate a user when they may not have sent you a token, right?23:09
nkinderfor automation purposes?23:09
rm_workyes23:10
nkinderyeah, so you needs trusts for that property23:10
rm_workok23:10
rm_work4. LBaaS hijacks the user's Keystone Token and uses it to create a Trust (with Impersonation) between the User and the LBaaS Service-Account (if one doesn't exist already), receiving a TrustID23:10
rm_workis that right then?23:10
nkinderyes23:10
nkinderand you store that trust id somewhere in LBaaS to use at execution time later23:11
rm_workyes23:11
rm_workthen 5. LBaaS executes the Trust with Keystone to receive an Impersonation Key23:11
nkinders/impersonation key/trust token (with impersonation)/23:11
rm_workthen 6. LBaaS reads the user's Certificate info using the Trust Token (with Impersonation)23:12
nkinderyep, sounds correct23:12
rm_workk23:12
*** raildo has quit IRC23:17
rm_worknkinder: http://i.imgur.com/fldU3OW.png23:21
nkinderthe arrow between 4 and 5 is confusuing, but you have the idea right in the text23:23
rm_workheh yeah23:23
nkinderI would expect 5 to return the trust ID23:23
rm_worknot sure the best way to do some of those arrows23:23
nkinderthen 6 to execute the trust with an arrow from LBaaS->Keystone23:24
nkinderand 7 to return the trust token23:24
rm_workerr, but 4 returns the trustID?23:24
rm_work5 returns a trustToken23:25
rm_workand 6 uses that token in Barbican?23:25
*** gokrokve has joined #openstack-keystone23:28
nkinderrm_work: http://goo.gl/svqRwz23:29
rm_workheh yeah23:31
*** sigmavirus24 is now known as sigmavirus24_awa23:31
rm_worki used to use this23:31
rm_workI should start again :P23:31
rm_workmaybe I'll redo this whole thing in this tool23:31
nkinderrm_work: I gotta take off, but does my explanation make sense?23:32
rm_workyeah, i thought that was the same as what I had :P23:32
rm_workbut you're saying it isn't quite?23:33
nkinderrm_work: the arrows just weren't showing two distinct operations (round trips) to Keystone23:33
rm_workerr23:33
nkinderrm_work: you have the idea right23:33
rm_workwell it's more of a process diagram than an actual tracking of each and every API call23:34
rm_worklike #1 is actually 2+ API calls23:34
rm_workand from #1 to #2 is not really linked, nor #2 to #323:35
nkinderrm_work: yeah, abstracting some of the detail away is fine.  The main reason to show those keystone actions as separate is that we expect to execute a trust that already exists (which is the whole reason for having a trust)23:36
nkinderrm_work: it allows that flow to be shows by simply eliminating the boxes for trust creation/trust id return23:36
nkinderrm_work: either way, it's a nitpick on my part :)23:37
nkinderrm_work: gotta go, bbl23:37
rm_workkk, thanks for the feedback23:37
jamielennoxmorning all - yes it's client review time, here are a couple with a +2 already:23:41
jamielennoxhttps://review.openstack.org/#/c/115903/23:41
jamielennoxhttps://review.openstack.org/#/c/117399/23:41
jamielennoxhttps://review.openstack.org/#/c/81147/ (a bit trickier than the first two)23:42
*** nkinder has quit IRC23:42
jamielennoxthere are a number of super easy ones as well (less than 50 lines!)23:44
jamielennoxhttps://review.openstack.org/#/c/118520/23:45
jamielennoxhttps://review.openstack.org/#/c/117669/23:45
jamielennox(that one is +10,-2)23:45
jamielennoxhttps://review.openstack.org/#/c/112440/23:46
*** richm1 has quit IRC23:47
*** stevemar has joined #openstack-keystone23:48
*** hrybacki has joined #openstack-keystone23:49
*** gokrokve has quit IRC23:53
*** dims has joined #openstack-keystone23:59

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