Tuesday, 2014-09-23

*** r-daneel_ has quit IRC00:03
*** amcrn has joined #openstack-keystone00:04
*** achampion has quit IRC00:08
*** jorge_munoz has quit IRC00:12
*** wwriverrat has quit IRC00:21
*** wwriverrat has joined #openstack-keystone00:24
*** wwriverrat has left #openstack-keystone00:25
*** nkinder_ has joined #openstack-keystone00:26
*** gokrokve has joined #openstack-keystone00:29
*** oomichi has joined #openstack-keystone00:34
*** HenryG has quit IRC00:36
*** rodrigods_ has joined #openstack-keystone00:37
*** marcoemorais has quit IRC00:44
*** david-lyle has quit IRC00:50
*** jorge_munoz has joined #openstack-keystone00:51
morganfainbergnkinder_, mind taking a look at https://review.openstack.org/#/c/119345/ (LDAP related), more ldap eyes on it would be great.01:03
morganfainbergnkinder_, since it's a RC blocker01:03
nkinder_morganfainberg: sure01:03
nkinder_morganfainberg: about to eat dinner, but I'll look it over afterwards01:03
morganfainbergit *looks* sane to me. but you know... i'd rather combine my "yeah looks sane" with your ldap expertise01:03
morganfainbergnkinder_, yah np, enjoy dinner and thanks! :)01:04
stevemarnkinder_, morganfainberg definitely need some ldap experts on it :\01:04
nkinder_morganfainberg: I thought gyee fixed this as a part of one of his other patches recently01:04
morganfainbergnkinder_, sortof. it's 1/2 fixed this goes the other 1/2 of the way01:04
morganfainbergnkinder_, afaict01:04
nkinder_morganfainberg: hmm, do you have a link handy to gyee's fix for the other half?01:05
morganfainbergnkinder_, but if it isn't needed, i'm happy as well. :)01:05
nkinder_no worries if not, I'll hunt it down01:05
morganfainbergnkinder_, i think it was the read-only attr bit01:05
morganfainbergnkinder_, sec.01:05
nkinder_morganfainberg: yeah, that's the one01:05
morganfainbergnkinder_, https://review.openstack.org/#/c/117658/01:05
gyeemorganfainberg, k, I am familiar with that one01:06
gyeewas going to review it last week01:06
morganfainbergnkinder_, really appreciate it :) yeah if both of you review it and it looks good, i'd feel better about getting it merged in01:06
morganfainberggyee, ^01:06
nkinder_morganfainberg: from gyee's commit message - "This patch also added the missing ID attribute when creating an object in LDAP."01:07
nkinder_I'll compare the code though to make sure01:07
morganfainbergnkinder_, yeah thats what i'm looking for.01:07
nkinder_stevemar: I plan to dive into setting up federation in the next week or two.  I'll likely have some questions pointed your way.01:08
nkinder_stevemar: just a heads up...01:08
morganfainbergnkinder_, gyee, if it turns out we don't need it i'm going to be happy to punt it from RC01:08
gyeenkinder_, we need that 1/2 fix01:08
gyeeour LDAP logic is all over the place01:08
*** achampion has joined #openstack-keystone01:08
gyeeideally all LDAP related stuff are in common/ldap/core.py01:09
* morganfainberg plans on spending a lot more time with LDAP next cycle.01:09
morganfainbergespecially since i want to get us testing against a real LDAP impl.01:09
gyeemorganfainberg, we should seriously think about retiring read-write LDAP01:09
morganfainberggyee, things to discuss @ the summit01:10
morganfainberggyee, i'd actually like to at the very least if we're keeping it make it completly split out as a separate driver.01:10
morganfainberggyee, rather than inter-mingled. so we can optimise for read-only01:10
gyeeyes, and focusing optimizing its performance01:10
stevemarnkinder_, cool with me01:11
morganfainbergstevemar, if you have some spare cycles to mull over things, i'm going to be asking you how we do K2K *real* testing in Kilo :)01:12
*** _cjones_ has quit IRC01:12
morganfainbergstevemar, don't need an answer now, but... :)01:12
stevemarmorganfainberg, good, cause I don't have one01:12
morganfainbergstevemar, hehe01:12
*** _cjones_ has joined #openstack-keystone01:12
*** achampion has quit IRC01:13
*** achampion has joined #openstack-keystone01:13
*** oomichi has quit IRC01:16
openstackgerritA change was merged to openstack/keystone: Fix minor spelling issues in comments  https://review.openstack.org/12299001:16
morganfainberghey look stevemar ^ :P01:17
*** _cjones_ has quit IRC01:17
*** gokrokve_ has joined #openstack-keystone01:22
*** gyee has quit IRC01:25
*** gokrokve has quit IRC01:25
*** gokrokve_ has quit IRC01:27
nkinder_morganfainberg: I can help you with getting the testing side of that up and running.  I've just built a bunch of automation for that sort of thing for my own testing.01:29
morganfainbergnkinder_, sweet. i'm hoping we can follow in the steps of the other functional testing suites01:30
nkinder_morganfainberg: one of the bugs I fixed a week or two ago has hit quite a number of people running icehouse (it's fixed in stable/icehouse now).  It's stuff we could catch with live LDAP testing.01:30
morganfainbergand i want multi-domain testing as well (per domain backends) etc01:30
morganfainbergso i think we have a lot of improvement we can do.01:31
nkinder_morganfainberg: also, debugging of LDAP is pretty ugly.  I usually resort to packet capture and adding more logging to the code. :(01:31
nkinder_morganfainberg: we should definitely devote some summit time to discussing this01:31
morganfainbergnkinder_, yep01:31
nkinder_morganfainberg: I'm in agreement with gyee.  We need this additional fix (though I'm still reviewing the whole thing).01:32
nkinder_morganfainberg: It's catching an issue in the LDAP assignment driver01:32
morganfainbergnkinder_, sounds good. i'll look for your +1. if you +1 and i have a +2 from gyee i feel like that covers the ldap expertise01:33
morganfainbergnkinder_, and the rest of it def. looks "right"01:33
openstackgerritDave Chen proposed a change to openstack/keystone: local configuration should be allowed in "keystone-paste.ini"  https://review.openstack.org/12143901:33
*** diegows has quit IRC01:35
ayoung-afkmorganfainberg, something is strange.  I know I +2ed that review right when I first saw it earlier today01:38
*** ayoung-afk is now known as ayoung01:38
morganfainbergayoung, the LDAP one? it's had some work done on it today01:38
ayoungmorganfainberg, no, bknudson's fix for oslo config01:38
ayoungah...it was in middleware01:39
morganfainbergoh you +2'd middleware01:39
ayoungnot in keystone, that is why01:39
ayounglooking at the LDAP one now01:39
morganfainbergayoung, ah tyvm :)01:40
ayoungmorganfainberg, what does he mean by "older LDAPs?"01:40
morganfainbergayoung, g. OpenLDAP 2.301:40
ayoungI mean,  this code is from more than three years ago01:40
ayoungmorganfainberg, yeah, I meant like time wise.01:41
ayoungwhere are we now...01:41
morganfainberg i think we may have some changes recently that changed this around.01:41
morganfainberglike some of the refactoring of how we handle things in ldap during juno01:41
ayoungmorganfainberg, hmmm01:41
morganfainbergayoung, it's also specific to emulation enabled afaict01:42
morganfainbergayoung, which may not be heavily used in the older openldaps01:42
ayoungit seems innocuous01:42
ayoungmorganfainberg, yeah...I just worry that this is going to "fix" things for the author and break it for someone else01:43
ayoungI hate that we lack real LDAP testing01:43
ayoungI wonder what the right testing matrix would be?01:43
ayoungOpenLDAP (versions?), FreeIPA, AD.01:43
ayoungI wonder if we could get Microsoft to run an out of tree check job against AD?01:44
morganfainbergayoung, i think this falls into the "functional" testing bucket. though AD would likely need to be external CI01:44
ayoungmaybe alex piloti's team could set it up01:44
ayoungor CERN01:44
morganfainbergayoung, that would be awesome. maybe not Microsoft, but perhaps one of the companies that is interested in it01:44
ayoungMS is paying more attention01:45
ayoungI went to an OpenStack meetup in the Cambrige office.  They had some interesting things going on01:45
ayoungOpenVSwitch running on Microsoft server01:45
*** alex_xu has quit IRC01:45
morganfainbergi'd love them to be directly involved, but if not i think we have some companies that could/would dedicate resources to it01:45
ayoungmorganfainberg, primeministerp  (Peter Pouliot) works for them01:46
ayounghe's been the guy keeping the HyperV dream alive01:46
ayoungoffered to get us some AD licenses etc01:46
morganfainbergdef. someone to talk to then.01:46
ayoungthey have a slew of internal CI,  I'll see if they can run an external AD job.  SHoulda thought of that before01:46
morganfainbergwould be great to have external CI for that01:47
morganfainbergayoung, I'd also like to see RAX document jython deplopyment of keystone and external CI it.01:47
ayoungmorganfainberg, "external CI" as a Keystone session at the design summit?01:48
morganfainbergayoung, i think it's a definite possibility or a "pod" (or whtever the equivalent this time will be) discussion01:48
ayoungmorganfainberg, I think that is the ticket...we identify the various LDAP setups we need to test and get someone's name on the line for each01:49
morganfainbergwell anything OpenLDAP i want us to gate on as 1st party CI.01:49
morganfainbergbut other than that yeah that would be awesome.01:49
ayoungI can talk with RH internal;  we already have a CI job (or have at some point) and I can get nkinder_ and our next level boss to put some pressure on to run a FreeIPA based job there01:49
morganfainbergwoo :)01:50
ayoungI thinkits time01:50
nkinder_morganfainberg: reviewed01:50
morganfainbergnkinder_, tyvm!01:50
nkinder_morganfainberg: Looks good.  There's one comment that could be added, but not worth holding things up for it.01:50
morganfainbergnkinder_, ah looks like we're just waiting for a clean "check" run now.01:50
nkinder_morganfainberg: yeah, it's in the check queue01:50
morganfainbergunless ayoung sees anything glaringly wrong, but ... it *looks* pretty sane, just wasn't sure on the LDAP specifics.01:51
nkinder_morganfainberg: honestly, AD would be an ideal gate test (and FreeIPA)01:51
ayoungnkinder_, read up...I think we have a plan for dealing with LDAP and all its complexities:01:51
morganfainbergnkinder_, yeah, though AD (due to licensing) would likely nesscitate it being external CI (see scroll back)01:51
ayoungwe make an external CI framework for LDAP testing01:51
ayoungand then identify one person at the summit for each variety01:52
ayoungso we'll that the FreeIPA variation, probably get CERN to do AD since they were the driving force behind it, if we can';t get MS to take it01:52
ayoungupstream CI will be run against OpenLDAP and devstack01:52
ayoungmorganfainberg, I say we go with the following scenario:01:52
nkinder_ayoung: yeah.  I have automation that builds a complete AD VM setup, a Keystone VM from a fresh RHEL cloud image (full all-in-one RDO install actually), and configures Keystone to use AD with no intervention.01:53
ayounginstall is done on SQL. LDAP is mounted in a specific domain with a precanned set of users, and we run the LDAPLiveTests against it01:53
nkinder_morganfainberg: yeah, if we can get the licensing issue nailed down, it's completely automatable.01:53
morganfainbergnkinder_, nice.01:53
morganfainbergthis discussion makes me really happy.01:54
ayoungnkinder_, maybe we can get Oracle to run it:  https://twitter.com/RDOcommunity/status/51408048075784192101:55
nkinder_ayoung: LOL01:55
*** shakamunyi has quit IRC01:57
*** alex_xu has joined #openstack-keystone01:59
*** rodrigods_ has quit IRC02:01
ayoungmorganfainberg, do you have +A ability here https://review.openstack.org/#/c/120261/02:02
ayoungthere are 2 +2s02:02
morganfainbergayoung, nope. not infra core02:02
morganfainbergayoung, i *think* this is blocking on the governance change02:03
morganfainbergayoung, either that... or it's the wrong day for new repos02:03
ayoungmorganfainberg, I thought they were waiting a +1 from dolphm02:03
morganfainbergayoung, yeah. they are on the governance change02:03
*** jorge_munoz has quit IRC02:03
*** gordc has joined #openstack-keystone02:09
*** dims_ has quit IRC02:15
*** dims has joined #openstack-keystone02:16
*** amcrn has quit IRC02:16
*** radez_g0n3 is now known as radez02:19
*** dims has quit IRC02:20
*** andreaf has quit IRC02:23
*** andreaf has joined #openstack-keystone02:24
*** jorge_munoz has joined #openstack-keystone02:28
*** jimbaker has quit IRC02:40
*** jimbaker has joined #openstack-keystone02:44
*** jimbaker has quit IRC02:44
*** jimbaker has joined #openstack-keystone02:44
*** soulxu_ has joined #openstack-keystone02:45
*** alex_xu has quit IRC02:48
*** HenryG has joined #openstack-keystone02:48
*** KanagarajM has joined #openstack-keystone02:58
*** KanagarajM has quit IRC03:06
*** richm1 has quit IRC03:08
*** saran has joined #openstack-keystone03:16
*** saran has quit IRC03:17
*** ukalifon3 has joined #openstack-keystone03:17
*** ukalifon1 has quit IRC03:19
*** jorge_munoz has quit IRC03:24
*** ayoung has quit IRC03:31
*** zzzeek has quit IRC03:37
*** morgan_remote_ has joined #openstack-keystone03:50
*** marcoemorais has joined #openstack-keystone03:50
*** marcoemorais1 has joined #openstack-keystone03:52
*** soulxu__ has joined #openstack-keystone03:54
*** marcoemorais has quit IRC03:55
*** soulxu_ has quit IRC03:57
*** vdreamarkitex has quit IRC03:58
*** cjellick has quit IRC04:02
openstackgerritSteve Martinelli proposed a change to openstack/keystone: local configuration should be allowed in "keystone-paste.ini"  https://review.openstack.org/12143904:04
*** Sanchit has left #openstack-keystone04:16
*** gokrokve has joined #openstack-keystone04:20
*** vdreamarkitex has joined #openstack-keystone04:29
*** cjellick has joined #openstack-keystone04:31
*** gordc has quit IRC04:31
*** cjellick has quit IRC04:35
*** radez is now known as radez_g0n304:39
openstackgerritDave Chen proposed a change to openstack/keystone: local configuration should be allowed in "keystone-paste.ini"  https://review.openstack.org/12143904:44
openstackgerritDave Chen proposed a change to openstack/keystone: local configuration should be allowed in "keystone-paste.ini"  https://review.openstack.org/12143904:48
*** vdreamarkitex has quit IRC04:49
*** gokrokve_ has joined #openstack-keystone04:50
*** gokrokve has quit IRC04:53
*** _cjones_ has joined #openstack-keystone05:11
*** gokrokve_ has quit IRC05:13
*** gokrokve has joined #openstack-keystone05:14
*** _cjones_ has quit IRC05:16
*** _cjones_ has joined #openstack-keystone05:16
*** gokrokve has quit IRC05:18
*** gokrokve has joined #openstack-keystone05:24
*** vhoward has joined #openstack-keystone05:26
*** harlowja is now known as harlowja_away05:31
*** cjellick has joined #openstack-keystone05:31
*** cjellick has quit IRC05:36
*** cjellick has joined #openstack-keystone05:44
openstackgerritA change was merged to openstack/python-keystoneclient: Fix auth_token for old oslo.config  https://review.openstack.org/12319805:46
*** rushiagr_away is now known as rushiagr05:52
*** afazekas has joined #openstack-keystone05:53
*** cjellick has quit IRC05:56
*** morgan_remote_ has quit IRC06:00
*** jaosorior has joined #openstack-keystone06:05
*** k4n0 has joined #openstack-keystone06:23
*** amerine has quit IRC06:29
*** andreaf has quit IRC06:32
*** andreaf has joined #openstack-keystone06:32
*** ukalifon3 has left #openstack-keystone06:36
*** drjones has joined #openstack-keystone06:38
*** ukalifon1 has joined #openstack-keystone06:39
*** drjones has quit IRC06:40
*** drjones has joined #openstack-keystone06:40
*** _cjones_ has quit IRC06:41
*** stevemar has quit IRC06:43
*** drjones has quit IRC06:44
*** henrynash has joined #openstack-keystone06:45
*** lufix has joined #openstack-keystone06:46
*** gokrokve_ has joined #openstack-keystone06:49
*** cjellick has joined #openstack-keystone06:51
*** gokrokve has quit IRC06:51
*** gokrokve_ has quit IRC06:54
*** cjellick has quit IRC06:56
*** morgan_remote_ has joined #openstack-keystone07:09
*** andreaf has quit IRC07:11
*** wanghong has quit IRC07:11
*** BAKfr has joined #openstack-keystone07:21
*** gokrokve has joined #openstack-keystone07:25
*** gokrokve has quit IRC07:27
*** gokrokve has joined #openstack-keystone07:27
*** wanghong has joined #openstack-keystone07:28
*** soulxu__ has quit IRC07:31
*** dguitarbite has quit IRC07:31
*** gokrokve has quit IRC07:32
*** marcoemorais1 has quit IRC07:33
openstackgerritDave Chen proposed a change to openstack/keystone: Remove duplicated assertion  https://review.openstack.org/12338207:47
*** alex_xu has joined #openstack-keystone07:47
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: token signing support alternative message digest  https://review.openstack.org/11737207:49
*** cjellick has joined #openstack-keystone07:52
openstackgerritDave Chen proposed a change to openstack/keystone: Remove duplicated assertion  https://review.openstack.org/12338207:53
*** cjellick has quit IRC07:57
*** jaosorior has left #openstack-keystone07:59
*** jaosorior has joined #openstack-keystone07:59
*** dguitarbite_ has joined #openstack-keystone08:01
openstackgerritA change was merged to openstack/keystone: Fix create and user-role-add in LDAP backend  https://review.openstack.org/11934508:01
*** dguitarbite_ is now known as dguitarbite08:02
openstackgerritA change was merged to openstack/python-keystoneclient: Do not iterate action.choices if it is none  https://review.openstack.org/12301608:02
*** f13o has joined #openstack-keystone08:11
*** f13o has quit IRC08:15
*** f13o has joined #openstack-keystone08:15
*** gokrokve has joined #openstack-keystone08:26
*** gokrokve has quit IRC08:31
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Add an extension to store domain specific configuration in SQL.  https://review.openstack.org/12323808:34
*** viklund has joined #openstack-keystone08:37
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Add an extension to store domain specific configuration in SQL.  https://review.openstack.org/12323808:38
*** cjellick has joined #openstack-keystone08:53
*** cjellick has quit IRC08:57
*** morgan_remote_ has quit IRC09:10
*** henrynash has quit IRC09:14
*** KanagarajM has joined #openstack-keystone09:26
*** gokrokve has joined #openstack-keystone09:26
*** gokrokve has quit IRC09:30
*** andreaf_ is now known as andreaf09:36
*** Tahmina has joined #openstack-keystone09:43
*** amakarov_away is now known as amakarov09:44
*** dguitarbite has quit IRC09:53
*** cjellick has joined #openstack-keystone09:54
*** aix has joined #openstack-keystone09:57
*** cjellick has quit IRC09:59
*** henrynash has joined #openstack-keystone10:02
*** junhongl has quit IRC10:19
*** junhongl has joined #openstack-keystone10:21
*** diegows has joined #openstack-keystone10:23
*** dguitarbite has joined #openstack-keystone10:25
*** gokrokve has joined #openstack-keystone10:26
*** ajayaa has joined #openstack-keystone10:28
*** gokrokve has quit IRC10:30
*** soulxu_ has joined #openstack-keystone10:34
*** alex_xu has quit IRC10:38
*** soulxu__ has joined #openstack-keystone10:46
*** soulxu_ has quit IRC10:49
*** henrynash has quit IRC10:50
*** henrynash has joined #openstack-keystone10:52
*** cjellick has joined #openstack-keystone10:55
*** soulxu_ has joined #openstack-keystone10:56
*** cjellick has quit IRC10:59
*** soulxu__ has quit IRC10:59
*** garcianavalon has joined #openstack-keystone11:01
*** soulxu_ has quit IRC11:02
*** soulxu_ has joined #openstack-keystone11:02
*** henrynash has quit IRC11:08
*** achampion has quit IRC11:12
*** vdreamarkitex has joined #openstack-keystone11:17
*** soulxu_ has quit IRC11:19
*** soulxu_ has joined #openstack-keystone11:20
*** amarouni has joined #openstack-keystone11:21
*** dims has joined #openstack-keystone11:25
*** gokrokve has joined #openstack-keystone11:26
*** gokrokve has quit IRC11:31
*** gordc has joined #openstack-keystone11:35
*** lufix has quit IRC11:37
*** samuelmz has joined #openstack-keystone11:37
*** ukalifon1 has quit IRC11:46
*** gordc has quit IRC11:51
samuelmzdolphm, ping11:51
*** ukalifon1 has joined #openstack-keystone11:52
*** cjellick has joined #openstack-keystone11:56
*** cjellick has quit IRC12:00
*** achampion has joined #openstack-keystone12:04
*** k4n0 has quit IRC12:09
*** amarouni has left #openstack-keystone12:10
*** dims has quit IRC12:13
*** dims has joined #openstack-keystone12:14
*** gokrokve has joined #openstack-keystone12:26
*** KanagarajM has quit IRC12:29
*** gokrokve has quit IRC12:31
*** soulxu_ is now known as alex_xu12:55
*** cjellick has joined #openstack-keystone12:57
*** cjellick has quit IRC13:01
*** Tahmina has quit IRC13:03
*** gordc has joined #openstack-keystone13:12
*** zzzeek has joined #openstack-keystone13:13
*** nkinder_ has quit IRC13:14
*** miqui has joined #openstack-keystone13:15
*** alex_xu has quit IRC13:24
chmouelit's kind of painful to launch the keystonemiddleware unittests these days :(13:25
chmouel(or at least on macosx)13:25
*** zzzeek has quit IRC13:25
*** victsou has joined #openstack-keystone13:26
*** topol has joined #openstack-keystone13:26
*** gokrokve has joined #openstack-keystone13:26
*** bknudson has joined #openstack-keystone13:28
*** gokrokve has quit IRC13:31
*** radez_g0n3 is now known as radez13:32
*** stevemar has joined #openstack-keystone13:34
*** ayoung has joined #openstack-keystone13:34
*** vhoward has left #openstack-keystone13:35
*** ajayaa has quit IRC13:37
*** richm has joined #openstack-keystone13:38
chmouelmhu: http://pastie.org/private/tiarpbno1mt8p4lwmbol9q13:38
*** andreaf is now known as andreaf_13:38
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Enumerate Projects with Unscoped Tokens  https://review.openstack.org/10683813:47
ayoungchmouel, always get a little giggle out of that site name.13:48
chmouelayoung: hahah :)13:48
* ayoung reads up13:48
*** sigmavirus24_awa is now known as sigmavirus2413:52
*** jaosorior has quit IRC13:52
*** ajayaa has joined #openstack-keystone13:54
ayoungchmouel, tox is not an option on Mac?  I know that at least two Keystone core do their work on mac, so I think there is something you are missing13:54
ayoungthat looks like it is reading the wrong config.13:54
chmouelayoung: it wasn't working for me when launching maybe there is some tricks? the paste i sent earlier was on f2013:55
ayounghow'd you run it?13:55
chmouelayoung: another colleague launched it on his mac and wasn't working for him either13:55
chmoueltox -epy34 for me tox -epy27 for my colleague (both fails)13:55
ayoungchmouel, how old were the venvs?13:57
chmoueli rm -rf them beforehand13:57
chmoueltrying again13:57
ayoung tox -epy27 failed for me, but in a different way.  trying with -r13:57
*** cjellick has joined #openstack-keystone13:57
*** joesavak has joined #openstack-keystone13:57
*** r-daneel_ has joined #openstack-keystone14:00
ayoungchmouel, I got the same thing14:00
chmouelayoung:  ah at least i am not the only one :)14:00
ayoungchmouel, I've learned that if you are the one complaining, and I am not seeing the problem, the issue is far morelikely on my side....14:01
ayoungchmouel, I'm going to guess that this is suspec:  commit d281bd25461eda49963522a5bf2583b84bb7d147:   Updated from global requirements14:02
ayounglets see...14:02
*** cjellick has quit IRC14:02
chmouelah this sounds a god culpurit14:02
ayoungthere are some other recent commits that might also be culpable14:02
ayoung"Always add auth URI to unauthorized requests"14:02
ayoungconsidering the error is on an url that looks like an authurl check14:03
ayoung  File "keystonemiddleware/tests/test_auth_token_middleware.py", line 1317, in test_auth_plugin14:03
ayoungthat is14:03
chmouelah yeah mhu was mentioning this to me offline just before ^14:04
*** nkinder_ has joined #openstack-keystone14:04
*** toysrough has quit IRC14:04
*** gokrokve_ has joined #openstack-keystone14:05
*** mflobo_ has joined #openstack-keystone14:05
morganfainbergchmouel, as of yesterday i was able to use tox on a mac14:06
morganfainbergchmouel, but.. there is a caveate14:06
ayoungmorganfainberg, run with -r14:06
ayoungsomething has changed, and its not a Mac issue14:06
morganfainbergayoung, you need to brew install stuff14:06
ayoungit is a kmid14:06
ayoungmorganfainberg, its not a mac issue, I have it on F2014:06
morganfainbergoh that one14:06
morganfainbergoh thats got a fix gating iirc14:07
morganfainbergtop of the queue14:07
ayoungsehr kuhl14:07
*** mflobo has quit IRC14:07
*** jsavak has joined #openstack-keystone14:07
chmouelnice :)14:07
morganfainberghopefully will merge in 11mins14:07
morganfainbergor so14:07
*** achampion has quit IRC14:08
morganfainbergayoung, down to 1 review blocking keystone14:09
morganfainbergmemcache pool14:09
ayoungmorganfainberg, I'll trade you a memcache pool for a client review...14:10
morganfainbergksc is ready for the 0.11.1 release (will ask TTX to cut it in a few minutes unless dolph is around)14:10
morganfainbergayoung, sure will review that once done with things like release 1-on-one unless dolphm is around doing it.14:10
morganfainbergayoung, supposed to do the release thing in lik 2 mins :P14:11
morganfainbergor i'd review it now14:11
ayoungfair enough14:11
*** joesavak has quit IRC14:11
ayoungDamn YorikSar you like taking the easy patches don't you?14:12
*** achampion has joined #openstack-keystone14:12
chmouelif someone masterize their py3, encoding, buffer and stuff like that please feel free to advise me about this  https://bugs.launchpad.net/keystonemiddleware/+bug/137248414:12
uvirtbotLaunchpad bug 1372484 in keystonemiddleware "auth_token body errors are not returned as bytes for py34" [Undecided,New]14:12
morganfainbergchmouel, the bug looks legitimate.14:13
*** mflobo_ has quit IRC14:13
morganfainbergchmouel, but i haven't tested it14:13
morganfainbergchmouel, the fix seems... "sane" that is in the bug14:13
*** mflobo has joined #openstack-keystone14:13
ayoungmorganfainberg, so there is no pooling library for memcache that we can use?  We have to carry this code ourselves?14:13
morganfainbergayoung, the issue is thread.local14:13
chmouelah, yeah was trying to send a proper patch but i needed to be able to run the untittests first :)14:13
ayoungof course it is14:13
morganfainbergayoung, in K we'll convert to pymemcached (and so will dogpile upstream)14:14
ayoungmorganfainberg, is this one of those Eventlet only issues?14:14
morganfainbergthen we can look at other options.14:14
morganfainbergayoung, yep14:14
*** jsavak has quit IRC14:14
morganfainbergayoung, joyous right?14:14
ayoungmorganfainberg, OK,  I'm digging in.  Eventlet is not going to beat me.  We are getting rigd of that thinkg in Kilo14:14
morganfainbergayoung, probably deprecate in K, remove in L or M14:15
morganfainbergbut yes.14:15
ayoungmorganfainberg, so what is this patch doing to get around threadlocal?14:16
morganfainbergayoung, it's making a memcache pool that is based on the queue.Queue object (locking across greenthreads) and replaces the base class in memcache client with object14:16
morganfainbergnot using thread.local14:16
YorikSarayoung: Huh?14:17
ayoungYorikSar, looking at your Memcache Pool patch14:17
YorikSarayoung: Oh, yes, I like to put up couple diff lines14:17
ayoungYorikSar, how does that patch work?14:18
YorikSarayoung: When user turns on 'memcache_pool' backend for cache and/or memcache token persistence backend, it uses a very special dogpile.cache backend that keeps pool of connections to memcached and reuses them and does some fancy stuff with them14:20
ayoungYorikSar, I don't see enough code to make that happen.  Is it in here:  https://review.openstack.org/#/c/119452/31/keystone/common/cache/_memcache_pool.py,cm14:20
*** david-lyle has joined #openstack-keystone14:21
ayoungdoes @contextlib.contextmanager somehow synchronize here?14:22
YorikSarayoung: No, but Queue does14:22
YorikSarayoung: We subclass stdlib Queue that does all synchronization for us14:23
ayoungand that ensures that the ref counting to the pool is atomic?14:23
openstackgerritMarek Denis proposed a change to openstack/keystone: Read idp_metadata_path value from CONF.saml  https://review.openstack.org/12344614:23
marekdstevemar: ^^14:24
morganfainbergayoung, yep14:24
stevemarthanks marekd14:24
stevemarmorganfainberg, ^14:24
ayoungYorikSar, morganfainberg what are we modeling as a queue?  THe connection pool?14:25
morganfainbergayoung, correct.14:25
morganfainbergmarekd, stevemar, is that changing the behavior from the last release?14:26
ayoungI guess it makes sense...14:26
marekdmorganfainberg: no.14:26
ayoungstricter than we need, but who cares14:26
stevemarmorganfainberg, no, a bug with k2k14:26
morganfainbergayoung, hm, it might be using the queue as a stack instead. we had it as a stack when it was the list.14:27
morganfainbergayoung, it also will reap unused connections14:27
morganfainbergayoung, after a period of time14:27
ayoungmorganfainberg, what performs that operation?14:28
ayoungthere is not explicit timer thread14:28
morganfainbergayoung, on connection release, we look at how long connections are idle in the queue, it's a simple search the queue for the TTL and compare14:28
morganfainbergreap if needed14:28
morganfainbergayoung, it's part of the context manager.14:28
ayoungmorganfainberg, so  we clean uop just when there is activity?14:29
morganfainbergayoung, correct.14:29
morganfainbergayoung, there is also a maximum size14:29
morganfainbergayoung, so you don't balloon usage.14:29
ayoungyeah, I see that, and I get it now...14:29
rodrigodsmakes sense to do something like that https://wiki.openstack.org/wiki/KeystonePerformance after Juno release?14:29
ayoungwhat is a memcache connection anyway?  I'd have thought it to be a TCP socket.  Couldn';t we time out the socket it self?14:30
ayoungand wouldn't that be more correct?14:30
morganfainbergayoung, the memcache client objects are smart, they reconnect14:30
morganfainbergayoung, among other things, and track dead memcache servers14:30
ayoungmorganfainberg, then why even bother to clean up?  They can't be that resource intensive14:31
ayoungbut cleaning up upon activity seems backwards14:31
ayoungits like, we had a bunch of activilty, so create a bunch of connections...then things die down...then we have a new flurry of activity...and we remove resources?14:32
morganfainbergayoung, well we only cleanup on release, meaning if there is a bunch of activity the connections will be active again14:32
ayoungwhat calls release?14:32
YorikSarayoung: After we had peak of activity, we clean up during usual rare activity14:32
YorikSarayoung: __exit__ in context manager basically14:33
morganfainbergayoung, release is the after the yeild in the contextmanager14:33
ayoungwhat does that map to in keystone?14:33
YorikSarayoung: And each operation with memcached is wrapped into that context manager.14:33
YorikSarayoung: Like when dogpile calls 'self.client.set(...)' or .get or whatevet, each operation is wrapped in that context manager14:34
YorikSarayoung: that acquires Client object from pool, does that operation and releases it back.14:34
YorikSarayoung: And after that it looks to the bottom of the stack for connections that stay there for too long.14:35
morganfainbergayoung, in reality, we likely will never see connections disappear with any load on keystone14:35
openstackgerritChmouel Boudjnah proposed a change to openstack/keystonemiddleware: Encode middleware error message as bytes  https://review.openstack.org/12345114:35
ayoungYorikSar, sar, so, yeah, its right at a burst of activity.14:35
ayoungmorganfainberg, its not a deal breaker,14:35
morganfainbergayoung, because connections will continue to be used.14:35
ayoungjust the same kind of messines we have with the SQL token backend and cleanup:  no good time to run it14:36
morganfainbergayoung, my local testing showed the connections consistently being used with a single thread doing token requests in a tight-ish loop14:36
morganfainbergayoung, yeah.14:36
morganfainbergayoung, so i don't think if keystone is under any real load we'll actually see reaping.14:37
ayoungmorganfainberg, activity goes in cycles14:37
morganfainbergayoung, the point is it doesn't take a ton of activity to keep the pool active14:37
morganfainbergayoung, but it doesn't add significant delays if the pool is active and hitting the maxsize limit unless you're woefully tuned to the low end.14:38
ayoungmorganfainberg, model this:   1000 connections.  Then idle for an hour,  then 1000 connections.14:38
morganfainbergayoung, in a production environment, you're not going to be idle for an hour, you might see 100rps then 1000rps14:38
ayoungmorganfainberg, make sure it is a queue then, not a stack14:39
morganfainbergayoung, even at 100rps you'll keep the pool mostly active.14:39
morganfainbergayoung, the reaping is pretty efficient.14:39
ayoungif you do a stack, you'll have one or two entries at the top active, and the bottom will not be cleaned up14:39
morganfainbergayoung, the cleaner reapse from the left14:40
morganfainbergayoung, the conenctions are aqcuired from the right (pop)14:40
ayoungnah,  do both from the right14:40
ayoungbut...not this patch14:40
morganfainbergayoung, hehe open to modifying this once we're into K14:41
ayoungI think we have something wrong, but I need to think about the right way to do it14:41
morganfainbergalso we'll move to pymemcached which eliminates some of the dirty hacks to deal with thread.local14:41
ayoungmorganfainberg, this is just how I understand code:14:41
morganfainbergas will dogpile.14:41
morganfainbergwe would have done that this cycle but we were past dep. freeze14:42
*** Xeye has joined #openstack-keystone14:42
*** Xeye has quit IRC14:43
*** garcianavalon has quit IRC14:44
morganfainbergmiddleware fix didn't pass gate :(14:44
YorikSarayoung, morganfainberg: We acquire and release conns from/to top of the stack, but do cleanup from the bottom14:50
ayoungYorikSar, the more I think about it, the more I am convinced that there is no right way to do this without having a cleanup thread.  Your solution is fine14:51
*** andreaf has joined #openstack-keystone14:51
YorikSarayoung: I had cleanup thread... But everybody said "We don't want extra threads in Keystone!"14:51
ayoungYorikSar, they are correct14:52
morganfainbergayoung, i really don't want to start advocating "cleanup" threads as a pattern within keystone. i'd rather not do any cleanup on the stack.14:52
ayoungI think the cleanup is unnecessary if each connection is doing nothing when idle.  So long as there is a top number of connections, we are ok14:52
ayoungmax out and stay there14:52
morganfainbergsince you need to budget resources for maximum number of connections anyway14:52
morganfainbergayoung, there is a tunable for idle timeout, you could do that effectively by settnig it to some rediculously high number14:53
morganfainberglike 1day14:53
ayoungYorikSar, morganfainberg why is MemcachePool a separate class from ConnectionPool?14:54
morganfainbergayoung, my view, ease of testing the connection pool.14:54
YorikSarayoung: To clearly separate functionality.14:54
YorikSar(and tests, right)14:55
ayoungYorikSar, in the future, if you have two classes, keep them as two classes.  Favor composition over inheritance14:55
YorikSarayoung: Well... It's not very clear how we can plug in memcache specifics into abstract pool without weird hooks or smth like that. I prefered to just do inheritance.14:57
*** KanagarajM has joined #openstack-keystone14:57
ayoungYorikSar, you have 3 classes.  One is a pool, which manages resources. One is a memcache connections. In between you have an adapter14:57
morganfainbergYorikSar, it wouldn't be too hard. but it's fine as is for now.14:57
YorikSarayoung: But probably 'MemcacheClientManager' with smth like 'before_acquire' and 'before_release' methods would be better.14:57
ayoungyep...lots of code like this14:57
ayoungand not for this patch14:58
ayoungjust for future reference14:58
*** andreaf has quit IRC14:58
*** andreaf has joined #openstack-keystone14:58
YorikSarayoung: I might put up anoter review for that refactor :)14:58
ayoungYorikSar, after this one merges, please14:59
dstanekmorganfainberg: checkout the new middelware version now; so that we can get this going14:59
YorikSarayoung: Sure14:59
dstaneks/checkout/checking out/14:59
ayoungdstanek, is that for chmouel 's problem?14:59
*** jorge_munoz has joined #openstack-keystone14:59
morganfainbergdstanek, thanks :)14:59
morganfainbergdstanek, it likely needs some adjusting14:59
dstanekayoung: k - no i was talking about the pool review i -1ed15:00
morganfainbergdstanek, but it should be close, i didn't port the unit tests over, i can do that if needed.15:00
dstanekmorganfainberg: is the goal for this to get into oslo post release?15:01
morganfainbergdstanek, possibly.15:01
morganfainbergdstanek, not sure where it'll land long term.15:01
YorikSarmorganfainberg: _memcache_pool.py needs to be synched from Keystone version...15:01
YorikSarmorganfainberg: I think I can do it later today15:01
morganfainbergYorikSar, i did a sync since you posted.15:02
morganfainbergYorikSar, there are some changes that were needed (notably the debuglogger needed to go because it was too spammy for middleware) etc15:02
morganfainbergYorikSar, and i18n change, etc15:03
YorikSarmorganfainberg: Ah, CONNECTION_GET_TIMEOUT is not used in Keystone version anymore...15:03
morganfainbergYorikSar, wait it isn't?15:03
morganfainbergYorikSar, ...15:04
morganfainbergYorikSar, why?15:04
morganfainbergYorikSar, oh no it should be?15:04
YorikSarmorganfainberg: No, it's replaced with config value15:04
*** ajayaa has quit IRC15:05
morganfainbergYorikSar, no15:05
morganfainbergYorikSar, in the accquire context manager15:05
morganfainbergoh oh oh that thing15:05
morganfainbergyeah we can clean it up later15:05
YorikSarmorganfainberg: self._connection_get_timeout15:05
YorikSarmorganfainberg: Yep15:05
morganfainbergYorikSar,  yeah we can clean it up later.15:05
morganfainbergYorikSar, scared me for a sec, thought we didn't timeout the acquire!15:06
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Server SAML metadata publicly  https://review.openstack.org/12346615:07
stevemarmarekd, ^15:07
YorikSarmorganfainberg: Ok, I don't see socket_timeout in middleware15:07
YorikSarmorganfainberg: in auth_token.py15:08
morganfainbergYorikSar, it wasn't in the latest post of connection pool15:08
marekdstevemar: thanks15:08
marekdstevemar: did you try it with apache?15:09
YorikSarmorganfainberg: It's passed in **self._arguments to memcache.Client15:09
stevemarmarekd, yep15:09
YorikSarmorganfainberg: It's jsut not present in auth_token's config15:10
*** victsou has quit IRC15:10
morganfainbergYorikSar, ah, thats fine we'll need to add it back in.15:10
morganfainbergYorikSar, might have been dropped in the refactor to make it optional15:10
marekdstevemar: i think there should be a bug against that.15:11
YorikSarmorganfainberg: btw, in reserve() we cat remove @contextmanager and just do 'return self._pool.get()' :)15:11
morganfainbergYorikSar, hm.15:11
stevemarmarekd, i don't think this one will get in this release :( - unless you think it's critical15:11
stevemarmarekd, and yes, needs a bug15:12
marekdstevemar: i don't15:12
YorikSarmorganfainberg: So that we return another context manager instead of wrapping it.15:12
YorikSarmorganfainberg: But that's not a big issue.15:12
marekdstevemar: this == k2k or this patch?15:12
morganfainbergYorikSar, ah. eyah i see it15:12
stevemarmarekd, i wanted to post the fix anyway15:12
stevemarmarekd, this patch15:12
marekdstevemar: understood.15:12
morganfainbergmarekd, k2k is already in afaict15:12
marekdmorganfainberg: yes yes.15:12
morganfainbergmarekd, unless there is a damn good reason don't want to revert it :)15:12
stevemarmorganfainberg, it may have code to activate skynet15:13
morganfainbergstevemar, REVERT REVERT15:13
marekdmorganfainberg: stevemar: yeah, saml2 is skunet's communiation protocol.15:14
YorikSarWhat's k2k?15:16
morganfainbergYorikSar, keystone to keystone federation15:16
YorikSarmorganfainberg: Oh, right.15:16
YorikSarmorganfainberg: Cool feature :)15:16
morganfainbergYorikSar, give credit to marekd and stevemar for making it happen15:17
YorikSarmarekd, stevemar: Good job :)15:18
marekdYorikSar: thanks, but we will open champagne after it's really deployed in some DCs :-)15:19
YorikSarmarekd: Do you have any users in mind?15:19
*** cjellick has joined #openstack-keystone15:19
YorikSarmarekd: We have a customer that would need just that... But it's too late - they already getting Icehouse.15:20
marekdYorikSar: Icehouse has also federation built in.15:20
YorikSarmarekd: But not k2k15:21
marekdYorikSar: and speaking about specific user...well CERN is very much interested in it :-)15:21
YorikSarmarekd: Oh, cool. That means they won't let it rot :)15:21
marekdwe should have it deployed soon (Icehouse federation, not k2k).15:22
marekdYorikSar: no, they won't :-)15:22
ayounghow does the whole "multiple servers" work in memcache?  Can we assume no degree of ACIDity from the commits?15:22
*** joesavak has joined #openstack-keystone15:24
morganfainbergayoung, memcached is atomic on the backend, multiple servers endup being a hash/bucket15:25
morganfainbergayoung, you don't replicate between them.15:25
YorikSarayoung: memcacged don't have ACID at all. Just simple instructions are atomic, nothing more.15:25
YorikSarWell, there is CAS and stuff, but it's not used in Keystone anymore.15:26
*** jsavak has joined #openstack-keystone15:26
morganfainbergYorikSar, that is a dirty word15:26
morganfainbergYorikSar, :P15:26
ayoungum....so when we have a list of memcached servers to try...15:26
morganfainbergYorikSar, CAS isn't supported by dogpile.15:26
ayoungClose Air Support?15:26
morganfainbergYorikSar, thankfully15:26
ayoungI knew Memcach was dangerous....15:26
morganfainbergayoung, it highlights yet again why memcache is awful for token storage15:27
morganfainbergayoung, for caching, it would be a cache miss at worst15:27
YorikSarayoung: Compare And Save15:27
ayoungright, I knew that15:27
bknudsoncompare and set15:28
* ayoung was googling the answer but got distracted15:28
ayoungClear and Stagger15:28
* YorikSar read 'googling' as 'dogpiling'15:28
*** gokrokve_ has quit IRC15:28
ayoungDOGPILE on the RABBIT!15:28
ayoungmorganfainberg, YorikSar ok, last question: a user would have to explicitly enable the pooing, right?15:29
YorikSarayoung: yep15:29
morganfainbergayoung, yes.15:29
*** joesavak has quit IRC15:29
ayoungthe feature will lay dormant until requested.15:29
ayoungOK...I cant +A15:29
morganfainbergayoung, it is opt-in only15:29
YorikSarmorganfainberg: Ha! I'm first!15:29
morganfainbergYorikSar, faster at the keyboarding!15:29
YorikSarayoung: Why cant?15:30
YorikSarmorganfainberg: Short answers only ;)15:30
morganfainbergYorikSar, hah15:30
ayoungbecause I have fat fingers and was typoing *can*15:30
YorikSarayoung: Wow, you fingers must've covered half the keyboard15:30
ayoungwas that muscle memory? Like always typin g after in?15:31
ayoungI can +A15:31
ayoungyeah...the one stray letter on the keyboard that would reverse what I mean....15:31
morganfainbergayoung, tyvm for the review. :) i will get that client one reviewed (though I was pretty happy with it earlier when we found the issue with the domain != domain_id)15:32
morganfainbergayoung, so don't see an issue with the client one as of right now.15:32
ayoungmorganfainberg, I think you pushed me toward a better solution on that one15:32
ayoungI ended up moving the code up one layer of the inheritance tree, and now we could potentially use the "fall back to auth_url"  approach for other calls.15:33
morganfainbergayoung, happy to help. ooh i see the fallback_to_auth15:33
morganfainbergayoung, yeah that is a bit more readable15:33
* ayoung likes doing the +A15:33
YorikSarayoung: Yay! THanks :)15:34
*** david-ly_ has joined #openstack-keystone15:34
morganfainbergayoung, and i think that is the last major RC blocker for keystone.15:35
morganfainbergayoung, once that gates we should be RC-ready. :)15:35
morganfainbergwhich means... we might *yet again* be first to the RC race.15:35
ayoungthis is my first Keystone release without a huge patch15:35
morganfainbergayoung, lots of cleanup though15:36
*** david-lyle has quit IRC15:36
ayoungEssex:LDAP....Folsom:PKI Tokens...Grizzly:Restructuring and Trusts...Havana:Split Identity...Icehouse:Revocation Events15:37
*** gokrokve has joined #openstack-keystone15:37
*** gyee has joined #openstack-keystone15:37
morganfainbergayoung, Kilo... ????15:37
ayoungIts cuz I've been battling Kerberos15:37
ayoungmorganfainberg, for Kilo...endpoint scoping of tokens, I hope15:37
morganfainbergayoung, ++15:37
ayoungactually,  more than that15:37
ayoungI want a switch that says "unscoped to scoped only"15:38
*** jsavak has quit IRC15:38
ayoungthat plus endpoint binding gets us a hugely more secure Keystone15:38
morganfainbergayoung, and kerberos should be good initially because you've been spending a lot of time wrangling it this cycle.15:38
ayoungheh...you'd thinkso15:38
morganfainbergayoung, eh, not that it'd be bad, but it means you've spent more time working on it. sometimes that helps when it's massive cross-project stuff15:39
ayoungmorganfainberg, we are likely to be introducing a new binding for Python to talk to Kerberos here shortly.  Replace python-kerberos with python-gssapi (which is the right interface)  and work twoard getting that as core python15:39
morganfainbergso, at the summit looks like we're getting a 6-7 sessions (we had 8 in ATL), and at least a 1/2 day meetup slot (might become a full day instead)15:39
ayoungpossibly write a PEP for it15:39
ayoungmorganfainberg, CI and testing should be one.  We can include any LDAP and Federation details into that15:40
morganfainbergI'm going to start an Etherpad for us here in a minute15:40
ayounggood deal15:40
morganfainbergso we can get discussions going.15:40
ayoungmorganfainberg, thank you for running for PTL.15:41
morganfainbergayoung, of course!15:41
*** zzzeek has joined #openstack-keystone15:41
* ayoung would have felt guilty for not running, but really doesn't want the job15:41
morganfainbergayoung, i figured you didn't want the job.15:41
marekdmorganfainberg: so it's confirmed already? :-)15:42
morganfainbergmarekd, nah, still open, if you want to run too go for it ;)15:42
marekdmorganfainberg: that was not my point...15:42
morganfainbergmarekd, but so far i'm the only candidate15:42
marekdmorganfainberg: yeah, i figured.15:42
morganfainbergmarekd, wont be official until they open the election on the .. uh 27th?15:42
morganfainbergif i'm the only candidate then, i win, if not election is final early oct15:43
marekdmorganfainberg: does it mean hackathons will take place in California? :P15:43
morganfainbergmarekd, likely will still be in SAT if dolphm, geekdom, and RAX are kind enough to let us15:43
morganfainbergmarekd, it's a good location for us because it has justifications for people to make it (can also do important customer visits) and it's about middle of the country15:44
marekdmorganfainberg: and no as expensive as Cal i guess...15:44
morganfainbergmarekd, i wouldn't be opposed to looking at hitting up raliegh or boston either if those made sense. I'd need to see about booking space up at HP HQ (bay area) if we were to do it in cali (I don't have an office here in SoCal and the hacker-spaces are ... limited)15:45
morganfainbergmarekd, we'll discussit for sure at the summit.15:45
marekdmorganfainberg: ++15:46
nkinder_ayoung, morganfainberg: https://review.openstack.org/#/c/123488/15:47
ayoungnkinder_, thanks15:49
ayoungnkinder_, what group has +2 on that?15:49
nkinder_puppet-core IIRC15:49
nkinder_ayoung: puppet-manager-core15:50
ayoungnkinder_, I added them15:50
nkinder_ayoung: "ultra high-scale" :)15:50
morganfainbergayoung, bknudson, gyee, dolphm, dstanek, stevemar, marekd, nkinder_, lbragstad, henrynash, topol https://etherpad.openstack.org/p/keystone-kilo-summit-sessions15:51
*** jasondotstar has joined #openstack-keystone15:51
*** gokrokve has quit IRC15:51
ayoungnkinder_, I think K2K will replace the primary use case we were headed for with PKI tokens.  I have to think more about it, but, yeah...right now, I don't think most deployments will hit the casew where token validations are the performance bottleneck15:51
nkinder_morganfainberg: cool15:52
nkinder_morganfainberg: have you thought about a federation topic, particularly with how to make it more usable (CLI, Horizon, etc.)?15:52
nkinder_morganfainberg: it might fall into a cross-project thing with Horizon too though15:52
morganfainbergnkinder_, worth adding to the list for sure.15:53
nkinder_k, will do15:53
morganfainbergnkinder_, this is just open discussion so we know what we want to cover. it's getting to that time so we should get some ideas in place before scheduling needs to occur.15:53
*** achampion has quit IRC15:54
ayoungWho wrote LDAP rewrite?15:54
bknudsonayoung: me. we've been talking about it for years.15:54
ayoungbknudson, so...how about a different approach15:55
*** _cjones_ has joined #openstack-keystone15:55
bknudsonayoung: splitting it up into read-only/read-write/Active Directory15:55
ayoungbknudson, using SSSD and apache to do the work for us15:55
bknudsonI'm happy with a different approach15:55
ayoungbknudson,     http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/       look at   for conetxt http://adam.younglogic.com/2014/05/mod_lookup_identity/15:56
ayoungbknudson, and with that setup, we should be able to do SSSD direct to AD.15:59
ayoungnkinder_, can sssd run on a Mac?15:59
nkinder_ayoung: not sure that's ever been attempted15:59
*** rodrigods_ has joined #openstack-keystone15:59
ayoungnkinder_, might be a deal breaker for devs15:59
lbragstadthat etherpad filled up quick16:01
morganfainbergayoung, we largely don't run OpenLDAP on mac anyway16:02
morganfainbergayoung, it's not unreasonable to say you can't run the SSSD tests on OS X if they don't work16:02
ayoungmorganfainberg, but the LDAP code can run on a Mac today.  You might not do it, but I suspect someone does16:04
morganfainbergayoung, sure. let me check something16:05
morganfainbergayoung, haven't tried compiling sssd for mac16:05
gyeeayoung, morganfainberg, bknudson, I did setup LDAP auth with Apache before16:11
gyeeproblem is it has to do it in conjunction with basic auth16:11
ayoungmorganfainberg, so the mod lookup idenetiy approach needs dbus support and sssd.  I know it runs by default on Fedora etc, and I know Debian based distros can support it.16:11
gyeeI had to setup a different endpoint to make it work16:11
gyeelike /v3/auth/tokens/ldap or something16:12
ayounggyee, its really the group list that is the issue16:12
bknudsongyee: that's similar to federation16:12
ayoungwith Kerberos or X509 backed by LDAP we have a decent solution16:12
gyeebut I totally understand ayoung's thinking when you mentioned /v3/auth/tokens/<mechanism> awhile back16:13
ayoungthe one thing that would be good is if we could use the mapping code to add groups to what we get out of LDAP16:13
gyeebknudson, it similar to federation, but I am not sure apache is conveying the attributes in the case of LDAP auth though16:14
gyeelike setting the user objectclass attributes in the request environment16:15
bknudsongyee: right, we'd need our own middleware for that16:15
gyeebknudson, no, you don't need middleware, just a new provider, and protocol map16:15
gyeejust like federation16:15
*** marcoemorais has joined #openstack-keystone16:16
ayoungmorganfainberg, asking about Mac support in #sssd16:16
bknudsongyee: but we don't have the attributes to map?16:16
gyeewith basic auth, Apache is already setting the REMOTE_USER16:16
morganfainbergayoung, cool16:16
bknudsonApache doesn't care about the attributes so it's not going to fetch them.16:16
gyeebknudson, yeah that's a problem16:17
bknudsonI think it just does a compare16:17
gyeewe need the attributes16:17
ayounggyee, is that you adding "Signed requests?"16:18
gyeeayoung, no16:18
gyeeayoung, you mean signature auth?16:18
morganfainbergthat is me16:19
morganfainbergsigned requests like EC2 does with keypairs.16:19
gyeeoh, the etherpad16:19
gyeesorry, I need to scroll back16:19
ayoungmorganfainberg, do you have a link for that? It might be something I'm working towards, too16:21
* ayoung has never worked with EC2. really16:21
morganfainbergayoung, it's HMAC signed requests, so you have a keypair and you sign your request, it does require asking for the other info about your auth on the backend though16:22
*** wwriverrat has joined #openstack-keystone16:22
morganfainbergayoung, let me see if i can find info on it from EC216:22
ayounghttp://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html  ?16:22
morganfainbergayoung, http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html16:22
*** Haneef has joined #openstack-keystone16:22
ayoungbeat ya too it16:23
ayoungSo...couple problems with that.  Nova can't sign a request to glance for you.16:23
morganfainbergayoung, yeah it might not be a perfect analog.16:24
morganfainbergayoung, but it might work for the principle request, it's worth exploring (possibly longer term)16:25
ayoungmorganfainberg, if my request is synchronos, the server can authenticate me directly.  That kind of signing is better for Async, which means it ties in with oslo messaging16:25
ayoungI presented on that last summit.16:25
ayoungbut it means we need a mech for Keypair managment.16:25
ayoungThe credential API was supposed to be that, no?16:26
*** meera has joined #openstack-keystone16:26
*** BAKfr has quit IRC16:27
ayoungmorganfainberg, I wonder if browser based Crypto can be used to sign a request?16:29
morganfainberginteresting thought16:30
ayoungmorganfainberg, if so, then a signed request via javascript becomes an alternative16:31
morganfainbergi'll bet javascript could do the work.16:31
*** rushiagr is now known as rushiagr_away16:31
*** rushiagr_away is now known as rushiagr16:32
*** rodrigods_ has quit IRC16:32
ayoungmorganfainberg, it might be browser specific16:33
*** richm has quit IRC16:34
ayoungmorganfainberg, lets start with this one http://matasano.com/articles/javascript-cryptography/16:34
morganfainbergayoung, cool16:34
ayoungmorganfainberg, but, I think that Crypto in Javascript and Crypto called from Javascript are two different things16:35
ayoungwe only would accept that latter16:35
*** rushiagr is now known as rushiagr_away16:36
morganfainbergok i'm going to go get breakfast...16:39
morganfainbergbe back before the meeting.16:39
*** afazekas has quit IRC16:40
*** arunkant has joined #openstack-keystone16:41
openstackgerritAndre Aranha proposed a change to openstack/keystone: Creating a policy sample  https://review.openstack.org/12350916:43
afaranhaReading openstack policies in general, we think that the roles are quite complicated, we don't know which roles are appropriated for each user. For example, in many policies just the admin role is described. Our proposal is to clarify for the cloud user whats the role organizations, for example, cloud_admin is the role for the admins, project_admin for the project admin and project_member a member with a role in a project but with no ad16:44
afaranhaThe ideia is create a policy.cloudsample.json, where was defined roles as a project_admin, domain_admin, cloud_admin and project_member and determine their permissions, making policies closer to the business reality.16:45
afaranhawhat do you think about it?16:45
morganfainbergafaranha, how does this compare to http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json ?16:46
*** richm has joined #openstack-keystone16:47
*** gokrokve has joined #openstack-keystone16:48
afaranhathe roles are more defined16:51
afaranhawe have specific roles for the cloud admin, the domain admin, project admin and for a project member16:51
morganfainbergafaranha, right. the cloudsample one should be similar in that regard.16:52
afaranhathe sample provided in keystone are only defining the admin role16:52
afaranhathere is no separations, in roles, for other kind of users16:53
afaranhaexcept for service role16:53
morganfainbergafaranha, ah i see,16:53
morganfainbergafaranha, i'm not opoosed to having other example policy files, it's worth discussing the merits of having them in-tree, documented, etc.16:54
afaranhaone of the motivations for this is that we got confused because there are 2 roles for member in keystone, "_member_" and "Meber"16:54
afaranhayes, sure16:55
morganfainbergafaranha, eventually i'd like to see a richer default policy for keystone, but we need to work on how to provide that without breaking current deployments16:55
afaranhaNow we are going to work on the documentation16:55
morganfainbergafaranha, cool16:55
afaranhacurrently we are submitting a paper to a conference with a use experience with policies in Opensatck16:55
afaranhawe are going to create a documentation based on this[16:55
*** lufix has joined #openstack-keystone16:55
*** lufix has quit IRC16:56
*** lufix has joined #openstack-keystone16:56
morganfainbergafaranha, i look forward to seeing the documentation / paper16:56
afaranhasure, thanks :)16:56
afaranhaand we are doing this for the main Openstack policies, Cinder, Nova, Glance and Neutron also16:56
afaranhagood to have a good feedback16:56
afaranhamorganfainberg: Two problem that we encountered, that is not in this scope, is the sync of the different policies and hardcoded checks, without using the policy permissions16:59
morganfainbergafaranha, V2 definitely only uses admin.17:00
morganfainbergafaranha, and that isn't going to change.17:00
morganfainbergafaranha, v3 shouldn't have hard-coded checks17:00
morganfainbergafaranha, other openstack projects do have hardcoded "admin" and similar roles17:00
*** _cjones_ has quit IRC17:03
*** _cjones_ has joined #openstack-keystone17:03
*** sigmavirus24 is now known as sigmavirus24_awa17:04
*** david-ly_ is now known as david-lyle17:04
topolmorganfainberg where on your summit session list would we put Keystone Horizon fedration integration?17:04
*** stevemar has quit IRC17:04
*** lufix has quit IRC17:05
topolfederation integration?17:05
*** stevemar has joined #openstack-keystone17:05
marekdtopol: i think it's already there - 9.217:05
gyeetopol, are you guys going to donate a CADF consuming service to Jenkins so we can gate the stuff?17:07
*** wwriverrat has left #openstack-keystone17:07
*** rushiagr_away is now known as rushiagr17:08
*** _cjones_ has quit IRC17:08
topolmarekd, good eye. I did not see it. its a long list17:08
marekdtopol: lots of cool stuff :-)17:09
topolgyee, I think that is a good idea. Need to understand how much work that is but I really like that idea17:09
topolgyee, I added to the summit session list17:11
nkinder_topol: yeah, I added the Horizon/Federation topic17:11
nkinder_topol: I'd like to sync up with you on that ahead of time17:12
topolnkinder_ do we need to clarify between Kerberos and non-Kerberos versions of Horizon/Federation?17:12
topolnkinder_  absolutely, we can syn up anytime17:13
nkinder_topol: Probably not.  I think we can come up with a single solution for both17:13
gyeetopol, thanks! auditing is easily the least understood and under appreciated component of AAA17:14
gyeeits like AAa17:14
marekdgyee: ++17:14
topolgyee,  we can certainly discuss what we need to do to enhance audit17:15
gyeeaudit and forensics17:16
*** rwsu has quit IRC17:17
*** harlowja_away is now known as harlowja17:19
topolgyee I was looking for something I can help code in Kilo.17:20
topolgyee sounds like you have some ideas17:20
*** _cjones_ has joined #openstack-keystone17:22
*** vhoward has joined #openstack-keystone17:23
gyeetopol, for one, I would love to have the ability to trace an API call17:23
*** amcrn has joined #openstack-keystone17:23
topolgyee, I added a section 15 to the summit session wiki if you want to add stuff to it17:24
topolgyee for audit17:24
*** stevemar has quit IRC17:31
*** stevemar has joined #openstack-keystone17:32
gyeetopol, k, I'll add. At the very least, on an update event, we need to know which fields were updated17:32
gyeeright now we are just sending a resource ID, which is not good enough17:32
*** rwsu has joined #openstack-keystone17:36
morganfainberggetting food finally should be back for the meeting, if not i might be a minute or two late17:37
topolgyee, cool. Sign me up17:40
*** jsavak has joined #openstack-keystone17:41
*** victsou has joined #openstack-keystone17:44
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/identity-api: API documentation for Hierarchical Multitenancy  https://review.openstack.org/11135517:45
stevemarjeez this list filled up fast -> https://etherpad.openstack.org/p/keystone-kilo-summit-sessions17:45
*** rushiagr is now known as rushiagr_away17:46
gyeeafaranha, welcome to the role management party, its more scary than you think :)17:49
gyeeafaranha, https://bugs.launchpad.net/keystone/+bug/890411 for starters17:49
uvirtbotLaunchpad bug 890411 in keystone "Tenant role conflicts/overlaps can be a security issue" [Medium,Invalid]17:49
*** joesavak has joined #openstack-keystone17:49
*** samuelmz has quit IRC17:49
stevemarwe really need some better CI for keystone :(17:52
*** jsavak has quit IRC17:52
dstanekstevemar: needs to be faster!17:55
stevemardstanek, sloth life - live slow, die whenever17:56
stevemari'll escort myself out now17:56
dstanekliving the sloth life17:57
raildostevemar, can I suggest some design session for Kilo in the etherpad?17:57
*** rushiagr_away is now known as rushiagr17:57
stevemarraildo, of course17:58
raildostevemar, great :)17:58
morganfainbergmeeetin time!17:59
*** joesavak has quit IRC18:02
*** zzzeek has quit IRC18:21
*** aix has quit IRC18:24
*** sigmavirus24_awa is now known as sigmavirus2418:25
*** rushiagr is now known as rushiagr_away18:30
*** henrynash has joined #openstack-keystone18:34
henrynashtahmina: you about?18:35
*** victsou has quit IRC18:46
*** Haneef has quit IRC18:48
morganfainbergdown to 10 "new" bugs in keystone https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New18:59
ayoungbknudson, morganfainberg, where do the commonclient folks hang out?19:01
lbragstadmorganfainberg: nice!19:01
ayoungin #openstack-sdk  ?19:02
*** ukalifon1 has quit IRC19:02
morganfainbergnkinder_, ping re: https://bugs.launchpad.net/keystone/+bug/1209343 is this specific to multi-backend LDAP or *all* ldap?19:03
uvirtbotLaunchpad bug 1209343 in keystone "Split backend does not provide ldap.set_option(ldap.OPT_X_TLS_CACERTFILE) for ldaps connections" [Wishlist,In progress]19:03
nkinder_morganfainberg: checking...19:03
morganfainbergbcause if it isn't *all* ldap it isn't needed for icehouse19:03
nkinder_morganfainberg: all19:04
nkinder_morganfainberg: that bug description should be changed19:04
morganfainbergnkinder_, can you do it or does a bug driver need to?19:04
morganfainbergnkinder_, if you can that would be great so we get the right info in it19:05
nkinder_morganfainberg: ah, I think "split" refers to identity/assignment19:05
nkinder_morganfainberg: I was thinking "multi" as well...19:05
morganfainbergotherwise let me know what i need to / should change19:05
morganfainbergbecause it would be good to tag to stable/icehouse if we need it19:05
lbragstadmorganfainberg: room subject is now out of date?19:05
morganfainbergthis room subject?19:05
morganfainbergnope, still valid till we hit RC.19:05
morganfainbergand middleware isn't released19:06
lbragstadmorganfainberg: do we have to go through all the 'juno-rc-potential' tags now too?19:06
nkinder_morganfainberg: bug summary updated19:06
morganfainberglbragstad, we should.19:07
nkinder_morganfainberg: I've already proposed it for stable/icehouse too19:07
morganfainbergnkinder_, i saw.19:07
morganfainberglbragstad, https://bugs.launchpad.net/keystone/+bugs?field.tag=juno-rc-potential19:07
lbragstadmorganfainberg: thanks19:07
lbragstadshould we add 'juno-backport-potential'?19:08
morganfainberguh we could.19:08
morganfainbergnkinder_, i tagged that bug to RC fyi19:08
*** _cjones_ has quit IRC19:08
nkinder_morganfainberg: ok, great19:08
dstanekmorganfainberg: checkout the last 2 comments on https://bugs.launchpad.net/keystone/+bug/135420819:08
morganfainbergnkinder_, it should land shortly.19:08
uvirtbotLaunchpad bug 1354208 in keystone/icehouse "[OSSA 2014-029] Catalog replacement allows reading config (CVE-2014-3621)" [Medium,Fix committed]19:08
nkinder_morganfainberg: yep, just waiting for the gate19:08
morganfainbergdstanek, oh fun19:09
morganfainbergdstanek, yeah i think we need another patchset that is icehouse specific :(19:09
morganfainbergor uh.. wat it says it merged to icehouse?19:10
dstanekmorganfainberg: i had a patch on icehouse already merge19:10
morganfainbergand havana has a merge19:10
morganfainbergso what is he asking?19:10
morganfainbergoh is that a recent "release" of stable?19:11
dstanekis 2014.1.2.1 a previous release of icehouse? that's how i read it19:11
morganfainberghe'd need to get the entire chain19:11
morganfainbergor repackage the patches.19:11
nkinder_ayoung: https://review.openstack.org/12354719:11
dstanekmorganfainberg: we had lots of churn there, so there may be lots of patches that would need to be included too19:12
morganfainbergnkinder_, bknudson, gyee, ayoung, https://bugs.launchpad.net/keystone/+bug/1358243 this one looks legitimate - makes sense. just trying to get it out of "new"19:12
uvirtbotLaunchpad bug 1358243 in keystone "LDAP Critical extension is unavailable 500 error " [Low,New]19:12
bknudsonmorganfainberg: if you don't want to get the error then don't set the page size19:12
bknudsonif you configure to ask for a page size then it seems like it should fail19:13
morganfainbergbknudson, works for me.19:13
morganfainbergbknudson, i would say this really does feel like a "dude you should know your ldap server's limits"19:13
bknudsonmaybe the docs could describe what's going to happen if you set it.19:13
morganfainbergi can tag it as a docfix instead19:13
dstanekbknudson: so thats configured on the server side to include page size on the query to LDAP?19:14
ayoungnkinder_, why does this require so many changes https://review.openstack.org/#/c/123547/1/spec/classes/keystone_spec.rb,cm  ?19:14
bknudsonI think so.. check into it19:14
nkinder_ayoung: those are tests19:14
ayoungnkinder_, were they not there before?19:15
morganfainbergayoung, https://bugs.launchpad.net/keystone/+bug/1208588 this looks like spec not bug (for sure).19:15
uvirtbotLaunchpad bug 1208588 in keystone "Support getting Auth attributes from Kerberos PAC" [Wishlist,New]19:15
nkinder_ayoung: because only a simple test was there to ensure that pki_setup wasn't run when token_provider=uuid19:15
nkinder_ayoung: now that we do run pki_setup, we have a matrix of things to check19:16
morganfainbergand something you're currently working on.19:16
ayoungnkinder_, but what about if token_provider=pki19:16
nkinder_ayoung: those are already there19:16
ayoungthat test was there or no?19:16
ayoungso no way to reuse the existing tests?19:16
nkinder_ayoung: there may be some ruby/spec magic to have a parameter that changes with test iterations19:17
nkinder_ayoung: I'm not sure how though19:17
ayoungok....we'll let the maintainer kick it back if there is a problem with duplication19:18
nkinder_ayoung: I figure a puppet expert will let me know19:18
*** Hillary_Effertz5 has joined #openstack-keystone19:20
richmyes, you can have a test that takes arguments19:21
richmsee keystone_spec.rb19:22
richmyou can run a test function in a loop, passing in different parameters each time19:23
richmallowing you to reuse test "functions"19:23
*** Hillary_Effertz5 has quit IRC19:25
nkinder_richm: hmm, let me see how I would apply that to my tests19:26
*** HenryG is now known as HenryG_afk19:27
*** samuelmz has joined #openstack-keystone19:28
gyeemorganfainberg, yes, we need to return a better error message19:28
nkinder_richm: ok, so take this test example - http://paste.openstack.org/show/114671/19:30
nkinder_richm: I want to have a version of it where token_format => 'UUID'19:30
nkinder_the expectations of the test are the same, but there is a nested test that refers to the PKI provider that woulld need to be the UUID provider if token_format is UUID19:32
gyeemorgainfainberg, bknudson, but seriously, that's low priority. They need to upgrade their LDAP server :)19:32
*** roock has quit IRC19:32
bknudsondstanek: oh, you were asking if the server can be configured to support paging or not? I think some servers do have this option19:33
gyeethat extension's been around for what, the last 15 years?19:34
nkinder_morganfainberg, gyee: It should check if paging is supported and skip the control19:34
nkinder_gyee: simple paged results?  Less than that for sure19:34
bknudsonyou can make the control non-critical and then it won't fail19:34
gyeenkinder_, I thought pagination support's been around for a long time19:34
bknudsonbut if the user asked for paging and we can't do it then it makes sense for it to fail.19:35
nkinder_gyee: there are different forms19:35
nkinder_gyee: VLV allowed paging, then that was deprecated19:35
nkinder_Simple Paged Results is the current way of doing paging19:35
gyeenkinder_, ah I see19:35
*** joesavak has joined #openstack-keystone19:36
bknudsonthere's all sorts of reasons to disable paging. it may be hard to implement efficiently / safely19:36
nkinder_gyee: I suppose it has been 15 years though...19:36
gyeeis there a way to discovery that stuff?19:36
bknudsoncan set yourself up for a DoS attack19:36
gyeevia API19:36
bknudsonrootDSE might have it19:36
openstackgerritA change was merged to openstack/keystone: Set LDAP certificate trust options for LDAPS and TLS  https://review.openstack.org/12095419:36
*** meera has quit IRC19:37
*** jsavak has joined #openstack-keystone19:37
gyeebknudson, but that's not a standard right?19:37
openstackgerritA change was merged to openstack/keystone: Add a pool of memcached clients  https://review.openstack.org/11945219:37
bknudsonI don't think there's a standard covering it19:37
*** meera has joined #openstack-keystone19:37
nkinder_gyee: search the rootDSE and look for "supportedControl"19:37
nkinder_AD has rootDSE too IIRC19:37
nkinder_It is a standard19:37
nkinder_gyee, bknudson: http://msdn.microsoft.com/en-us/library/ms684291%28v=vs.85%29.aspx19:38
bknudsonhttps://tools.ietf.org/html/rfc2251#section-3.4 -- maybe it is standard?19:38
nkinder_that answers the AD question19:38
bknudsonI guess it's right there in LDAPv3.19:38
nkinder_bknudson: yep, definitely a standard19:39
bknudsonsurprised because it seems like most useful things aren't standardized in ldap.19:39
*** _cjones_ has joined #openstack-keystone19:39
gyeenkinder_, nice! here's what I got from our AD19:39
gyeesupportedControl: 2.16.840.1.113730.3.4.1819:39
gyeesupportedControl: 2.16.840.1.113730.3.4.219:39
gyeesupportedControl: 1.2.840.113556.1.4.31919:39
gyeesupportedControl: 1.2.826.0.1.3344810.2.319:39
gyee# search result19:39
gyeesearch: 219:40
gyeeresult: 0 Success19:40
gyee# numResponses: 219:40
gyee# numEntries: 119:40
morganfainbergdstanek, is this still an issue: https://bugs.launchpad.net/python-keystoneclient/+bug/1260495 ?19:40
uvirtbotLaunchpad bug 1260495 in pbr "Setting autodoc_tree_index_modules makes documentation builds fail" [Undecided,In progress]19:40
*** joesavak has quit IRC19:40
morganfainbergdstanek, or can i mark it as "invalid" now.19:40
dstanekmorganfainberg: yes, it's still an issue19:40
*** _cjones_ has quit IRC19:40
dstanekmorganfainberg: let me run a quick test though19:40
morganfainbergdstanek, ok marked as confirmed19:41
*** _cjones_ has joined #openstack-keystone19:41
morganfainbergdstanek, close it if it isn't19:41
gyeegot the same list from m own OpenLDAP as well19:41
nkinder_gyee: 1.2.840.113556.1.4.319 is simple paged results19:41
nkinder_gyee: you wouldn't want to lookup the rootDSE every time you do a search though...19:42
bknudsonat least it's easy to remember :)19:42
bknudsonif it's optional then mark the server control as not critical19:43
gyeenkinder_, I mean we can query that information once at startup19:43
gyeeif server doesn't support the extension, they put a nice warning message in the log19:44
nkinder_gyee: yep, that would do just fine19:44
morganfainberglbragstad, ok lets do a quick once over on the RC-potentials19:44
morganfainberglbragstad, we are within 2 things merging to be RC ready, so we should make sure things aren't *actually* blockers19:44
morganfainberglbragstad, e.g. https://bugs.launchpad.net/keystone/+bug/137049219:44
uvirtbotLaunchpad bug 1370492 in keystone "calling curl "HEAD" ops time out on /v3/auth/tokens" [Medium,Confirmed]19:45
morganfainberglbragstad, so we have doc bugs, do we push those through for RC (mostly doc bugs are still open19:46
morganfainbergnkinder_, can i borrow you for a sec? :)19:47
nkinder_gyee, morganfainberg: Just added a comment to the LP with the recommended approach for a fix19:47
nkinder_morganfainberg: sure, what's up?19:47
morganfainbergnkinder_, https://review.openstack.org/#/c/118590/19:47
morganfainbergnkinder_, that is tagged as RC potential19:47
morganfainbergnkinder_, doing the last once over on RC blockers seeing if we need to get them in.19:48
nkinder_morganfainberg: Yeah, I've looked that one over in detail previously (and discussed it with the developer)19:49
morganfainbergnkinder_, i'm happy to move it out of RC potential, but this one I'm not getting the full story on19:50
nkinder_morganfainberg: my take is that much of it isn't really necessary19:50
nkinder_morganfainberg: so here's the deal...19:50
nkinder_We have the ability to create additional mappings.  This was added to allow keystone to supply required attributes during LDAP entry creation (to satisfy schema/objectclass requirements)19:50
morganfainbergthat much i'm familir with19:51
nkinder_morganfainberg: for example, if keystone uses 'uid' and 'cn' for 'id' and 'name', we might also need to supply 'sn' to satisfy LDAP19:51
nkinder_So much of this change is to require/expect those additional mapped attributes to be returned form a search request19:52
nkinder_So in the previous example, we would now request for uid, cn, and sn to be returned19:52
nkinder_even though we never use sn for anything19:52
nkinder_I don't think it's necessary19:52
morganfainbergnkinder_, ok i'll take the RC potential tag off, we can look into it being something we want in K, or even bits of it in K if that makes sense19:53
nkinder_morganfainberg: +119:53
nkinder_morganfainberg: there may be other stuff of value in there too though.  Let me finish giving it another once-over19:53
morganfainbergright not abandoning, just making it non-RC19:54
lbragstadmorganfainberg: on https://bugs.launchpad.net/keystone/+bug/137049219:55
uvirtbotLaunchpad bug 1370492 in keystone "calling curl "HEAD" ops time out on /v3/auth/tokens" [Medium,Confirmed]19:55
nkinder_morganfainberg: yeah, it's only adding validation for those additional mapped attribute.  I don't think it's needed at all, but we should discuss it further with the developer who proposed it.19:55
morganfainberglbragstad, that is the only thing on the RC list that worries me19:55
lbragstadI opened up an issue against WebOb19:55
morganfainberglbragstad, ok so we "can't" do anything about it?19:56
morganfainbergno workarounds?19:56
lbragstadmorganfainberg: not that I've discovered yet19:56
lbragstadbesides not doing HEAD requests ;)19:56
morganfainbergso.. we're "broken" in eventlet V3? since HEAD is used for token validation?19:57
bknudsonlbragstad morganfainberg: the curl command says don't do -X HEAD19:57
morganfainbergoh hah19:57
morganfainberg-X HEAD whoa19:57
lbragstadbknudson: where/19:57
bknudsonmorganfainberg: lbragstad: use -i or --head19:57
morganfainberghis option only changes the actual word used in the HTTP request, it does not alter the way curl behaves. So for example if you want to make a proper HEAD request, using -X HEAD will not suffice. You need to use the -I, --head option.19:58
bknudsonif there's a bug here it's in curl, which shouldn't allow -X HEAD19:58
openstackgerritDavid Stanek proposed a change to openstack/python-keystoneclient: Removes temporary fix for doc generation  https://review.openstack.org/12166719:58
* lbragstad sigh19:58
dstanekmorganfainberg: yeah still an issue19:58
morganfainbergdstanek, ok19:59
*** jsavak has quit IRC19:59
* lbragstad facepalm 19:59
morganfainberglbragstad, marking as invalid.19:59
dstanekmorganfainberg: i don't think anyone else believes me though19:59
morganfainberglbragstad, help me look ones more over the "new" bugs20:05
morganfainberglbragstad, i think these are all non-RC https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New20:05
morganfainbergdstanek, if it helps i belive you :)20:07
*** marcoemorais has quit IRC20:11
lbragstadmorganfainberg: thanks for marking invalid,20:12
lbragstadI updated with my comments and verified that --head works20:13
morganfainbergi did actually confirm it worked properly as well20:13
morganfainbergbefore makring invalid20:13
* lbragstad feels silly for not reading the man page20:13
bknudsonwebob could handle this better... dos if it leaves the connection open20:13
bknudsonor is it eventlet?20:13
morganfainbergbknudson, there is the greenlet issue too20:13
morganfainbergbknudson, yeah eventlet20:13
lbragstadmorganfainberg: https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New are all open, and non RC-blocking, right?20:14
morganfainberglbragstad, none look RC-blocky20:14
morganfainberglbragstad, but wanted a second pair of eyes on them20:14
bknudsonyou're asking for it if you put an eventlet server on the internet.20:14
lbragstadmorganfainberg: ok, checking20:14
morganfainbergbknudson, +++20:14
morganfainbergbknudson i mean we could disable keepalives :(20:14
*** amakarov has quit IRC20:17
*** radez is now known as radez_g0n320:18
lbragstadnkinder_: ayoung bknudson ldap question,20:20
lbragstadshould this be something we include for RC? https://bugs.launchpad.net/keystone/+bug/136602020:20
uvirtbotLaunchpad bug 1366020 in keystone "LDAP Identity does not convert ID to DN for lookup" [Undecided,New]20:20
*** amakarov has joined #openstack-keystone20:21
stevemarayoung, just finished reading the meeting logs, file bugs against OSC if you don't like the usability! please please20:22
samuelmzmorganfainberg, could you take a look at bug #1373113 and possibly confirm it?20:22
uvirtbotLaunchpad bug 1373113 in keystone "Wrong exception when deleting a domain group assignment using a not domain-aware backend" [Undecided,New] https://launchpad.net/bugs/137311320:22
*** zzzeek has joined #openstack-keystone20:23
rodrigodsmarekd, ping20:23
rodrigodsor stevemar =)20:23
*** amerine has joined #openstack-keystone20:23
stevemarrodrigods, pong20:24
rodrigodsstevemar, was taking a look at k2k patches, and didn't understand why this one was abandoned: https://review.openstack.org/#/c/104623/20:24
bknudsonlbragstad: there's no fixed proposed for it.20:25
rodrigodsdon't know much about websso, i guess20:25
mfischnkinder_ has the best commit messages20:26
*** gokrokve has quit IRC20:26
samuelmzlbragstad, ping20:26
nkinder_mfisch: I'm wordy... :)20:26
lbragstadbknudson: yeah, which is why I was asking. Would it be something we need to release20:26
morganfainbergsamuelmz, that looks legitimate20:26
*** gokrokve has joined #openstack-keystone20:26
mfischnkinder_: I'20:26
bknudsonlbragstad: consider how long we've been living with this I'd say no.20:27
mfischnkinder_: I'm +1 on both reviews and thanks for looking at it, having developers look at the puppet modules is a big help20:27
lbragstadbknudson: ok20:27
mfischthings (like what you changed) get missed20:27
nkinder_mfisch: awesome.  Thanks for the reviews!20:27
samuelmzmorganfainberg, ok I'm gonna fix this .. just need you to confirm it :-)20:27
nkinder_mfisch: richm has some out there for deploying keystone in httpd20:27
lbragstadbknudson: fair enough, wanted to run it by the ldap savvy guys20:27
nkinder_mfisch: not sure if you've looked at those, but that is important since httpd is the prefered deployment method now20:28
morganfainbergsamuelmz, go ahead and fix. the moment you post the code it'll go to "in progress"20:28
nkinder_mfisch: https://review.openstack.org/#/c/10967620:28
ayoungstevemar, I think the problem is not usability (there might be some of that) but that I have a broken install20:29
stevemarrodrigods, we decided we didn't need a whole just to save service providers - since it's just a name and url20:29
stevemarayoung, ahhh update to latest, got some new stuff in there20:29
marekdrodrigods: hello20:29
samuelmzmorganfainberg, ok thanks20:29
mfischnkinder_: I'll bring this up to colleen20:29
marekdrodrigods: looks like stevemar answered your questiong.20:29
stevemarayoung, but honestly if you find anything wrong let me know or file a bug, the more proponents we have for osc the better20:29
nkinder_mfisch: awesome, thanks20:30
rodrigodsayoung, I'm having issues as well. It works when I revert the session.Session commit20:30
stevemarayoung, i'll fix it double time20:30
ayoungstevemar, we should probably add --interactive and have a no-arg call be the same as -h20:30
ayounglbragstad, fire away  (was away from my desk)20:30
rodrigodsmarekd, stevemar, so... they will only be regions?20:31
nkinder_mfisch: if you don't mind, mention this related upstream puppetlabs change too - https://github.com/puppetlabs/puppetlabs-apache/pull/852/20:31
stevemarrodrigods, yep20:31
lbragstadayoung: was wondering if we should target https://bugs.launchpad.net/keystone/+bug/1366020 to a RC but, based on the above from bknudson, we're going to hold off.20:31
uvirtbotLaunchpad bug 1366020 in keystone "LDAP Identity does not convert ID to DN for lookup" [Undecided,New]20:31
rodrigodsstevemar, ahh ok, thanks =)20:31
*** amcrn has quit IRC20:32
*** gokrokve has quit IRC20:32
*** gokrokve has joined #openstack-keystone20:33
ayounglbragstad, yeah...I filed that one, and still not sure how I feel about it20:34
lbragstadayoung: we'll leave it as is for now20:35
*** marekd is now known as marekd|away20:45
*** marcoemorais has joined #openstack-keystone20:46
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/keystone: Fix exception delete domain group grant in LDAP  https://review.openstack.org/12358520:53
morganfainbergsamuelmz, i think we need a test for that as well20:55
morganfainbergsamuelmz, so we can make sure it doesn't crop back up20:55
mfischnkinder_: I've pinged the new community organizer person, she's giving a talk now I suspect. You can always drop by #puppet-openstack, we won't make you become a sysadmin or anything ;)20:57
ayoungstevemar, argparse comes from python-libs-2.7.5-11.fc20.x86_64  which is base Python...the error with the common client impliest an issue with python...are you testing 2.7 or 3.4?20:57
stevemarayoung, i am using 2.7 in my dev. env. but we gate against 2.7 and 3.320:58
morganfainbergmfisch, i'm still scared of being asked devopsy questions :P ;)21:00
morganfainbergmfisch, i mean >.> ....21:00
* mfisch nominates morganfainberg to give a talk on keystone at the next operators summit21:00
morganfainbergOH NOES!21:01
ayoungmfisch, he gets to do the STATE OF THE KEYSTONE talk!21:01
ayoungAssume he gets elected21:01
morganfainbergayoung, hey, that isn't a guarantee yet21:01
*** gokrokve has quit IRC21:01
mfischI've not received any bribes yet for votes21:01
ayoungbut everyone is saying "Not me!"21:01
mfisch+2s for votes21:01
morganfainbergayoung, i think it's a webcast these days not a "talk"21:01
*** meera has quit IRC21:02
*** meera has joined #openstack-keystone21:02
*** marcoemorais has quit IRC21:06
*** marcoemorais1 has joined #openstack-keystone21:06
*** stevemar has quit IRC21:13
ayoungbknudson, morganfainberg, lbragstad can you guys pie on this review https://review.openstack.org/#/c/120310/  for21:17
ayoungcreating the kerberos plugin repo21:17
bknudsonayoung: what's it for? Is there code already?21:18
ayounglet me bug ttx21:18
*** gordc has quit IRC21:20
morganfainbergayoung, they're mostly waiting for dolphs "yep" on it afaict.21:23
ayoungmorganfainberg, yeah21:23
ayoungmorganfainberg, looking for the IRC log where he gave it the thumbs up21:23
ayoungmust not have been in a meeting21:23
bknudsonthey were asking dolphm to +1 it21:23
*** vhoward has left #openstack-keystone21:24
samuelmzmorganfainberg, yes sure ... tests are coming with the patch for bug #136748021:25
uvirtbotLaunchpad bug 1367480 in keystone "Add test for grant CRUD on test_backend" [Low,Confirmed] https://launchpad.net/bugs/136748021:25
*** arosen has joined #openstack-keystone21:33
ayoungmorganfainberg, do you recall when we made the decision to go with a separate repo?21:33
morganfainberguh, was right around the time jamie posted those21:33
arosendtroyer: any idea about this? http://paste.openstack.org/show/114705/21:33
ayoungmust have been 2014-09-0921:34
dtroyerarosen: first SWAG would be that SessionStore is not actually a Session, which is what has the request method21:38
ayoungdo we need a bug number for recheck now?21:38
morganfainbergayoung no.21:38
dtroyerarosen:  I don't know what SessionStore is, it sounds like a container for Session objects maybe?21:39
*** zzzeek has quit IRC21:40
arosendtroyer:  ah right it isn't.  I'm running into an issue getting the congressclient hooked into keystone without hardcoding the creds there21:41
*** andreaf has quit IRC21:41
*** andreaf has joined #openstack-keystone21:42
dtroyerarosen: as an OSC plugin or standalone?21:42
arosendtroyer:  standalone, the osc part just buys us the cli bits.21:42
*** _cjones_ has quit IRC21:43
*** _cjones_ has joined #openstack-keystone21:44
*** amcrn has joined #openstack-keystone21:44
*** zzzeek has joined #openstack-keystone21:44
dtroyerOSC also gives you an authenticated session…so right now doing it standalone means managing which auth plugin to use.  I'm sure there is abetter way but you can brute-force it like in https://github.com/dtroyer/python-openstackclient/blob/master/openstackclient/common/clientmanager.py#L9621:44
dtroyerwe're planning to replace that with https://review.openstack.org/#/c/108325/ soon...21:45
dtroyerwhich is a better model to follow21:45
*** topol has quit IRC21:46
*** _cjones_ has quit IRC21:48
*** _cjones_ has joined #openstack-keystone21:48
*** meera has quit IRC21:50
*** rkofman has quit IRC21:54
morganfainbergtentative release schedule for Kilo: https://docs.google.com/spreadsheets/d/1Ypxkvsfth0DHsDKlPhsjtHaM4zJ_f9sdDgr3pArZEdY/edit#gid=35379708921:54
*** rkofman has joined #openstack-keystone21:55
bknudsonwe haven't even gotten Juno out the door yet21:55
*** nkinder_ has quit IRC21:56
morganfainbergyep. but we're not having a whole summit session in paris dedicated to this21:56
morganfainberginstead we're hammering it out on the ML and in IRC before the summit21:56
morganfainbergthis does mean the L cycle will likely be a short cycle (up to 3wks shorter)21:57
*** jasondotstar has quit IRC21:57
bknudsonnow we're talking about L?21:57
morganfainbergbknudson, if we set the K cycle at that schedule, L will be short.21:58
*** harlowja is now known as harlowja_away22:01
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/keystone: Add test for grant CRUD on assignment backend  https://review.openstack.org/12359022:03
samuelmzmorganfainberg, ^22:03
morganfainbergsamuelmz, thanks!22:03
samuelmzmorganfainberg, :-)22:03
*** harlowja_away is now known as harlowja22:03
*** miqui has quit IRC22:04
*** samuelmz is now known as samuelmz-away22:04
*** Tahmina has joined #openstack-keystone22:06
*** gokrokve has joined #openstack-keystone22:06
*** bknudson has quit IRC22:07
*** sigmavirus24 is now known as sigmavirus24_awa22:17
*** zzzeek has quit IRC22:21
*** amerine has quit IRC22:22
*** zzzeek has joined #openstack-keystone22:24
*** amerine has joined #openstack-keystone22:26
*** ayoung has quit IRC22:28
*** jorge_munoz has quit IRC22:31
*** openstackgerrit has quit IRC22:31
*** openstackgerrit has joined #openstack-keystone22:31
openstackgerritA change was merged to openstack/python-keystoneclient: Stop using intersphinx  https://review.openstack.org/12131122:35
*** amerine has quit IRC22:42
*** amerine has joined #openstack-keystone22:44
*** nkinder_ has joined #openstack-keystone22:47
*** dims has quit IRC22:53
*** dims has joined #openstack-keystone22:54
*** dims has quit IRC22:59
*** marcoemorais1 has quit IRC23:07
*** marcoemorais has joined #openstack-keystone23:08
*** jimbaker has quit IRC23:12
*** jimbaker has joined #openstack-keystone23:12
*** jimbaker has quit IRC23:12
*** jimbaker has joined #openstack-keystone23:12
*** andreaf has quit IRC23:13
*** andreaf has joined #openstack-keystone23:14
*** andreaf has quit IRC23:15
*** gokrokve_ has joined #openstack-keystone23:19
*** dims has joined #openstack-keystone23:19
*** david-lyle has quit IRC23:20
*** gokrokve has quit IRC23:21
*** dhellmann has quit IRC23:21
*** dhellmann has joined #openstack-keystone23:21
*** david-lyle has joined #openstack-keystone23:21
*** david-lyle has quit IRC23:26
*** samuelmz-away has quit IRC23:27
*** openstackgerrit_ has joined #openstack-keystone23:28
*** ayoung has joined #openstack-keystone23:31
*** samuelmz-away has joined #openstack-keystone23:34
*** Joshua_Hodkiewic has joined #openstack-keystone23:39
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Prevent infinite recursion on persistence core on init  https://review.openstack.org/12361223:43
morganfainbergdstanek, gyee, henrynash, dolphm, ayoung, lbragstad, ^23:44
morganfainbergbug reported that needs to be fixed prior to RC, it's a simple fix, confirmed it locally and that the fix works.23:44
dstanekmorganfainberg: wow,  didn't know that was a problem; sounds bad23:44
*** Joshua_Hodkiewic has quit IRC23:45
morganfainbergdstanek, it doesn't crash keystone or anything just spews recursive calls a lot23:45
morganfainbergdstanek, and then it will eventually stabilize, it's a bad thing™ but doesn't really break things too badly23:45
morganfainbergbut it' stacks up a few thousand calls in a loop on keystone start23:45
morganfainberggyee, yeah haneef and arun found it23:46
morganfainbergsince it's code that will be removed in about oh.. 1 day, i figure it's ok not to have a string in the AttributeError() raise23:47
gyeek :)23:48
*** Alexane_Metz has joined #openstack-keystone23:51
*** alex_xu has joined #openstack-keystone23:51
morganfainberggyee, not sure it really warrants a unit test, i can if you want it.23:56
morganfainberggyee, it's just mock .assert_called_with and a count23:56
gyeemorganfainberg, if this's just temporary code then probably not worth the time23:57
morganfainberggyee, yeah it's basically just for Juno to print that nice deprecation warning23:57
morganfainberg"hey don't use token_api"23:57
gyeemorganfainberg, k, let me change my vote then23:57
morganfainbergadded a new item to the summit list "Dependency Injection: Fix it"23:58
*** marcoemorais has quit IRC23:58
*** marcoemorais has joined #openstack-keystone23:59

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