Wednesday, 2014-09-10

*** oomichi has quit IRC00:00
*** amerine has quit IRC00:00
jamielennoxayoung: can you take a look at https://review.openstack.org/#/c/117709/00:00
gyeejamielennox, you have more for me?00:02
jamielennoxgyee: https://review.openstack.org/#/c/118520/ again it had a +A and needed a rebase00:02
jamielennoxit's currently got a transient -1 from jenkins but if i do a recheck it'll be 4 hours00:02
*** david-lyle has quit IRC00:05
gyeejamielennox, I don't understand the wisdom behind that one00:06
jamielennoxgyee: sure00:06
gyeeso we have two ways of getting user_id and project_id?00:06
gyeeone from the plugin and the other from access_info?00:06
*** gordc has quit IRC00:07
jamielennoxso access_info is mostly an implementation detail of Identity plugins00:07
jamielennoxwe shouldn't restrict this to only working with keystone auth00:07
jamielennox(thinking pure SSL certs and the like for auth)00:07
*** jimhoagland has quit IRC00:07
gyeek, you have me at SSL00:08
jamielennoxthere are certain commands like change my own password where you have to be able to retrieve the user id from the auth plugin to construct the URL00:08
*** amerine has joined #openstack-keystone00:08
jamielennoxto me this is broken, you shouldn't need to specify your own information in the URL, however that's what we have now00:08
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Adds hint about filter placement to extension docs  https://review.openstack.org/11983400:09
*** cjellick has quit IRC00:09
jamielennoxso i don't want to give people access to everything, but if there is a way to determine user_id from the auth plugin then i guess it's better to allow the plugin to expose it00:09
gyeeI hear ya00:09
*** gokrokve has quit IRC00:10
gyeechanging password is update_use right now00:10
gyeeupdate_user00:10
jamielennoxso i have this in a later review: https://review.openstack.org/#/c/97681/30/keystoneclient/httpclient.py00:10
jamielennoxa user_id property that does its best to figure out the user_id and i've already seen this being replicated in other projects that need the user_id for whatever reason00:11
ayoungjamielennox, looking00:12
jamielennoxsame with project_id. i need it in to be exposed so that for those stupid apis that have /v1/{project_id}/ in the url i can construct it00:12
jamielennoxgyee: anyway - i agree, i never wanted to expose that information at the base plugin level - i'm just not sure what else to do00:13
ayoung+A00:14
jamielennoxayoung: thanks, should mean i can rebase a few things now so they aren't all queued up00:15
*** ncoghlan is now known as ncoghlan_afk00:16
jamielennoxnow we pray and offer sacrifice to zuul so that this actually merges00:17
*** gyee is now known as zuul00:18
zuuljamielennox, what do you have for me?00:18
jamielennoxzuul: you appear much easier to bribe now00:18
*** zuul is now known as gyee00:18
jamielennoxs/bribe/offering obviously00:18
gyee:)00:19
jamielennoxgyee: so if you aren't sure about that one put a -1 on it00:19
jamielennoxi can work around that one until i have some more evidence00:20
gyeestill thinking over it00:20
jamielennoxfor new code, i think this is exciting: https://review.openstack.org/#/c/107222/00:21
jamielennoxactually did that service_token stuff merge? i might have to rebase that00:22
jamielennoxayoung: https://review.openstack.org/#/c/119261/00:23
gyeejamielennox, so the plugin can get that information from the token right? or are we envisioning a scenario where we don't operate on tokens?00:29
jamielennoxgyee: the auth_token one?00:29
gyeeeven with SSL, we are still getting a token00:29
gyeeyes00:29
jamielennoxauth_token is keystone specific and should always be00:29
*** ncoghlan_afk is now known as ncoghlan00:30
jamielennoxif you want to do something else there then i think you replace auth_token with something else00:30
jamielennoxopening that up to non-keystone auth methods is just too hard00:30
gyeejamielennox, k, why do we need these then https://review.openstack.org/#/c/118520/3/keystoneclient/auth/base.py00:33
gyeewe can just get those from access_info right?00:33
jamielennoxgyee: sure, in the auth_token case we can do that or use the headers00:34
gyeeget_token()00:34
gyeeidentity.base.BaseIdentityPlugin.get_token_ref()00:35
jamielennoxwhat do you mean?00:36
gyeeI mean I can get user_id and project_id from get_token_ref()00:37
jamielennoxassuming you have get_token_ref00:37
jamielennox(i think it's get_auth_ref or get_access)00:37
gyeeright00:37
jamielennoxthat's limited to identity plugins00:37
gyeecan't we move get_token_ref to base?00:38
gyeesince we assume we are working with keystone tokens00:38
gyeeif they are designed to be generic then I would think we need more than just user_id and project_id00:39
jamielennoxi possibly made it hard for myself by ever allowing an auth plugin that wasn't a keystone plugin00:39
gyeenah, its a noble thing00:40
jamielennoxbut given that we have the distinction i don't think so because you can only construct an AccessInfo from the keystone token data00:40
gyeenot really, AccessInfo is just a dict, a plugin can populate it with their own auth context00:41
gyeeits basically identity attributes00:42
jamielennoxso take the TokenEndpoint plugin - which is essentially the only thing we have ATM which isn't an identity plugin00:42
jamielennoxi don't know how i could construct an AccessInfo from that that would make sense00:43
*** stevemar has joined #openstack-keystone00:43
jamielennoxso here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v2_0/shell.py#L34700:44
jamielennoxactually here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v2_0/shell.py#L36200:44
jamielennoxi don't know how to do this fallback to auth_user_id generically00:45
*** Ephur has quit IRC00:46
*** russellb has quit IRC00:46
gyeeFor TokenEndpoint, we may just need to make an extra call to validate the token to get the access info00:47
jamielennoxwhat if it's an ADMIN_TOKEN00:47
gyeesound crazy, but it'll cleaner00:47
gyeethen error out00:47
gyeeno body uses ADMIN_TOKEN to list roles00:48
jamielennoxactually i have that bug in bugzilla right now00:48
gyeeADMIN_TOKEN is for bootstrapping purposes only00:49
jamielennoxbecause OS_ENDPOINT and OS_SERVICE_TOKEN take priority in the cli00:49
gyeeit should not be (ab)use for anything else00:49
*** russellb has joined #openstack-keystone00:49
jamielennoxso the admin guide says do all this stuff to create a user00:49
*** Ephur has joined #openstack-keystone00:49
jamielennoxthen source the new rc file00:49
gyeewe need to change that00:49
jamielennoxhowever that doesn't unset the old variables and it's a weird error that's returned00:49
*** gokrokve has joined #openstack-keystone00:50
jamielennoxanyway, we can leave that one for now00:51
jamielennoxi can implement it locally for what i need in keystoneclient and then we'll wait and see where else it's needed00:51
gyeehttps://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L700:52
gyee"This "token" does not represent a user" :)00:52
gyeeso we should rightfully error out if that token is used to request any "user" data00:52
gyeek, man00:53
gyeegym time00:53
jamielennoxgyee: ok - have fun, thanks00:53
*** gyee has quit IRC00:55
*** hrybacki has joined #openstack-keystone01:06
jamielennoxmorganfainberg: is experimental job better/worse that a non-voting check job?01:14
morganfainbergbetter01:14
*** dims_ has joined #openstack-keystone01:14
morganfainbergit doesn't consume resources unless you explicitly trigger it01:14
jamielennoxok - that's probably what we should do for all these server side python3 jobs01:15
morganfainberg++01:15
morganfainbergpy34 now01:15
jamielennox... if we make a new project with no data with python tox jobs - is that going to be an issue? or we just need to fix it on first run?01:16
jamielennoxs/run/commit01:16
jamielennoxmaybe i should populate a repo first01:18
morganfainbergjamielennox, hm.01:18
morganfainbergjamielennox, i think it doesn't matter, first commit needs to have it though01:18
*** ncoghlan is now known as ncoghlan_afk01:27
*** oomichi has joined #openstack-keystone01:35
ayoungmorganfainberg, you seem insistant that it is python34.  What is the real difference?01:35
ayoungjamielennox, BTW, I got a response back from one of the apple devs over python-kerberos.01:35
jamielennoxayoung: you  mentioned briefly but no details about what they said01:36
ayoungjamielennox, bascially he said "file tickets and also tell what are your blockers."01:36
ayounghttp://trac.calendarserver.org/report/1?sort=component&asc=1&page=201:37
ayoungso...lets see if they do something about the patches carried by Fedora01:37
ayoungbig thing is first they need a new release...considering the fork called their 1.1.5  I wonder what these guys will number it as...01:38
jamielennoxprobably doesn't matter01:39
jamielennoxthey haven't had a release in years - how active is it?01:39
*** gokrokve_ has joined #openstack-keystone01:40
*** gokrokve has quit IRC01:41
jamielennoxi'm not a github fanbuy but it has certainly made things easier01:41
morganfainbergayoung, py34 has minor changes iirc01:43
morganfainbergayoung, but infra is stopping supporting py33 that is why it's important to be p3401:43
ayoungmorganfainberg, makes no real difference to me, so long as we have a reasonable chance of hitting something.01:45
*** gokrokve has joined #openstack-keystone01:48
*** gokrokve_ has quit IRC01:48
*** gus has quit IRC01:49
*** gus has joined #openstack-keystone01:51
*** amcrn has quit IRC01:55
*** r-daneel has quit IRC02:02
jamielennoxayoung: so i can see patches for python302:03
jamielennoxhttp://trac.calendarserver.org/ticket/79802:03
jamielennoxthough it's not commitd02:03
*** fifieldt_ is now known as fifieldt02:03
*** marcoemorais has quit IRC02:20
*** ayoung has quit IRC02:24
openstackgerritRichard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported  https://review.openstack.org/7489702:24
*** harlowja is now known as harlowja_away02:25
*** diegows has quit IRC02:26
*** richm has quit IRC02:29
*** ncoghlan_afk is now known as ncoghlan02:35
*** hrybacki has quit IRC02:52
*** jimbaker has quit IRC02:58
*** KanagarajM has joined #openstack-keystone03:00
*** jimbaker has joined #openstack-keystone03:00
*** dims_ has quit IRC03:01
*** dims_ has joined #openstack-keystone03:01
*** wanghong has quit IRC03:05
*** dguitarbite has quit IRC03:12
*** dims_ has quit IRC03:14
*** dims_ has joined #openstack-keystone03:15
*** dims_ has quit IRC03:19
*** alex_xu has joined #openstack-keystone03:21
*** meker12 has quit IRC03:31
stevemarman bknudson just made the most awesome change to devstcak03:34
stevemarhaving that extra screen for the access logs, freakin awesome03:34
*** wwriverrat has joined #openstack-keystone03:39
Morgan_stevemar: hehe04:00
stevemarMorgan_, i was just about to type :O04:00
stevemarjamielennox, i'm a fan of that slide deck you shared about federation :)04:00
jamielennoxstevemar: glad you liked it, it borrowed a lot from the one you guys did at atlanta04:01
jamielennoxand showed of my skills as an artist :)04:01
stevemarjamielennox, saw some bits that looks familiar, but i've had to present it a bunch of times now, it all starts to blur04:02
stevemari saw! i'm going to have to borrow the diagram you have with apache04:02
stevemarjamielennox, could you send it to me? I don't want to have to create a slideshare account just to download :(04:03
jamielennoxit's been a while since i've had to do that sort of stuff, it's all online javascript and css stuff04:03
jamielennoxslideshare makes you do that?04:04
jamielennoxyou want the pics or the pdf?04:04
jamielennoxstevemar: https://fedorapeople.org/~jamielennox/federation.pdf is the pdf04:07
jamielennoxstevemar: https://www.dropbox.com/sh/g3jz0v36p7ktd0m/AADd5m1whhHQIUJCOnLVa2F7a?dl=0 for all the bits04:09
stevemarjamielennox, pdf is good enough, thanks sir04:09
stevemarthat works too04:10
*** amerine_ has joined #openstack-keystone04:10
*** amerine has quit IRC04:11
jamielennoxstevemar: https://review.openstack.org/#/c/120104/1 gives me:04:12
jamielennoxImportError: Start directory is not importable: './python-keystoneclient/tests'04:12
*** ncoghlan is now known as ncoghlan_afk04:13
stevemarjamielennox, ahhh! right because it tries to find the name by doing: PACKAGENAME=$(python setup.py --name)04:14
jamielennoxyep04:14
jamielennoxjust looking and i can't see anything in setup.py that will give just keystoneclient04:14
stevemarshoot04:15
stevemarworks for keystone/keystonemiddleware/pycadf and ceilometer04:16
stevemar*grumble grumble*04:16
jamielennoxstill, funny that none of the clients have noticed this04:16
jamielennoxa sed rule perhaps?04:16
stevemar mmmaybe04:17
stevemari wonder if i can just hack it and chop off the 'python-' bits if that comes up04:19
*** amerine_ has quit IRC04:19
*** ncoghlan_afk is now known as ncoghlan04:20
*** amerine has joined #openstack-keystone04:20
*** jorge_munoz has joined #openstack-keystone04:23
jamielennoxstevemar: that or i guess accept an environment variable if provided to the script04:25
stevemarjamielennox, oh thats more elegant :)04:25
jamielennoxstevemar: actually a --module-name would be better than an env04:27
jamielennoxor --test-dir04:27
stevemarjamielennox, i'm blanking on how to make the -- thing happen, but i got it working with a positional argument04:38
*** rushiagr_away is now known as rushiagr04:40
stevemarjamielennox, if you are interested: https://review.openstack.org/12031604:43
stevemarjamielennox, it would mean changing the proposed change to: commands = oslo_debug_helper.sh keystoneclient {posargs}04:44
stevemarbah, have to make it $2, not $1, thats for the tests!04:47
*** ajayaa has joined #openstack-keystone04:51
*** vhoward has joined #openstack-keystone04:58
*** ncoghlan is now known as ncoghlan_afk05:02
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Use oslo_debug_helper and remove our own version  https://review.openstack.org/12010405:04
stevemarjamielennox, welp, best i can think of at this hour: https://review.openstack.org/#/c/120316/05:13
*** wanghong has joined #openstack-keystone05:14
*** ncoghlan_afk is now known as ncoghlan05:19
*** afazekas_ has joined #openstack-keystone05:27
*** dguitarbite has joined #openstack-keystone05:30
*** k4n0 has joined #openstack-keystone05:45
*** stevemar has quit IRC05:49
*** jimhoagland has joined #openstack-keystone05:55
*** jimhoagland has quit IRC06:01
openstackgerritSasikanth Eda proposed a change to openstack/keystone: Fix user-role-add in LDAP backend  https://review.openstack.org/11934506:22
*** jaosorior has joined #openstack-keystone06:25
*** gokrokve has quit IRC06:29
*** ajayaa has quit IRC06:30
*** ajayaa has joined #openstack-keystone06:39
*** rushiagr is now known as rushiagr_away06:48
*** rushiagr_away is now known as rushiagr06:49
*** jimhoagland has joined #openstack-keystone06:55
*** gokrokve has joined #openstack-keystone06:56
*** gokrokve has quit IRC06:59
*** gokrokve has joined #openstack-keystone07:00
*** jimhoagland has quit IRC07:00
*** gokrokve has quit IRC07:05
*** k4n0 has quit IRC07:07
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Removed keystoneclient.apiclient  https://review.openstack.org/10792607:19
*** ukalifon1 has joined #openstack-keystone07:21
*** k4n0 has joined #openstack-keystone07:22
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/11162007:26
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/11625507:31
*** wanghong has quit IRC07:32
*** henrynash has joined #openstack-keystone07:34
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/11162007:34
*** jorge_munoz has quit IRC07:37
*** wanghong has joined #openstack-keystone07:44
openstackgerritwanghong proposed a change to openstack/keystonemiddleware: correct docstring  https://review.openstack.org/12033307:49
*** BAKfr has joined #openstack-keystone07:55
*** jimhoagland has joined #openstack-keystone07:55
*** bvandenh has joined #openstack-keystone07:57
*** jimhoagland has quit IRC08:00
*** gokrokve has joined #openstack-keystone08:00
*** gokrokve has quit IRC08:05
mfloboSome good tutorial to enable LiveLDAP on devstack, please?08:05
*** wanghong has quit IRC08:07
*** ncoghlan has quit IRC08:11
openstackgerritYuriy Taraday proposed a change to openstack/keystone: Added config value for cache backend arguments  https://review.openstack.org/12034008:20
openstackgerritYuriy Taraday proposed a change to openstack/keystone: Add a pool of memcached clients  https://review.openstack.org/11945208:21
bjornarI keep seeing "mysql server has gone away" in master...08:24
*** wanghong has joined #openstack-keystone08:25
*** bdossant has joined #openstack-keystone08:33
openstackgerritA change was merged to openstack/python-keystoneclient: Distinguish between name not provided and incorrect  https://review.openstack.org/11590308:44
*** jimhoagland has joined #openstack-keystone08:55
*** jimhoagland has quit IRC09:00
*** gokrokve has joined #openstack-keystone09:00
*** gokrokve has quit IRC09:05
*** rushiagr is now known as rushiagr_away09:18
*** rushiagr_away is now known as rushiagr09:18
*** x-eye has quit IRC09:21
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Keystone part of a PoC for Horizon/Keystone WebSSO  https://review.openstack.org/10609609:26
*** Xeye has joined #openstack-keystone09:27
*** aix has quit IRC09:47
*** alex_xu has quit IRC09:48
*** jimhoagland has joined #openstack-keystone09:55
*** jimhoagland has quit IRC10:00
*** gokrokve has joined #openstack-keystone10:00
*** gokrokve has quit IRC10:01
*** Bharat_Kobagana has joined #openstack-keystone10:02
*** gokrokve has joined #openstack-keystone10:02
*** gokrokve has quit IRC10:07
*** bvandenh has quit IRC10:07
*** Bharat_Kobagana is now known as bharat_kobagana10:10
*** amakarov has joined #openstack-keystone10:11
*** aix has joined #openstack-keystone10:21
openstackgerritAlexander Makarov proposed a change to openstack/keystone: PKI and PKIZ tokens unnecessary whitespace removed  https://review.openstack.org/12004310:23
*** alex_xu has joined #openstack-keystone10:32
*** garnav has joined #openstack-keystone10:40
*** diegows has joined #openstack-keystone10:47
*** dims_ has joined #openstack-keystone10:57
*** bvandenh has joined #openstack-keystone10:58
*** miqui has quit IRC11:00
*** gokrokve has joined #openstack-keystone11:00
*** bharat_kobagana has left #openstack-keystone11:03
*** gokrokve has quit IRC11:05
*** dims_ has quit IRC11:21
*** dims_ has joined #openstack-keystone11:21
*** dims__ has joined #openstack-keystone11:22
*** topol has joined #openstack-keystone11:23
*** dims_ has quit IRC11:25
*** ekarlso- has quit IRC11:37
*** ekarlso- has joined #openstack-keystone11:37
*** KanagarajM has quit IRC11:46
*** jimhoagland has joined #openstack-keystone11:55
openstackgerritA change was merged to openstack/keystone: Fixed typo 'in sane manner' to 'in a sane manner'  https://review.openstack.org/11790211:59
*** jimhoagland has quit IRC12:00
*** gokrokve has joined #openstack-keystone12:00
*** gokrokve has quit IRC12:05
*** samuelmz-zzz is now known as samuelmz12:11
samuelmzDoes 'identity' in test_v3_identity mean the identity api or does it mean the identity component, as for assignment?12:13
*** hrybacki has joined #openstack-keystone12:27
openstackgerritVictor Sergeyev proposed a change to openstack/keystone: Remove of using session in migration 042  https://review.openstack.org/12014612:27
*** hrybacki has quit IRC12:31
*** dims__ has quit IRC12:34
*** dims_ has joined #openstack-keystone12:35
*** dims_ has quit IRC12:38
*** dims_ has joined #openstack-keystone12:38
*** radez_g0n3 is now known as radez12:43
*** gordc has joined #openstack-keystone12:45
*** hrybacki has joined #openstack-keystone12:47
*** KanagarajM has joined #openstack-keystone12:49
*** oomichi has quit IRC12:54
*** jimhoagland has joined #openstack-keystone12:55
*** gokrokve has joined #openstack-keystone13:00
*** jimhoagland has quit IRC13:00
*** afazekas_ has quit IRC13:01
*** aix has quit IRC13:02
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Add a simple module to work with filters and DNs to LDAP backend  https://review.openstack.org/11748413:03
*** aix has joined #openstack-keystone13:04
*** gokrokve has quit IRC13:05
*** richm1 has joined #openstack-keystone13:07
*** joesavak has joined #openstack-keystone13:12
*** nkinder has quit IRC13:13
*** saipandi has joined #openstack-keystone13:16
*** afazekas_ has joined #openstack-keystone13:16
*** jimhoagland has joined #openstack-keystone13:19
*** jsavak has joined #openstack-keystone13:23
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Add a simple module to work with filters and DNs to LDAP backend  https://review.openstack.org/11748413:24
*** joesavak has quit IRC13:25
*** ayoung has joined #openstack-keystone13:29
*** bknudson has joined #openstack-keystone13:34
*** bdossant has quit IRC13:37
*** hrybacki has quit IRC13:49
ekarlso-so can anyone tell my why ksclient doesn't pickup cacerts installed systemwide ?13:57
dolphmsamuelmz: it's intended to be identity-related API calls, like those on /v3/users13:59
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Templated catalog backend not implemented  https://review.openstack.org/12001114:00
dolphmsamuelmz: a bunch of authz tests ended up in there, which should be pulled out in test_v3_assignments but such a file does not exist :)14:00
samuelmzdolphm, yeah that's the point14:00
*** gokrokve has joined #openstack-keystone14:00
samuelmzdolphm, I'd be glad to make this refactoring14:00
dolphmsamuelmz: awesome, please do!14:01
samuelmzdolphm, in addition, we have all grant/assignment tests there14:01
samuelmzdolphm, :-)14:01
dolphmsamuelmz: ++14:01
*** gokrokve has quit IRC14:02
*** gokrokve has joined #openstack-keystone14:02
*** nkinder has joined #openstack-keystone14:03
*** gabriel-bezerra has quit IRC14:03
*** sigmavirus24_awa is now known as sigmavirus2414:04
*** stevemar has joined #openstack-keystone14:05
*** afazekas_ has quit IRC14:08
*** jimhoagland has quit IRC14:16
samuelmzdolphm, identity -> domains, projects, users, groups and roles14:23
samuelmzdolphm, assignment -> grants/role assignments14:24
samuelmzdolphm, right?14:24
dolphmsamuelmz: users and groups are in identity, everything else there is in assignment14:24
*** ajayaa has quit IRC14:24
samuelmzdolphm, ok14:26
*** rwsu has joined #openstack-keystone14:30
openstackgerritDolph Mathews proposed a change to openstack/keystone: improve dependency injection doc strings  https://review.openstack.org/12043814:34
samuelmzdolphm, https://bugs.launchpad.net/keystone/+bug/136777814:38
uvirtbotLaunchpad bug 1367778 in keystone "Extract Assignment related tests from IdentityTestCase" [Undecided,New]14:38
*** dhellmann is now known as dhellmann_14:39
*** dhellmann_ is now known as dhellmann14:40
*** rwsu has quit IRC14:48
*** david-lyle has joined #openstack-keystone14:51
ayoungrm_work, you should not have  LBaaS create a trust for a user.  It is actually going to be impossible for you to do except under the most trivial of situations14:51
ayoungnamely,  only if the user requests something of the LBaaServer directly.  But HEAT is going to be working off of Trust tokens, and a trust token cannot create a new trust14:52
ayoungsamuelmz, domains are enumerated in the assignment backend, but identity subdivieds along domain lines.  So each groups and user HAS-A domain assigned14:55
ayoungRoles are a global set of strings.  Role assignements are a tuple of (<identity>, role, <target>)  with identity being user or group, and target being domain or project14:56
dolphmayoung: can you create a trust with yourself?14:57
ayoungso while a user maintained inside exactly one domain, it can also have roles in other domains, or in projects in other domains14:57
ayoungdolphm, I think so14:57
ayoungI have not tried it, but I have not prevented it, and I often think it would be super useful14:57
ayoungdolphm, let me try....14:57
*** wwriverrat has quit IRC14:57
dolphmayoung: and trusts are not mutable, correct?14:57
ayoungdolphm, correct14:58
*** jimhoagland has joined #openstack-keystone14:58
ayoungdolphm, have I showed you the javascript prototype yet?14:58
dolphmayoung: no - i'm documenting https://bugs.launchpad.net/ossn/+bug/1331882 for the OSSN at the moment though14:58
uvirtbotLaunchpad bug 1331882 in keystone "trustor_user_id not available in v2 trust token" [Wishlist,In progress]14:58
ayoungdolphm, OK,  we should set aside some time for me to walk you through it.  It leads to the whole  CORS discussion we had earlier, and also a better approach for Horizon to Keystone integration.14:59
ayoungI'm planning on adding trusts to the prototype, but I have not done so yet14:59
ayoungbut for now...14:59
dolphmayoung: are trusts deletable through the API?15:00
ayoungyes15:00
dolphmayoung: and do v2 trust tokens contain the trust ID?15:00
ayoungyes...I am pretty sure, let me confirm15:01
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py#n87   dolphm yes it does15:01
ayoungdolphm, we missed the trustor_id, but the trustee_id and the trust_id are both in the token15:02
*** jimhoagland has quit IRC15:07
morganfainbergmornin15:09
topolWhats up15:11
*** morganfainberg is now known as morgan15:12
*** jimhoagland has joined #openstack-keystone15:13
*** morgan is now known as Morgan15:13
*** annasort has quit IRC15:14
*** Morgan is now known as morgan15:15
*** aix has quit IRC15:17
*** cjellick has joined #openstack-keystone15:18
*** jorge_munoz has joined #openstack-keystone15:20
*** stevemar has quit IRC15:20
*** stevemar has joined #openstack-keystone15:21
*** jasondotstar has joined #openstack-keystone15:22
*** garnav has quit IRC15:25
samuelmzayoung, ok ... so identity handle user and project, and bind them to their owning domain15:26
ayoungyeah15:26
samuelmzayoung, we can have multiple identity providers? multiple ldap, for instance?15:26
ayoungsamuelmz, we can as of Juno15:26
ayoungsamuelmz, http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/15:27
samuelmzayoung, ok .. but can multiple providers take care of a single domain?15:27
ayoungsamuelmz, nope15:27
ayoungsamuelmz, but users from multiple domains, and thus from multiple providers, can all be assigned to roles in one domain15:28
samuelmzayoung, ok .. thanks for the link ..15:28
ayoungsamuelmz, for instance, say I set up a domain just for service users15:28
samuelmzayoung, yeah makes sense15:28
ayoungand then I have two domains, one for your org, onme for mine, both served out of our respective LDAP servers15:29
samuelmzayoung, domains for service users and domains for assignments15:29
ayoungwe could both be administrators for the service domain15:29
samuelmzayoung, something like this?15:29
samuelmzayoung, cool15:29
*** aix has joined #openstack-keystone15:30
*** gyee has joined #openstack-keystone15:32
samuelmzayoung, thanks for clarifying15:32
ayoungsamuelmz, NP15:32
*** k4n0 has quit IRC15:34
samuelmzayoung, is there a way to map ldap groups on keystone groups?15:37
ayoungsamuelmz, nope15:37
ayoungsamuelmz, LDAP groups ARE keystone groups15:37
ayoungno additional mapping allowed or required15:37
ayoungyou can specify a separate query for how to fetch the groups if you really need to, but usually its the memberOf thing...15:38
ayoungwell, that is for group assignments15:38
samuelmzayoung, ok it makes sense15:41
samuelmzayoung, the think we were talking about having multiple ldap identity backends ...15:42
ayoungsamuelmz, and you can do that, too15:42
ayoungone per domain15:43
samuelmzayoung, we had your org's domain, my org's domain and the service domain ...15:43
openstackgerritLance Bragstad proposed a change to openstack/keystone: Fix Policy backend driver documentation  https://review.openstack.org/11844315:43
samuelmzayoung, so the service domain users should be = ur org users + my org users?15:43
ayoungsamuelmz, so service stays in SQL, and then create to LDAP config files, one per backend15:43
*** jsavak has quit IRC15:43
samuelmzayoung, my concern is about domain isolation15:43
ayoung"create two"15:43
ayoungsamuelmz, each LDAP server gets its own domain.  You create that first, but don't put any users in SQL15:44
ayoungjust follow the same steps I laid out a second time15:44
ayoungsamuelmz, each LDAP server will have its own domain, and the domain gets an UUID to identify it15:45
ayoungthe users are generated an ID based on a sha256 of their ID attribute from LDAP and the domain_id15:45
ayoungit goes in a separate table in SQL.15:46
samuelmzayoung, i got it .. but where will be placed the projects?15:46
samuelmzayoung, in a third domain?15:46
ayoungsamuelmz, those go in SQL15:46
ayoungif you want, or let each of the LDAP domains have their own set15:46
*** wwriverrat has joined #openstack-keystone15:46
ayoungyou can assign users from domain A to roles in projects in domain B and vice versa15:46
*** joesavak has joined #openstack-keystone15:47
samuelmzayoung, it's clear now .. :-)15:52
ayoungawesome.  Glad I could help15:52
*** stevelle_ has joined #openstack-keystone15:58
*** ukalifon1 has quit IRC15:59
*** gokrokve has quit IRC15:59
*** bvandenh has quit IRC16:09
*** rwsu has joined #openstack-keystone16:12
lbragstadnonameentername: around?16:20
*** BAKfr has quit IRC16:23
gyeejamielennox, you still awak?16:23
*** marcoemorais has joined #openstack-keystone16:25
*** jaosorior has quit IRC16:32
*** gokrokve has joined #openstack-keystone16:32
*** marcoemorais has quit IRC16:35
*** marcoemorais has joined #openstack-keystone16:36
*** marcoemorais has quit IRC16:36
*** marcoemorais has joined #openstack-keystone16:36
openstackgerritDolph Mathews proposed a change to openstack/keystone: LDAP: refactor use of "1.1" OID  https://review.openstack.org/12047816:40
*** zzzeek has joined #openstack-keystone16:42
dolphmayoung: nkinder: bknudson: ^ small refactor16:44
dolphmbknudson: you beat me to it16:44
ayoungdolphm, thanks....16:44
nkinderdolphm: good idea16:44
ayoungdolphm, I'm pretty sure I just got a self trust to work...let me see if I can create a token with it.16:45
nkinderdolphm: but now I won't get to look up RFC references when people ask what 1.1 means... :(16:45
dolphmnkinder: my bad :P16:46
*** wwriverrat has left #openstack-keystone16:46
rm_workayoung: "But HEAT is going to be working off of Trust tokens, and a trust token cannot create a new trust" Ok, that is quite interesting. I was wondering what use case would cause us to not have the right token.16:47
ayoungrm_work, yeah, I worked long and hard to keep you from being able to do what you are suggesting that you want to do. :)16:47
rm_workayoung: heh16:48
rm_workwell, possibly we'll have two different workflows, for HEAT vs. not16:48
ayoungrm_work, it would be a horrible security mechanism if that worked16:48
rm_workor we'll TRY to set up the trust, and if it fails (which is part of our syncronous API) then we'll tell the user to do it at that point16:48
ayoungyeah, the whole "I give you a whole token and you can do whatever you want with it" is broken16:48
ayoungand I aim to fix it16:49
rm_workayoung: right, I actually was complaining about it (my use of the term "hijack" originally was a form of protest) but it really is a shitty workflow if the user has to do it manually16:49
ayoungbut in order to do so, I need to lead this target by about, oh, three years16:49
rm_work99% of our users are NOT using the API, but are using HEAT/similar16:49
rm_workand there isn't even a way to create a Trust in HEAT, as far as I know?16:49
rm_workor is there now16:49
ayoungrm_work, users should be creating their own trusts...start with that, and give me a workflow that makes sense.16:49
ayoungThere better not be16:49
rm_workayoung: i mean, is there even a way in HEAT for the *user* to create a trust?16:50
*** amakarov has quit IRC16:50
rm_workbecause again, our users are not API users. If we tell them "go create this Trust with the API using this JSON" they're going to go over and use AWS >_>16:50
ayoungrm_work, ask the heat team.16:50
rm_workforcing the user to make an API call to create a Trust is pretty much a no-go16:51
rm_workso we need to find an alternative solution16:51
ekarlso-jamielennox: u here still ?16:51
ayoungrm_work, they are not going to ues AWS because they can't host it on site, but that is a different issue16:51
ekarlso-guess he's zzz16:51
ayoungekarlso-, he's in Australia, likely asleep16:51
ekarlso-:D16:51
rm_workayoung: well, our *particular* users aren't concerned about that16:51
rm_workI know that a lot of Openstack users are private-cloud anyway, but I have to code for the users that pay my salary T_T16:52
ekarlso-guys, is there any chance we can get https://review.openstack.org/#/c/81147/ in for the next release ?16:52
*** stevelle_ has quit IRC16:53
ayoungrm_work, yeah, I hear you,  but if the workflow includes "go to keystone and create this trust"  that should be OK, so long as it is syncronos.  THat is pretty much true across the board.  I know that Horizon HEAT UI  does Keystone stuff, not sure if it is direct or indirect16:53
ayoungso if you get a token up front, (not a trust token) then, yes, you will be able to create a trust16:54
ayoungIf heat needs to do this for the end user, Heat will need to create the trust16:54
ayoungup front when the user registers for LBaaS16:54
rm_workayoung: yeah...16:54
*** marcoemorais has quit IRC16:54
ayoungrm_work, as shardy, I'm sure he has an answer for you16:54
*** marcoemorais has joined #openstack-keystone16:55
rm_workayoung: is there a way to retrieve a TrustID for a Trust that was created by someone else, if you know their user/tenant/project/whateverID?16:55
rm_workayoung: like, if I created a Trust on my account with you as the Trustee, could you get the TrustID without me giving it to you?16:55
rm_workwondering mostly about discovery -- like, do we ACTUALLY need to store the trustID in our DB, or can we look it up at runtime?16:56
*** aix has quit IRC16:58
*** harlowja_away is now known as harlowja16:58
samuelmzayoung, I saw your post 'Getting Service Users out of LDAP'17:01
ayoungrm_work, we keep those under close hold. They really are not secrets per-se, but we don;t allow enumeration of trusts by anyone other than the trustor.  Its a policy decision, and could be varied on a deployment basis17:01
samuelmzayoung, to have multiple LDAP backends, I need to create multiple keystone.<domainname>.conf files, right?17:01
ayoungsamuelmz, that is correct17:02
samuelmzayoung, and then create every <domainname> domain to have things synchronized, right?17:02
rm_workayoung: ok, makes sense17:02
ayoungsamuelmz, yes17:03
rm_workayoung: so, I think 90% of our users will probably come in through Horizon -- is the same thing an issue there?17:03
ayoungrm_work, ask Heat17:03
ayoungbut I think you are OK there17:03
rm_workask Heat about Horizon? :P17:03
ayoungHorizon tokens are not trust tokens17:03
rm_workok17:03
ayoungrm_work, yes, there is a Heat section to Horizon,17:03
samuelmzayoung, that's amazing17:03
ayoungand I think you will have the same issues17:03
ayoungsamuelmz, thank henrynash , as he's the one that made it happen17:03
rm_workayoung: alright I'll ask around in heat/horizon channels, thanks17:04
*** rkofman has quit IRC17:05
samuelmzhenrynash, great work on making multiple backends for domains :-)17:05
samuelmzhenrynash, that's just amazing17:05
samuelmzayoung, thanks again for clarifying :)17:05
ayoung++17:05
*** rkofman has joined #openstack-keystone17:05
*** amcrn has joined #openstack-keystone17:05
openstackgerritA change was merged to openstack/keystone: Fixes formatting error in debug log statement  https://review.openstack.org/11864017:06
openstackgerritA change was merged to openstack/keystone: Stop skipping LDAP tests  https://review.openstack.org/11997017:07
*** ukalifon has joined #openstack-keystone17:08
samuelmzhenrynash, ping17:11
ayoungnkinder, in your IPA setups, do you do anything about the  "enabled" field?17:12
nkinderayoung: heh, I just fixed a but to allow that to work recently17:12
ayoungnkinder, is it a config option, or a patch?17:13
nkinderayoung: https://review.openstack.org/#/c/104408/17:13
nkinderconfig option17:13
*** rushiagr is now known as rushiagr_away17:13
nkinderthe true/false logic needs to be reversed17:13
ayoungnkinder, without that, does the user_ref not have an "enabled" attribute?17:13
ayoungI'm getting17:13
ayoung   if not trustor_user_ref['enabled']:17:13
ayoung[Wed Sep 10 17:11:19.989991 2014] [:error] [pid 13636] 13636 TRACE keystone.common.wsgi KeyError: 'enabled'17:13
nkinderayoung: it can, but the logic will be wrong.  The attribtue is nsAccountLock17:14
nkinderthere is no 'enabled' attribute in LDAP17:14
ayoungright, so  I need your patch...let me start with that17:14
nkinderayoung: it can work without it, but you would use the emulated enabled approach17:14
ayoungnkinder, besides the patch, do I need to set a config option?17:15
*** ukalifon has quit IRC17:15
ayoungnkinder, so17:16
ayounguser_enable_invert=true17:16
ayounguser_enable_attribute=nsAccountLock17:16
ayounger enableD17:17
nkinderyes, and there is a default value too...17:18
ayoungah, now I am getting 403,  better17:18
nkinderuser_enabled_default?  Let me look it up17:18
ayoungTrustor is disabled...17:18
nkinderayoung: user_enabled_default needs to be set to the value as represented in ldap17:19
nkinderayoung: so, a default of True with invert set means the user is diabled by default17:19
nkinderayoung: I added docs on that in keystone.conf (around the new user_enabled_invert setting)17:20
*** richm1 has quit IRC17:20
samuelmzayoung, If we want federation with multiple LDAP identity providers... we can have the same behavior with 'Multiple backends for domains', can't we?17:24
ayoungsamuelmz, that is the idea, yes17:24
samuelmzayoung, :DD17:24
*** marcoemorais has quit IRC17:30
*** marcoemorais has joined #openstack-keystone17:31
*** marcoemorais has quit IRC17:32
*** marcoemorais has joined #openstack-keystone17:33
*** marcoemorais has quit IRC17:33
*** marcoemorais has joined #openstack-keystone17:33
*** richm1 has joined #openstack-keystone17:34
*** rushiagr_away is now known as rushiagr17:36
*** amirosh has joined #openstack-keystone17:38
nkinderayoung: so it the enabled stuff working for you?17:42
ayoungnkinder, nope17:42
*** david-lyle has quit IRC17:42
ayoungnkinder, I was a few weeks behind, so I just resynced, had to pip install oslo.utils....17:42
ayoungjust tests again, and it still fails17:43
ayoungnkinder, I have17:43
ayounguser_enabled_invert=false17:43
ayounguser_enabled_attribute=nsAccountLock17:43
ayoung#user_enabled_default=true17:43
ayoungright now...17:43
ayoungjust commentd out the default17:43
ayoungstill getting the key error17:43
nkinderayoung: you need user_enabled_invert=true17:44
nkinderand user_enabled_default=false17:44
ayoungnkinder, but I shouldn't get a key error either way17:44
nkinderayoung: so something else may have changed here that makes keystone not deal with the attribute not being present17:45
ayoungnkinder, with those values set, I get a 403 (Trustor is disabled)17:46
nkinderayoung: when I wrote this, a missing lock attribute would result in user_enabled_default being used17:46
nkinderayoung: does 'keystone user-list' show enabled/disabled for your users?17:46
ayoungnkinder, I wonder if I need to drop the attribute to get the default...let me try that, and I'll come back to the nsAccountLock value17:46
ayoungnkinder, I'm trying to create a token from a trust17:46
nkinderayoung: I'd make sure the enabled stuff is just working in a basic case first17:47
ayoungyep17:47
*** david-lyle has joined #openstack-keystone17:48
ayoungnkinder, so user_enabled_default=True  should work no matter what, right?17:50
ayoungeven if I don't have #user_enabled_attribute=nsAccountLock  set17:50
nkinderayoung: that setting would mean that we shoudl think we got "nsAccountLock: true" from the LDAP server, even if it wasn't there.17:50
nkinderayoung: which would mean the account is locked17:51
*** rushiagr is now known as rushiagr_away17:51
nkinderayoung: it's meaning is inverted17:51
ayoungnkinder, but I should not get a key error.  And I am not inverting17:51
ayoungnkinder, if All I set is that value, all users should be enabled17:51
nkinderayoung: you need to be inverting, but you should not get a key error17:51
nkinderayoung: ah, not necessarily17:52
nkinderayoung: you have no user_enabled_attribute set17:52
nkinderayoung: so it wants an "enabled" attribute, but doesn't find it17:52
nkinderayoung: I wouldn't expect a key error17:52
nkinderI would expect it to think all accounts are enabled17:53
ayoungnkinder, the code that runs this is LDAP and trusts.  I'm not certain how well tested a code path that is17:53
nkinderayoung: this must have changed, and we need a unit test that covers no enabled attr being returned from LDAP17:53
nkinderayoung: does this fail without trusts?17:53
nkinderplease take trusts out of the picture first17:54
ayoungnkinder, the code is not exectued without a trust17:54
ayoungnkinder, I'll link so you see17:54
*** jaosorior has joined #openstack-keystone17:54
nkinderayoung: I know what you're saying, but is enabled/disabled even working properly without trusts right now?17:54
ayoungI don't think so17:54
ayoungthe user can get a token regardless of what I have in there17:55
ayoungnkinder, it is failing here https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L21917:56
ayoungthat ref is returned from the LDAP identity provider, and should do the ldap->model transform17:56
ayounglet me try enabled_emulation:17:57
nkinderayoung: res_to_model should be filling that in17:57
ayounghttps://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap.py#L22217:57
ayoungnkinder, OK, with just user_enabled_emulation I should always get a user being enabled, no?18:03
nkinderayoung: well, you need an enabled group set then, and the user needs to be a member to be enabled18:04
ayoungah...that is right...not what I want18:05
ayoungnkinder, I suspect that using Kerberos is bypassing the authenticate call, which is where enabled is usually checke18:06
ayounglemme see18:06
richm1hey - is Morgan Fainberg around?  I have a question about his proposal that I rebase my commit 74897 on top of Dolph's 12047818:09
richm1I followed https://wiki.openstack.org/wiki/Gerrit_Workflow#Add_dependency18:09
richm1When I do git review, it asks me if I want to submit both commits18:10
ayoungrichm1, morgan and Morgan_ are both aliasesto morganfainberg. Not sure why he is in cog neeto!18:10
richm1http://paste.openstack.org/show/109683/18:10
ayoungnkinder, OK,   right now with no value set, I can get a token using userid/password  against a FreeIPA based LDAP18:11
richm1^^^ - should I type yes here?  If not, where did I go wrong?18:11
ayoungnkinder, now,  let me try it with a fake user, so I don't lock myself out....18:11
dstanekrichm1: i think you want to 'git review -R'....i'm pretty sure that's the no-rebase flag and if set it won't change the exising review18:11
*** amirosh has quit IRC18:11
ayoungOK...now let me disable that user and lets see...18:12
dstanekrichm1: git review --help will show you for sure18:12
richm1dstanek: with git review -R I get the same thing18:12
ayoungnkinder, now I get a 40118:12
dstanekrichm1: it will show both patches, but shouldn't rebase18:13
richm1dstanek: does that mean I should type "yes" to the prompt and submit both commits?18:15
nkinderrichm1: you are making one patch depend on another?18:15
richm1yes18:16
nkinderrichm1: if so, type "yes"18:16
dstanekrichm1: yes18:16
openstackgerritRichard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported  https://review.openstack.org/7489718:16
nkinderrichm1: it will do the right thing (though that message is scary the first time you do this)18:16
morganrichm1, hey18:22
morganayoung, I am incognito because i was snagging this as an IRC alias.18:22
morganrichm1, and typing "yes" was the right answer :)18:23
*** morgan is now known as morganfainberg18:23
*** morganfainberg is now known as morgan18:24
ayoungnkinder, hmmm I might have been executing a bogus trusts.  I was doing a blanket list_trusts, with no param, which lists all trusts...let me try again with a scoped list, and see what I find18:24
*** thiagop has joined #openstack-keystone18:26
openstackgerritRodrigo Duarte proposed a change to openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only)  https://review.openstack.org/11577018:27
nkindermorgan, dolphm: can you explain the --no-rebase option when submitting a review with a dependency?18:29
dolphmnkinder: sure...18:29
morgannkinder, git review does some rebase magic18:29
nkinderI saw dolphm's comment in the review, and want to be sure I understand18:29
morgannkinder, i use it when things are in gate already18:29
dolphmnkinder: when you do a normal git-review, it rebases onto master automatically before uploading18:30
nkinderdolphm: ah, so it would attempt to rebase your 1.1 patch too18:30
dolphmnkinder: the fear (and what morgan's referring to) is if a change has already spent time in the gate, and it's pulled back out by git-review uploading a trivially rebased patch, it has to start all over again in the gate18:31
nkinderdolphm: and that would start your review back over in the gate (with the rebase)?18:31
dolphmnkinder: yeah18:31
dolphmnkinder: ++18:31
nkinderyeah, that's no good18:31
*** Morgan_ is now known as morgan_remote18:31
nkinderI always manually rebase off of master just before submitting a review for normal patches18:31
nkinderbut it sounds like --no-rebase should almost always be used when depending on another patch18:31
morgannkinder, well, it depends.18:32
nkinderI can see if I wanted to rebase one of my own other proposals at the same time18:32
dolphmnkinder: if it's someone else's patch, i'd recommend --no-rebase so as to not confuse people :)18:32
nkinderbut rebasing someone else's seems bad18:32
nkinderyeah, ok.  Thanks for the explanations!18:32
*** jsavak has joined #openstack-keystone18:33
*** joesavak has quit IRC18:33
*** rushiagr_away is now known as rushiagr18:33
*** ChanServ sets mode: +o morgan18:36
*** vhoward has left #openstack-keystone18:38
morganYorikSar, ping re https://review.openstack.org/#/c/120340/18:38
morganYorikSar, we went back and forth on supporting a JSON string in the config, in short it was nixxed18:39
morganYorikSar, i don't want to re-open that discussion this late in the cycle. I know you prefer the json, it is awful for deployers tbh to need to craft json strings to put in a config file.18:39
morganYorikSar, it looks like you have a fixed number of arguments for the pool, lets just add one option per argument (url is handled) for the pool in [memcache] for the keystone server18:40
morganit is *memcache* specific configuration.18:40
YorikSarmorgan: Oh, it's not like I like JSON in config. I just don't know other extensible way to put these options there.18:41
YorikSarmorgan: Sure, I understand.18:41
YorikSarmorgan: And what about [cache]?18:41
morganYorikSar, i meant like it compared to specific args in [memcache]18:41
morganYorikSar, i'm ok with piggybackiing the same pool arguments18:41
morganYorikSar, if you feel we *need* separate args for cache we can add them there too or only use the backend_argument multi-opt18:42
YorikSarmorgan: I'll scrap this CR then and add all those args to these two sections in the pool CR, ok?18:42
morganYorikSar, i meant like json compared to the alternative of individual opts :)18:42
morganYorikSar, ++ works for me, feel free to use the same changeid18:42
morganYorikSar, that way you don't need to change the commit msg of the other one :)18:42
openstackgerritMichael Bayer proposed a change to openstack/keystone: Ensure a consistent transactional context is used  https://review.openstack.org/12014618:43
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Add RSS feed  https://review.openstack.org/12052218:43
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Remove templates from toctrees  https://review.openstack.org/12052318:43
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Use the current date for the copyright statement  https://review.openstack.org/12052418:43
YorikSarmorgan: I actually understood that we've been passing strings where backend expected ints... So I'm not sure backend_argument really worked for pool.18:44
morganYorikSar, ah. i'm ok with the options being in both sections18:44
morganYorikSar they are specific to the different functions (kvs/memcache token and caching)18:44
YorikSarmorgan: So I'll name them memcache_* in [cache] and w/o prefix in [memcache], ok?18:45
morganYorikSar, ++18:45
YorikSarmorgan: Great. I'll do that first thing in the morning. (11pm here already)18:46
morganYorikSar, works for me. tyvm18:46
ayoungGahdamnint... "add the OSTRUST:  to the token messes up angular.js"18:47
*** bjornar_ has joined #openstack-keystone18:48
YorikSarayoung: So don't use that monster :)18:48
ayoungYorikSar, you have that so backwards18:48
bjornar_I keep seeing these in master: http://pastie.org/pastes/9542821/text ... dont see it in icehouse18:48
*** bknudson has quit IRC18:48
ayoungits a good thing you are on another continent, or I would tackle you just to vent my frustration18:48
* ayoung gonna kick the wavemaster instead18:49
* YorikSar enjoys Russian safety18:49
ayoungYorikSar, isn't that an Oxymoron?18:50
morganbjornar_, https://bugs.launchpad.net/oslo.db/+bug/136137818:50
uvirtbotLaunchpad bug 1361378 in oslo.db ""MySQL server has gone away" again" [Undecided,Incomplete]18:50
YorikSarayoung: Nah, especially in this context :)18:51
*** gabriel-bezerra has joined #openstack-keystone18:51
nkinderayoung: how's the kerberos auth plug-in github seed coming along?18:52
ayoungnkinder, jamielennox submitted it, it was awaiting the admins to approve last I looked18:52
ayounghttps://review.openstack.org/#/c/120261/  nkinder18:53
morgandhellmann, +2 on the spec changes.18:53
YorikSarayoung: btw, I hope you didn't think I called anyone but angular a monster in that message.18:53
ayoungYorikSar, I thought you called OSTRUSTS a monster18:53
dhellmannmorgan: thanks18:54
ayoungAngular is not the problem, really18:54
bjornar_morgan, Invalid!?18:54
morganbjornar_, it's invalid in keystone, its an issue (if anything) in the oslo.db lib18:54
morganbjornar_, as far as we can tell.18:54
bjornar_sure.. but is the but "forwarded" to oslo?18:54
YorikSarayoung: No-no. Angular is a real monster. It's like writing in Python in Java-style.18:54
*** bknudson has joined #openstack-keystone18:55
morganbjornar_, it was added to the oslo team as "incomplete" (needs more info)18:55
morganbjornar_, but yes it was.18:55
bjornar_huh..18:55
*** ukalifon1 has joined #openstack-keystone18:55
bjornar_db errors like these are critical18:55
morganbjornar_, if you look at the url up there that is under oslo.db, which handles all the connection logic18:55
bjornar_sure18:55
morganbjornar_, so if there is more info, please add it to the bug so we can get it fixed18:56
bjornar_thats the info I have (pastebin)18:56
morganbjornar_, even if it's something keystone is doing wrong we can reopen, but it *looks* like it's an oslo issue. see what is listed in the bug.18:56
bjornar_And I know for a fact this is only happening on master, not icehouse branch18:56
morganbjornar_, i definitely (as i'm sure the oslo team will) want to see this fixed18:56
morganbjornar_, master uses oslo.db, iirc icehouse does not18:57
morganbjornar_, indicating it's an oslo.db issue we need to fix there (likely)18:57
bjornar_I dont see any oslo.db in the trace...18:58
ayoungnkinder, the trust thing seems to work OK for SQL, just not for LDAP.18:58
ayoungI'm trying to script it to show the problem...18:58
ayoungYorikSar, the problem is javascript. I get the token, and it correctly marshalls the JSON to an object, but then it gets to18:59
nkinderayoung: ok, so jamielennox will need ot make the jobs non-voting as AJ suggested18:59
ayoungtoken.OSTRUST:trust which is not a valid identifier18:59
ayoungnkinder, yes18:59
*** radez is now known as radez_g0n318:59
ayoungYorikSar, I didn't choose angular,  blame the Horizon folks19:00
bjornar_morgan, should I not see oslo.db referenced in the trace?19:00
YorikSarayoung: Well... Client can use token["OSTRUST:trust"] just as easy..19:00
morganbjornar_, i don't think you will19:00
ayoungAh  YorikSar that is it. I've been doing Python so long, I forget that ' != "19:00
morganbjornar_, oslo.db is a bunch of helpers around sqla but i don't think it ends up in the trace19:01
morganbjornar_, this might be needed https://github.com/openstack/oslo.db/blob/master/oslo/db/api.py#L62-L93 but typically the issue is really that you've lost connection with MySQL [legitimate error is 'mysql has gone away' in that case]19:01
YorikSarayoung: Huh! In Keystone ' != " :) (I've got a really long conversation on this topic with morgan recently, it was like 3 mins)19:02
*** rushiagr is now known as rushiagr_away19:02
ayoungYorikSar, in Javascript '  and "  are different19:02
morganayoung, hehe19:02
ayoungBut the error was OSTRUSTS != OS-TRUST19:02
morganYorikSar, yeah python is a bit less picky than json :P19:03
morganfor " vs '19:03
bjornar_morgan, lost connections should be no problem if you manage to reestablish..19:05
bjornar_a warning at most then19:05
morganbjornar_, if you lose the connection middle of a transaction, you're getting that error afaict.19:05
morganbjornar_, now, like i said might need the decorator.19:06
bjornar_then its not handled right19:06
morganbjornar_, can you confirm what is actually happening in this case when the error is raise? are you dropping from mysql? is the mysql server not responding anymore for some reason? is it purely python failing mid transaction?19:07
morganbjornar_, i've not been able to duplicate it short of turning off mysql, so, more info helps.19:07
morganif we need the decorator we can prioritize that as a bugfix.19:07
morganand if mysql is turned off (in my case) yes it should tell me the server went away :)19:08
bjornar_morgan, 140910 21:06:13 [Warning] Aborted connection 20571 to db: 'keystone' user: 'keystone' host: '172.16.0.19' (Unknown error)19:09
ayoungnkinder, OK, I think that Trusts are broken under LDAP and Keystone.  I see no effect from setting any of the config variables...I don't need to set them for authenticate:  disableing hte user seems to work fine, kereberos or userid/password19:09
morganbjornar_, i need to go (have to get somewhere for an appointment) i'll be back alter on and can circle back.19:10
morganbjornar_, if you want to add more information to that bug (or if it's something else, a new bug) please do. we should evaluate if anything is needed as an RC blocker on this front.19:11
morgandolphm, ^ re mysql server has gone away.19:11
morgandolphm, we might need to rule out / add this as an RC blocker.19:12
morganbjornar_, in either case i'll circle back and take a closer look when i'm back online.19:12
*** mgagne has quit IRC19:18
*** dtroyer has quit IRC19:19
*** mgagne has joined #openstack-keystone19:19
*** mgagne is now known as Guest7525019:19
bjornar_morgan, ok. Hope you take this serious19:20
*** dtroyer has joined #openstack-keystone19:21
*** KanagarajM has quit IRC19:23
samuelmzayoung, ping19:23
ayoungsamuelmz, I'm here...Better to just ask your question and send a Ping message.19:24
samuelmzayoung, still about your post about multiple backends for domains ..19:24
ayoungUh oh19:24
ayoungnow you are getting smart, and you are going to show me how something is broken, aren't you?19:24
samuelmzayoung, in that case you have a ldap structure like this (http://paste.openstack.org/show/109718/)19:25
samuelmzayoung, haha no :-)19:25
samuelmzayoung, you have that structure, right?19:25
ayoungyeah, that is roughly it19:25
*** ukalifon1 has quit IRC19:25
samuelmzayoung, what about if I had this (http://paste.openstack.org/show/109719/)19:25
bknudsonthat dit makes no sense. why would you put users under groups?19:26
bknudsoncan't you have the same user in 2 groups?19:26
ayoungsamuelmz, depends.  Is IPB  , IPC...something you expect to have created dynamically19:26
ayoungbknudson, I think he's just asking about multiple trees19:26
bknudsonoh, you can have multiple trees.19:26
samuelmzayoung, yes multiple trees19:26
ayoungsamuelmz, there are two ways19:27
ayoungprobably what you want is to search by object class in subtrees19:27
bknudsonjust point your ldap configs at different subtrees.19:27
samuelmzI have to tell him to get groups from org.freeipa.cloudlab.ipa and org.freeipa.cloudlab.ipb19:27
ayoungand I think you  need to change from19:27
bknudsonyou could use referrals for that.19:27
bknudson(I think... haven't tried it)19:27
ayoungquery_scope=one to query_scope=sub19:28
samuelmzHow it'd be in the config/keystone? A domain for each tree?19:28
bknudsonit would have to be a domain for each tree19:28
ayoungsamuelmz, it really depends on what you are trying to do.  If you just have a deeply nested tree, then you change the query scope to do subtree queries,  and I suspect that is what you want19:29
ayoungif, On the other hand, you have two organizations, and their trees are radiacally diffferent, you could treat them as two different LDAP server and put them in two domains19:29
ayoungsamuelmz, you are at a University, right?  So you have people in undergrad, gradschool, faculty etc?19:30
samuelmzayoung, yes19:30
ayoungsamuelmz, OK, so you want to try setting19:31
ayounguser_query_scope=sub and group_query_scope=sub19:31
ayoungwait no19:32
ayoungits just query_scope=sub19:32
ayoungthat is not one that is per entity...sorry19:32
bknudsonthat sounds like a bug19:32
ayoungbknudson, that it is not per entity?19:33
bknudsonayoung: yes. should be per entity19:33
ayoungbknudson, maybe19:33
ayoungbknudson, sub could easily be the default, with one as a tuning thing.19:34
samuelmzin ldap how do we associate users to groups?19:34
ayoungsamuelmz, usually it is via "memberOf"19:34
bknudsongroup has a member attribute19:34
samuelmzcool .. so we have a list19:34
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/config.py#n69519:35
samuelmzayoung, in our case we have a list of members in the group, is it/19:35
bknudsonthat's standard ldap stuff... nothing keystone specific19:35
*** saipandi has quit IRC19:41
openstackgerritRodrigo Duarte proposed a change to openstack/python-keystoneclient: Extracting common code to private method  https://review.openstack.org/12056319:42
dolphmbjornar_: are you referring to this bug? https://bugs.launchpad.net/keystone/+bug/136137819:43
uvirtbotLaunchpad bug 1361378 in oslo.db ""MySQL server has gone away" again" [Undecided,Incomplete]19:43
samuelmzayoung, look at this http://paste.openstack.org/show/109728/19:43
samuelmzayoung, I'd like to map ug_students, master and doctor to groups19:43
ayoungsamuelmz, yeah, sub is going to be required for that19:43
ayoungsamuelmz, ugh19:43
ayoungsamuelmz, they are not  already groups?19:44
ayoungsamuelmz, that you might want to do as three different domains.19:44
samuelmzayoung, import as keystone ones19:44
samuelmzayoung, I meant19:44
samuelmzayoung, make keystone use them ... sorry I dont know the better way to say it, but i got it19:45
samuelmzayoung, :-)19:45
ayoungsamuelmz, that is probably not a good LDAP setup, BTW. What happens when someone finishes a masters degree and goes on for the Doctorate?  You end up having to change their DN19:45
samuelmzayoung, I know and imagine you have the worst ldap setup you can imagine19:46
samuelmzayoung, and your enterprise dont want you to change the ldap19:46
ayoungsamuelmz  I'd try it as 3 domains, then.  One for each of those major groups19:46
ayoungI imagine that could get nasty if there are also actual groups there, too19:47
samuelmzayoung, ok we have different approaches19:47
ayoungand a group could contain undergrad, master and doctor...19:47
ayoungI don't think there is a solution.19:47
ayoungYou can't magically create a Keystone group out of a container19:47
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Use the current date for the copyright statement  https://review.openstack.org/12052419:48
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Remove templates from toctrees  https://review.openstack.org/12052319:48
samuelmzayoung, and if we could do something like this in the config ? http://paste.openstack.org/show/109730/19:49
bjornar_dolphm, looks similar, yes19:51
dolphmbjornar_: to what?19:51
samuelmzayoung, hmm.. I got the query_scope thing19:54
samuelmzayoung, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/config.py#n49119:54
bjornar_dolphm, ......to that bug....19:54
samuelmzayoung, thanks :-)19:55
samuelmzayoung, and I'll be back if I get smarter19:55
lbragstaddolphm: ping, figured out why the tests are failing for the user role assignment stuff19:57
dolphmlbragstad: o/ what's the bad news19:57
lbragstadturns out that call is dependent on the user being in the backend, even for V319:57
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/auth/plugins/password.py#L107-L10919:57
lbragstad^ that guy19:57
dolphmlbragstad: that shouldn't be LOG.exception() either... but i digress19:58
lbragstaddolphm: it's kinda misleading19:58
dolphmlbragstad: which user has to be in the backend? just the calling user?19:58
lbragstadthe user your assigning  the role to19:58
*** david-lyle has quit IRC19:58
lbragstadit's confusing because for UserNotFound, we get Unauthorized, but I'd agree that's a different matter19:59
*** hrybacki has joined #openstack-keystone20:03
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Use the current date for the copyright statement  https://review.openstack.org/12052420:03
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Remove templates from toctrees  https://review.openstack.org/12052320:03
openstackgerritDoug Hellmann proposed a change to openstack/keystone-specs: Add RSS feed  https://review.openstack.org/12052220:03
openstackgerritHenrique Truta proposed a change to openstack/python-keystoneclient: Implementing inherited role domain calls on keystoneclient v3  https://review.openstack.org/11608120:08
openstackgerritHenrique Truta proposed a change to openstack/python-keystoneclient: Creating parameter to list inherited role assignments  https://review.openstack.org/11730020:10
*** david-lyle has joined #openstack-keystone20:11
bjornar_dolphm, I did not see these errors before moving to master20:12
dolphmbjornar_: have you filed a bug report? i have no context for what you and morgan were discussing20:13
bjornar_oh, I filed to pastie: https://bugs.launchpad.net/oslo.db/+bug/136137820:14
bjornar_;)20:14
uvirtbotLaunchpad bug 1361378 in oslo.db ""MySQL server has gone away" again" [Undecided,Incomplete]20:14
bjornar_sorry: http://pastie.org/pastes/9542821/text20:15
*** marcoemorais has quit IRC20:25
*** saipandi has joined #openstack-keystone20:25
*** marcoemorais has joined #openstack-keystone20:26
*** marcoemorais has quit IRC20:27
*** marcoemorais has joined #openstack-keystone20:28
*** marcoemorais has quit IRC20:30
*** marcoemorais has joined #openstack-keystone20:30
*** topol has quit IRC20:32
openstackgerritRodrigo Duarte proposed a change to openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only)  https://review.openstack.org/11577020:33
*** amcrn has quit IRC20:35
*** hockeynut_ has quit IRC20:40
*** rm_work has quit IRC20:40
*** rm_work has joined #openstack-keystone20:41
*** hockeynut has joined #openstack-keystone20:42
nkinderjamielennox: I made the jobs non-voting for the kerberos plugin repo request - https://review.openstack.org/#/c/12026120:42
nkinderjamielennox: ...at least I think I did. :)  It seemed safe to leave the merge check and pypi templates in there.20:43
ayoungnkinder, I have user_enabled_attribute=nsAccountLock  and I traced as far as the LDAP query requesting that.  ldap has20:47
ayoungnsaccountlock: FALSE20:47
ayoungbut the attribute did not come back from the query20:48
ayoung LDAP search: base=cn=users,cn=accounts,dc=younglogic,dc=net scope=1 filterstr=(&(uid=ayoung)(objectClass=inetOrgPerson)) attrs=['mail', 'userPassword', 'uid', 'nsAccountLock'] attrsonly=0 search_s /opt/stack/keystone/keystone/common/ldap/core.py:91820:49
ayoungbut the line20:50
nkinderayoung: it has to be asked for, as it's an operational attribute IIRC20:50
nkinderyet that shows it's being asked for20:50
ayoungyep20:50
ayoungbut not returned from20:50
ayounghttps://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L90820:51
ayoungnkinder, just to confirm, you had this working with IPA, right?20:51
nkinderayoung: yes20:51
ayoungOK...I'm going to keep digging20:51
nkinderayoung: so are you saying it is returned via ldapsearch?20:51
nkinderayoung: because it will not always be present in an entry20:51
ayoungnkinder, well, I did ipa user-show --all --raw20:51
ayoungand it was there20:52
* ayoung got a little lazy20:52
nkinderayoung: I'd use ldapsearch directly20:52
nkinderayoung: IIRC, if you create a new user the nsAccountLock attr won't exist20:52
nkinderif you lock the user, it gets added with a value of True20:52
nkinderif you then unlock the user, the value is replaced with False (and the attr exists)20:52
nkinderayoung: moral of the story = the attribute will not always be present20:53
ayoungnkinder, I wonder if IPA fakes it, too20:53
ayoungnkinder, so I don't get it if I do20:53
ayoungldapsearch -Y gssapi  "(uid=ayoung)" | grep -i lock20:53
nkinderayoung: it's operational, so ask for it20:54
nkinderayoung: I don't have an IPA install handy on my laptop ATM20:54
ayoungnkinder, I have one, public, and in the cloud...and you already have an accout...but I want to keep hunting this....20:54
*** joesavak has joined #openstack-keystone20:54
ayoungyeah, nothing comes back....20:56
ayoungldapsearch -Y gssapi  "(uid=ayoung)"   uid nsAccountLock20:56
ayoung# requesting: uid nsAccountLock20:56
ayoung#20:56
ayoung# ayoung, users, compat, younglogic.net20:56
ayoungdn: uid=ayoung,cn=users,cn=compat,dc=younglogic,dc=net20:56
ayounguid: ayoung20:56
ayoungnkinder, OK,  let see for the one I locked20:57
nkinderayoung: ok, now lock your user using the IPA tools20:57
nkinderthen search, then unlock, then search again20:57
ayoungyep20:57
ayoung# jafo, users, accounts, younglogic.net20:57
ayoungdn: uid=jafo,cn=users,cn=accounts,dc=younglogic,dc=net20:57
ayounguid: jafo20:57
ayoungnsAccountLock: FALSE20:57
*** jsavak has quit IRC20:57
nkinderayoung: that's the unlocked user?20:57
ayoungnkinder, yes...locked and then unlocked20:57
nkinderayoung: correction... the user formerly known as the locked user :)20:57
nkinderayoung: yeah, so that fits with what I remember.  With my patch (and the proper config), 'keystone user-list' was showing enabled for users who were never locked20:58
ayoungOK, so this makes sense20:59
nkinderayoung: basically, I think res_to_model needs to set the enabled value based off of the default when we don't find the enabled attribute in the LDAP resource21:00
nkinderayoung: so the 'enabled' key should always be present in the model21:00
ayoungnkinder, yes, but it doesn't seem to do that now21:03
nkinderayoung: ok, it really should do that IMHO21:03
*** marcoemorais has quit IRC21:04
nkinderayoung: but strange that it was working for me with 'keystone user-list'21:04
*** marcoemorais has joined #openstack-keystone21:04
*** marcoemorais has quit IRC21:05
*** marcoemorais has joined #openstack-keystone21:06
ayoungnkinder, we should be checking the enabled value later on21:06
*** marcoemorais has quit IRC21:07
*** marcoemorais has joined #openstack-keystone21:08
ayoungnkinder, so we check it in the password plugin:21:09
ayoungand in the token controller, but not in external21:09
ayounghttp://paste.openstack.org/show/109766/ nkinder21:09
ayoungand that call is21:09
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/core.py#n56521:10
ayoungif not user.get('enabled', True):21:10
ayoungso we default it in core.py but then it fails in the token provider because that goes directly against the user_driver21:11
ayoungI think I can just make a change in the provider:21:11
ayounglet me test that21:11
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/python-keystoneclient: Inherited role domain calls on keystoneclient v3  https://review.openstack.org/11608121:14
*** jimhoagland has quit IRC21:15
nkinderayoung: ok, that is a less invasive change21:15
ayoungnkinder, OK, that worked21:16
ayoungbut not with your config values set21:16
ayounglet me confirm what I had21:16
ayoung#user_enabled_invert=True21:16
ayoung#user_enabled_attribute=nsAccountLock21:16
ayoung#user_enabled_default=True21:16
ayoungI think that last option was reversed21:17
ayounglet me try it with false21:17
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add a functional tests for role assignments  https://review.openstack.org/11984321:17
nkinderall commented out though?21:17
lbragstaddolphm: I have the test fixed up that exposes the bug, we can iterate in the bug report how to best go about fixing? ^21:17
ayoungnkinder, nope, user is disabled...21:18
ayounghmm21:18
ayoungnkinder, it should be21:18
ayounguser_enabled_invert=True21:18
ayounguser_enabled_attribute=nsAccountLock21:18
ayounguser_enabled_default=False21:18
ayoungright?21:18
nkinderyes21:18
nkinderayoung: does that work for password auth?21:18
ayounglet me see if password...heh21:19
nkinderand does user-list show the right thing?21:19
ayoungI was able to get a token using password21:19
nkinderayoung: now lock a user using the ipa CLI21:19
ayoungAh...no I didn;t21:19
ayoung40121:19
ayoung(me defaulted UI to Kerberos)21:20
ayoungnkinder...ok, one sec21:20
ayoungjafo failed too21:20
ayounglet me try locking his account21:20
ayoungdoesn't seem to make a difference21:21
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Adds pipeline hints to the example paste config  https://review.openstack.org/11982721:22
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:22
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Adds hint about filter placement to extension docs  https://review.openstack.org/11983421:22
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Document Keystone2Keystone federation  https://review.openstack.org/12058421:22
ayoungBAH21:22
nkinderayoung: is that a good BAH (as in there was some stupid problem), or a BAH of frustration?21:23
ayoungit was due to me not setting the user domain correctly and riunning a bunch of crap tests21:24
ayoungok...when I set it correctly21:24
ayoungjafo gets a 401 with the config options set21:24
ayoungnow removing them....21:25
ayoungand he still gets a 40121:25
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Document Keystone2Keystone federation  https://review.openstack.org/12058421:26
ayoungkinit: Clients credentials have been revoked while getting initial credentials21:26
ayoungok,  guessing his account is locked...21:26
ayoungnow he's unlocked...tested with Kerberos...got a token.  tested with password got a token...,21:28
ayoungand that is without the config options set21:28
ayoungnot let me set them and see...21:29
ayoung40121:29
ayoungnkinder, if all I set is nsAccountLock, it works...21:30
ayoungwhich is really strange21:30
*** bjornar_ has quit IRC21:31
*** hrybacki has quit IRC21:38
*** henrynash has quit IRC21:40
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add V3 JSON Home support to GET /  https://review.openstack.org/11824021:52
*** amcrn has joined #openstack-keystone21:53
ayoungnkinder, I richm1 I approved your subtree patch.  Keep an eye on it, and if it fails gate, let me know.21:54
dolphmbknudson: is the only change here? https://review.openstack.org/#/c/118240/6/keystone/controllers.py (plus dropping the name kwarg)21:54
bknudsondolphm: y, it should just be the comment and name= removal21:55
bknudsonand I rebased it ... no conflicts21:55
dolphmbknudson: +221:56
morgandolphm, this is related to the mysql server has gone away thing21:58
morgandolphm, the discussion with bjornar21:58
openstackgerritayoung proposed a change to openstack/keystone: Safer check for enabled in trusts  https://review.openstack.org/12059221:58
dolphmmorgan: https://bugs.launchpad.net/keystone/+bug/1361378 ?21:58
uvirtbotLaunchpad bug 1361378 in oslo.db ""MySQL server has gone away" again" [Undecided,Incomplete]21:59
morganthat was the one21:59
morganit *may* actually be relevant, we get that error if we're losing connection mid-transaction21:59
morganit looks like21:59
dolphmmorgan: did you see comment #2?21:59
morganthere are ways to auto retry21:59
morganright21:59
morganbut this was also in bjornar's environment not in gate22:00
morganafaik22:00
*** saipandi has quit IRC22:00
ayoungdolphm, well, it took me all day, and I had to do another bug fix, but I confirmed that a user can, infact, execute a "self" trust and get a token22:00
morganso not  *that* bug but a similarly related one, where midtransaction causes the query to fail vs. retry (there is that decorator?) *shrug* i'm not sure.22:01
dolphmayoung: thanks for checking... it seems like a useless edge case we should prevent?22:01
ayoungdolphm, nope22:01
ayoungdolphm, I see it as the right path forward22:01
morgandolphm, was willing to look at little closer before dismissing for RC, but not willing to give it an absolute RC blocker status22:01
ayoungdolphm, specifically, it is the only way I can create a token with a subset of my roles22:02
ayoungthere is no risk22:02
dolphmmorgan: add it to juno-rc-potential then22:02
morgandolphm, yeah will do once i am sure it's a *bug*. i don't think we want to use that bug id though. looks like it's only semi-related22:02
ayoungdolphm, it has a second side effect I like too:  a trust token cannot be used to create a new trust.  This means that I an use it to hand over a token and not worry that the remote service then creates a trust granting it full privs to my account22:03
richm1ayoung: thanks - I'll just keep doing "recheck" until it passes, as per usual22:04
ekarlso-ayoung: from 1 to 10 how hard btw is dogtag to get up ?22:04
ayoungrichm1, I can't seem to add you to a review22:05
ayoungrichm1, but please look at   https://review.openstack.org/12059222:05
ayoungekarlso-, install FreeIPA and it is trivial22:05
*** saipandi has joined #openstack-keystone22:05
ekarlso-ayoung: does it require the whole ipa suite ? :|22:06
ayoungekarlso-, doing it by hand is not too bad,  and alee in #openstack-barbican is one of the cores on it22:06
*** sigmavirus24 is now known as sigmavirus24_awa22:06
ayoungekarlso-, you want FreeIPA.  You crave it.  It fills a void in your life you didn't know you had22:06
ekarlso-haha22:06
ayoungekarlso-, LDAP and Kerberos and DNS...Oh My22:07
ayoungand Dogtag for good measure...22:07
ayoungekarlso-, why are you asking?22:07
ekarlso-ayoung: just wondering :)22:07
ayoungekarlso-, Its a tomcat app, but you want to use the python based deployment scripts, as it does a lot of Security hardening that is essential22:08
ayoungekarlso-, NSS enforces that the Private Keys stay inside the NSS database, unlike OpenSSL where you extract them and sign in your current process.  The net effect is that a crashed program does not have private keys in the memory dump22:09
ayoungthis is essential to things like getting the US government to use it.22:09
ayoung(FIPS/Common criteria type stuff)22:09
ayoungekarlso-, I think its pki-silent that you want.  nkinder is that right?22:10
*** nkinder has quit IRC22:12
*** dims__ has joined #openstack-keystone22:13
*** joesavak has quit IRC22:13
ayoungbknudson, https://review.openstack.org/#/c/118240/6  makes a change in keystone all that I do not see reflected in the HTML code...is this correct?22:13
ayoungOh, wait  as keystone_service22:14
ayoungOK...I guess we'll catch that in devstack22:14
bknudsonayoung: httpd/keystone.py ?22:16
ayoungbknudson, I see it now...it was the paste cleanup22:16
ayoungbknudson, it makes sense, but why is it in this patch?22:16
bknudsonayoung: the version controller needs to be able to do a GET /v3 call...22:17
bknudsonin order to do that it needs the public or admin application22:17
*** dims_ has quit IRC22:17
bknudsonso in order to get the public or admin application, the application needs to be stored when it's loaded22:17
bknudsonso in order to store the application, rather than calling deploy.loadapp, keystone.service.loadapp() is called22:18
ayoungbknudson, a controller is doing another Call?22:18
*** dims__ has quit IRC22:18
bknudsonayoung: yes, version controller is doing GET /v3. I couldn't figure out a better way to do it.22:18
ayounghmmm22:18
bknudsonbecause the extensions modify the /v3 response to fill in their resources.22:19
*** dims_ has joined #openstack-keystone22:19
bknudsondolphm asked me to write the JSON Home code that way... seemed pretty slick.22:19
*** david-lyle has quit IRC22:19
*** marcoemorais has quit IRC22:20
*** marcoemorais has joined #openstack-keystone22:20
bknudsondolphm: about https://bugs.launchpad.net/keystone/+bug/1315049 -- it's not a problem on master so seems like there shouldn't be a change to master... it was only affecting a stable/icehouse.22:20
uvirtbotLaunchpad bug 1315049 in keystone "'Provider' object has no attribute 'revoke_api'" [Medium,In progress]22:20
*** gordc has quit IRC22:20
*** marcoemorais has quit IRC22:20
ayoungbknudson, my head is spinning on this.22:20
gyeeayoung, for trust, where's the part that check for trust expiration when issuing a trust token?22:21
ayoungbknudson, my knee jerk reaction is that some of the slop we've been doing in the versions code path has come home to bite us22:21
*** marcoemorais has joined #openstack-keystone22:21
ayounggyee, no idea.22:21
bknudsonayoung: the versions code is a mess.22:21
gyeeI can't seem to find that code22:21
ayounggyee, should be in the issue trust22:21
ayounggyee, look in token/providers/common.py22:21
ayoungif its not there, it should be22:22
gyeeayoung, I did, but doesn't appear its check for expires_at22:22
ayounggyee, unless it is in the get code?22:22
*** jaosorior has quit IRC22:22
gyeenot there either22:22
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/core.py#n8322:23
ayoungyes it is22:23
* ayoung is probably lying22:23
gyeeI mean the checking for expires_at part22:23
ayounggyee, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/backends/sql.py#n13922:23
ayounggyee, if the trust expired, get_trust returns None22:24
gyeeayoung, that's it!22:24
gyeethanks!22:24
ayounggyee, YW22:24
ayounggyee, we should do that same logic for get_user22:24
ayoungand for any get22:24
gyeeoh, you mean a common layer to check for expiration? yes, good idea22:25
ayounggyee, I mean that we should have a pattern where the get_ returns None if the object is invalid22:25
gyeeayoung, ++22:25
morganayoung, instead of raising a 404?22:25
ayoungand an override switch for the cases where we still want to see them22:26
ayoungmorgan, I mean in the providers22:26
morganayoung, oh.22:26
ayoungmorgan, if a user is disabled, we still return it, but then explicitly have to check that22:26
ayoungversus trusts which enforce it at the provider level (see above link)22:26
*** morgan is now known as morganfainberg22:27
gyeehey guys, on a different topic, Stuart raised a concern on version discovery, which I think its legit22:27
gyeethis maybe application to JSON home as well22:27
gyeeconsider this22:27
gyeetwo instance of keystone running behind a VIP/LB, both servicing v2 and v322:28
gyeeone is being upgraded to service v3 only22:28
bknudsonJSON Home only supports v3.22:29
gyeeclient got routed to first instance which advertise both v2 and v322:29
gyeeon the second call, client got LBed to the second instance which no longer supports v222:29
bknudsonthe client should get routed to the same server... wouldn't that be an odd LB that switches the client's server?22:30
gyeebknudson, REST api are sessionless22:30
bknudsonalso, if the server says it supports both v2 and v3 then the client should be picking v3 and not v2.22:30
gyeebknudson, right, but if client just want to do v222:31
gyeefor whatever reason22:31
bknudsonthen you'd better not change your server to only support v3.22:31
gyeebkudson, wouldn't JSON home face the same issue when we have v4 or v522:31
bknudsonwe'll never have v4 or v5.22:31
gyeehehe22:31
bknudsonwe didn't learn our lesson?22:32
gyeebkundson, man this rolling upgrade stuff is breaking my head22:32
bknudsonwe can't do a rolling upgrade if we have data in sql22:33
gyeeyeah we can22:33
gyeeversion the data22:33
bknudsonat some point you're going to have to migrate sql22:34
*** dims_ has quit IRC22:34
gyeebknudson, rolling upgrade sql too22:34
*** dims_ has joined #openstack-keystone22:35
gyeejust need to do some LB magik22:35
bknudsonnova's got their nova-conductor22:35
bknudsonso you can upgrade all those22:35
bknudsonbut then you'll still need to do the db_sync and that's going to require quiesce the clients22:36
gyeeisn't that a grenade requirement that conf file, binary, and backend can be independently upgraded?22:36
bknudsonthey don't try to run current keystone with old database.22:36
gyeebut clients are talking to a VIP22:36
morganfainbergjamielennox, ping22:36
morganfainbergjamielennox, stevemar, for keystoneclient we really need to break the dep on lxml. we can either develop an egrep ourselves or we need to split federated plugin to it's own repo22:37
bknudsonif you can have the clients not do updates to the database then you could keep read-only going at least.22:37
*** alex_xu has quit IRC22:38
*** dims_ has quit IRC22:39
bknudsonfor keystone that would be no tokens so kind of a non-starter22:39
jamielennoxmorganfainberg: i agree22:41
jamielennoxdevelop an egrep?22:41
morganfainbergjamielennox, grep for the builtin default parser22:41
morganfainbergjamielennox, xml in python that is22:42
jamielennoxi think that we definitely want federation plugins into a new repo22:42
morganfainbergjamielennox, i think that is what is needed.22:42
morganfainbergjamielennox, ok i am happy to do that i'll work on that tomorrow.22:42
morganfainbergjamielennox, erm. crud... wait22:42
jamielennoxand yea, if there is a simple xml parser that can be done from python to at least keep the compatability with the old stuff22:42
morganfainberghmm.22:42
morganfainberglets see if we can do simple xml parser things first.22:42
morganfainbergmight be quicker and then we get the new repo spun up22:43
gyeebknudson, yeah, that's a problem22:43
dstanekcan't you use the parser that python provides? interface isn't as good as lxml, but you don't have the installation headaches22:43
morganfainbergdstanek, i think we can22:44
jamielennoxmorganfainberg: have we had a release with xml?22:44
jamielennoxlxml22:44
morganfainbergjamielennox, checking22:44
*** jorge_munoz has quit IRC22:44
morganfainbergjamielennox... yep.22:44
morganfainberg10.122:45
morganfainbergat least22:45
jamielennoxmorganfainberg: damn, but i figured as much22:45
morganfainbergif not more22:45
morganfainbergok we use the built-in parser22:45
morganfainbergi'll work on that instead22:45
morganfainbergwe can worry about the split later (ugh)22:46
jamielennoxmorganfainberg: i just re-uploaded the patch for the kerberos plugin, the federation one will be exactly the same if you think we should do it now22:47
morganfainbergjamielennox, yeah lets get it going.22:47
jamielennoxkeystoneclient-federation? keystoneclient-saml?22:47
jamielennoxto what level do we split it?22:47
jamielennoxi think -federation is ok22:48
*** bknudson has quit IRC22:53
jamielennoxmorganfainberg: ^ ?22:53
jamielennoxwow, gate is stupidly backed up22:57
*** nkinder has joined #openstack-keystone23:02
*** wanghong has quit IRC23:02
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/11162023:04
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/11914223:04
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/11625523:09
morganfainbergjamielennox, sure -federation sounds good23:09
morganfainbergcrud, we're using more xpath support than xml.etree.ElementTree can support :(23:10
morganfainbergjamielennox, i don't think this is going to be easy to do in pure python.23:12
morganfainbergpure python seems to be missing some of the xpath logic we actually need/use.23:13
jamielennoxi don't know that code well. Does that mean we have to manually parse it out23:15
ekarlso-jamielennox: yo23:15
jamielennoxekarlso-:23:15
ekarlso-up ? :)23:15
jamielennoxhi23:15
ekarlso-good morning australia ;)23:15
jamielennoxbeautiful day it's shaping up to be as well23:15
ekarlso-jamielennox: is there a way to register opts into a parser atm in the plugins ?23:19
jamielennoxekarlso-: yes, keystoneclient.auth.register_argparse_arguments and load_from_argparse_arguments23:20
jamielennoxthat creates an --os-auth-plugin field so that people can set the plugin they want and load those arguments to the parser23:21
jamielennoxif you want to create a default set of options (so you don't have to use --os-auth-plugin) then you can though it's not as obvious as i would like yet23:21
stevemarmorganfainberg, yo23:22
stevemarmorganfainberg, just caught up, wasn't this resolved by moving it to test-req?23:22
morganfainbergstevemar, seems like not? -infra was still having issues23:22
jamielennoxekarlso-: the return value from register_argparse_arguments is either the plugin that the user specified or none23:22
jamielennoxekarlso-: if it's none then you can register a different plugin23:23
jamielennoxi had a review for that...23:23
ekarlso-jamielennox: why not one way to register all opts for all plugins ? :/23:23
jamielennoxekarlso-: i'm not sure that makes sense, that list could get long23:23
jamielennoxbut if you want it you can do it fairly easily23:24
ekarlso-so --os-auth-plugin can be password or token ?23:24
jamielennoxuse stevedore, iterate the plugins on the auth namespace, then each plugin object has a function register_argparse_arguments23:25
jamielennoxso you can load them all if you ilke23:25
stevemarmorganfainberg, bah23:25
jamielennoxbut argparse doesn't allow you to have different plugins register the same parameter names23:25
jamielennoxso if you have multiple plugins saying they want --os-auth-url (like almost all will) you will need to do some sort of conflict resolution23:26
jamielennox--os-auth-plugin can take any plugin name, so password, token, v2password, v3token whatever23:26
ekarlso-jamielennox: any progress on the generic plugin23:27
jamielennoxekarlso-: gating as we speak i think23:28
jamielennoxekarlso-: so this patch https://review.openstack.org/#/c/113742/ was to let you specify a default value for cli23:29
jamielennoxbecause i don't think you should make all users specify a --os-auth-plugin on the cli23:29
jamielennoxmerged, not release i think23:29
jamielennoxi had another patch i can't find...23:29
ekarlso-jamielennox:23:30
jamielennoxah, because it's wrapped up in here: https://review.openstack.org/#/c/95680/923:30
ekarlso-well before u would just set OS_USERNAME OS_PASS or OS_TOKEN23:30
ekarlso-and it just worked :p23:30
jamielennoxso there is a file in there called auth/identity/cli.py23:30
jamielennoxit's not ready - i was waiting for the generic stuff23:30
jamielennoxso that plugin will be called cli23:30
jamielennoxso my intention is that other clients will do register_argparse_arguments(parser, default='cli')23:31
jamielennoxso that if a user doesn't specify an --os-auth-plugin it will invoke one that we prepared earlier and will accept the env variables like you said23:31
ekarlso-when will that be done ? :D23:31
jamielennoxumm, i haven't played with that one for a while, i was waiting for the generics23:32
ekarlso-:P23:32
morganfainbergstevemar, not sure how we can fix the need for full xpath support (with the idea that people should move to the new repo we're spinning off that can be lxml based)23:32
jamielennoxalso the CLIs i've tried to convert in the past are so tangled up with there own stuff that i was having to write a plugin specific to each CLI so i haven't been worried about a new standard one23:32
ekarlso-jamielennox: i guess no luck in getting it done before honeymoon :D23:33
dstanekdo commits with requirements changes in openstack-specs need to only use deps that are in global-requirements?23:33
jamielennoxekarlso-: doubtful, however i'll have a look today23:33
ekarlso-;P23:33
ekarlso-doh23:33
jamielennoxekarlso-: because it's not really that complex when you have the generic plugins23:34
morganfainbergdstanek, hm. it *should* be enforced23:34
morganfainbergdstanek, but it might not be23:34
morganfainbergdstanek, and honestly it probably doesn't matter23:34
morganfainbergstevemar, this might work in test-requires actually23:34
jamielennoxekarlso-: more i don't really know what people want there, obviously they want user/pass, i see various support for auth_url/token, and some that let you do endpoint/token23:35
ekarlso-:P23:35
dstanekmorganfainberg: ok, i have a scripts that tests for that and one of the reviews was failing23:35
morganfainbergdstanek, dhellmann's?23:36
dstanekyeah23:36
stevemarmorganfainberg, i was under the assumption that having it there would work23:36
ekarlso-jamielennox: could you try to whip up some stuff and I can try to follow up when you're away ;P23:36
morganfainbergstevemar, it does sortof work, but reality we still need lxml in -infra build machines for unit tests (icky)23:36
morganfainbergstevemar, long term losing lxml wont hurt anyone's feelings :P23:37
jamielennoxekarlso-: so what's in that review is a pretty good start, the concept is exactly the same as any other plugin23:38
jamielennoxekarlso-: you need to specify all the parameters your plugin takes, then you need a way to load the plugin from those parameters23:38
jamielennoxessentially then it's a matter of saying if --username or --user-id or whatever was passed then i want to use the password plugin23:39
jamielennoxif --token was passed i want to use the token plugin23:39
jamielennoxand load those plugins from your parameters23:39
jamielennoxthe reason that plugin is failing i think is more to do with me trying to hack that into what keystoneclient is using rather than a problem with the plugin itself23:40
ekarlso-jamielennox: u got some reviews I can look at ?23:40
jamielennoxhttps://review.openstack.org/#/c/95680/9/keystoneclient/auth/identity/cli.py23:40
jamielennoxfor more general how to write plugins there is a little bit in the docs23:40
jamielennoxotherwise your best bet is to look at the plugins that we already have23:41
jamielennoxthere is a fair bit of in-file documentation23:41
jamielennox(at least like function docs and such23:41
jamielennox)23:41
ekarlso-jamielennox: hmmm23:43
jamielennoxgyee: is dhu around?23:43
ekarlso-what plugin ops should the cli thing register ?23:43
ekarlso-I mean to me it seems it would need to have the opts of all the plugins :/23:43
ekarlso-at least generic23:43
jamielennoxanything that you want to pass from --os-*23:43
ekarlso-use "generiC" plugin ?23:43
jamielennoxso the combination of password and token i expect23:43
jamielennoxyes23:43
ekarlso-if you could get the generic ting merged it would ber awesome23:44
jamielennoxyep, gating - it's just really slow at the moment23:44
ekarlso-:;D23:44
*** richm1 has quit IRC23:44
*** harlowja has quit IRC23:48
*** harlowja_ has joined #openstack-keystone23:48
gyeejamielennox, no, he's in training this week afaik23:50
jamielennoxgyee: damn, is he going to summit?23:50
gyeejamielennox, not sure, I'll check with him23:51
jamielennoxi really need to have a talk with him about some of this session stuff23:51
jamielennoxjust saw a patch he did for heatclient which is gating23:51
gyeejamielennox, what's the issue?23:52
gyeeI think he's also working on a Nova CLI patch23:52
jamielennoxgyee: not the worst, he's reusing a lot of the old client code that i'm trying to destroy23:53
gyeeah23:53
jamielennoxalso the adapters and stuff are in a release now and so the code he's copying and pasting no longer needs to be23:53
jamielennoxi've seen the nova one23:53
*** zzzeek has quit IRC23:53
jamielennoxi didn't see the heat one till now23:53
gyeenice!, we can submit another patch to use the latest and greatest23:53
gyeeunless you want to do it23:54
gyeeI did ask him to add you to all his patches23:54
jamielennoxi might have been added - i've given up on trying to keep the gerrit mail under control23:55
gyeejamielennox, same here, my Outlook filter suck big time23:55
ekarlso-jamielennox: is the gate borked ? :D23:58

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