Wednesday, 2014-11-26

*** tellesnobrega_ has joined #openstack-keystone00:04
*** henrynash has quit IRC00:10
*** henrynash has joined #openstack-keystone00:12
*** ChanServ sets mode: +v henrynash00:12
*** htruta_ has joined #openstack-keystone00:14
*** jorge_munoz has left #openstack-keystone00:19
*** kobtea has joined #openstack-keystone00:30
samuelms_dolphm, is this still valid? https://bugs.launchpad.net/keystone/+bug/96317600:30
uvirtbotLaunchpad bug 963176 in keystone "Document should report that Users must have at least one role" [Medium,Incomplete]00:30
*** dims_ has quit IRC00:30
morganfainbergsamuelms_, that is likely still valid. i mean, you *could* have no roles, but it really becomes very strange.00:32
morganfainbergbut honestly, we might be ok if that goes away00:32
samuelms_morganfainberg, so we need to set to 'wont fix'?00:34
morganfainbergincomplete will expire out and disappear in 54 days00:34
samuelms_59 days, since I just messed up00:35
*** kobtea has quit IRC00:35
samuelms_status: Incomplete → Opinion00:35
samuelms_status: Opinion → Incomplete00:35
samuelms_morganfainberg, only core-reviewers can set a bug report to triaged/wont fix?00:36
morganfainbergright00:36
morganfainbergopinion also pretty much disappears00:36
* morganfainberg never looks at opinion bugs ever00:36
samuelms_morganfainberg, what does 'opinion' means in this context?00:37
morganfainberglike "wont fix" but more like "you think this is something and we don't"00:38
samuelms_morganfainberg, hmm.. so that's something I could do like: 'hey, you're making a mistake'00:39
samuelms_morganfainberg, and a core then mark it as wont fix ('yes, this wrong, get out of here')00:40
samuelms_:p00:40
morganfainbergeh00:40
morganfainbergi mean i'd discourage people from marking bugs as opinion because it makes them disappear00:40
morganfainberglike i said, i *never* look at opinion bugs00:40
samuelms_morganfainberg, ok00:41
samuelms_didnt pay attention at morganfainberg never looks at opinion bugs ever00:41
morganfainbergsimilar to the way i don't go back and look at wont fix bugs or invalid unless someone brings them back to an active state00:42
samuelms_makes sense00:42
samuelms_morganfainberg, how much time a day you reserve for reviewing patches?00:42
morganfainbergi don't have a fixed amount00:42
morganfainbergbut i can tell you tuesdays is next to nothing00:43
morganfainbergjust because i have at least 4 meetings.00:43
*** chrisshattuck has quit IRC00:43
samuelms_lol lot of meetings00:44
samuelms_I'll try to reserve at least 2h/day to do reviews ..00:44
samuelms_I think it's the best way to know what's going on00:45
stevemarmorganfainberg, i was idle00:48
stevemari am now sorta here, at best00:49
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Improves feedback message in SSL error  https://review.openstack.org/12976900:49
*** david-lyle is now known as david-lyle_afk00:51
openstackgerritRodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc  https://review.openstack.org/13499300:52
*** nkinder has joined #openstack-keystone00:52
openstackgerritMerged openstack/keystone: Use _ definition from keystone.i18n  https://review.openstack.org/13211600:56
openstackgerritwanghong proposed openstack/python-keystoneclient: add missing user-id option to auth.identity.generic.password  https://review.openstack.org/13262601:04
*** stevemar has quit IRC01:05
*** gokrokve has quit IRC01:06
*** esp has left #openstack-keystone01:13
jamielennoxmorganfainberg: do you have any ideas on where the context object should live?01:15
jamielennoxor anyone else here01:15
jamielennoxi'm almost certain oslo.context is a bad idea01:16
jamielennoxbut is our upcoming policy engine extract supposed to contain like a middleware piece? is it allowed to contain that much keystone specific information if it's not a keystone or oslo branded project01:17
jamielennoxayoung-dad-mode: ^01:17
rodrigodsHaneef, did you have some time to revisit https://review.openstack.org/#/c/130277/ and check Raildo's comments?01:17
*** tellesnobrega_ has quit IRC01:23
*** tellesnobrega_ has joined #openstack-keystone01:29
openstackgerritDavid Stanek proposed openstack/python-keystoneclient: Removes confusing _uuid property  https://review.openstack.org/13725301:30
*** dimsum__ has joined #openstack-keystone01:30
*** r-daneel has quit IRC01:32
*** dimsum__ has quit IRC01:36
*** dimsum__ has joined #openstack-keystone01:37
*** diegows has quit IRC01:37
*** jacorob_ has joined #openstack-keystone01:39
*** dimsum__ has quit IRC01:41
ayoung-dad-modejamielennox, keystoneclient...or keystonecommon if we do that01:42
jamielennoxyea, i'm just tryng to figure out how01:42
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Allow users to change own default_project_id  https://review.openstack.org/13725401:44
jamielennoxand whether we need to stop oslo.context01:45
jamielennoxdoes context creation want to be its own middleware, or should it hang off the plugin?01:46
*** dimsum__ has joined #openstack-keystone01:53
ayoung-dad-modewe need to stop oslo context02:01
*** ayoung-dad-mode is now known as ayoung02:01
ayoungit is not a middleware, but there will be multiple builders.02:02
*** lhcheng has quit IRC02:04
*** _cjones_ has quit IRC02:08
jamielennoxmultiple builders?02:14
*** raildo_ has joined #openstack-keystone02:24
*** richm has quit IRC02:27
*** erkules_ has joined #openstack-keystone02:28
*** erkules has quit IRC02:30
*** raildo_ has quit IRC02:35
*** erkules_ is now known as erkules02:36
*** NM has joined #openstack-keystone02:38
*** htruta_ has quit IRC02:49
*** gokrokve has joined #openstack-keystone02:52
*** gokrokve has quit IRC02:52
*** dimsum__ has quit IRC02:52
*** gokrokve has joined #openstack-keystone02:52
*** gokrokve has quit IRC02:53
*** gokrokve has joined #openstack-keystone02:53
*** gokrokve has quit IRC02:54
*** gokrokve has joined #openstack-keystone02:55
*** raildo_ has joined #openstack-keystone02:57
*** gokrokve has quit IRC02:59
*** NM has quit IRC02:59
*** gokrokve has joined #openstack-keystone02:59
*** gokrokve has quit IRC02:59
*** gokrokve has joined #openstack-keystone02:59
*** gokrokve has quit IRC03:00
*** gokrokve has joined #openstack-keystone03:00
*** fifieldt has joined #openstack-keystone03:01
*** gokrokve has quit IRC03:05
*** gokrokve has joined #openstack-keystone03:05
*** gokrokve has quit IRC03:06
*** gokrokve has joined #openstack-keystone03:07
*** gokrokve has quit IRC03:07
*** gokrokve has joined #openstack-keystone03:08
*** gokrokve has quit IRC03:08
*** gokrokve has joined #openstack-keystone03:12
*** gokrokve has quit IRC03:17
*** raildo_ has quit IRC03:24
*** harlowja is now known as harlowja_away03:29
*** _cjones_ has joined #openstack-keystone03:36
*** _cjones_ has quit IRC03:37
*** _cjones_ has joined #openstack-keystone03:38
jamielennoxayoung: still here?03:39
ayoungjamielennox, yep03:39
jamielennoxayoung: so with this context, i've already got an auth plugin that i'm passing out of auth_token03:39
ayoung"this context"  meaning what?03:40
jamielennoxi'm torn between whether i should just reuse that and make it do the context interface03:40
ayoungyou mean instead of what I submitted for review as a WIP?03:40
jamielennoxayoung: where did you submit?03:41
ayounghttps://review.openstack.org/#/c/137231/ jamielennox03:41
jamielennoxayoung: pshh, server side is for chumps :)03:41
ayoungjamielennox, heh.  Need it server side first03:42
jamielennoxayoung: different things03:42
ayoungwell *I* need it server side first03:42
jamielennoxso there's this: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/context.py03:42
ayoungyes, it is meant to replace that03:43
jamielennoxhttps://github.com/openstack/nova/blob/master/nova/context.py03:43
jamielennoxetc03:43
ayoungthe general rule is parse to canonical, munge to required form03:43
jamielennoxglance as well03:43
ayoungso we get a good canonical representation first03:43
ayoung user_idt  is an interesting approach03:44
jamielennoxayoung: so i don't know if all the type safe stuff is required but whatever03:44
ayoungheh03:44
jamielennoxi'm looking at what is sent into policy in non-keystone services03:44
ayoungnothing is required.  It just is good programming practice03:44
ayoungright03:45
jamielennoxcurrently they all create there own dict object03:45
jamielennoxwhich is loosely based around that incubator one03:45
jamielennoxand that's what's being extracted into oslo.context03:45
ayoungthat is what the  token_to_auth_context code is supposed to do, once I get it right:03:46
ayoungI don't need to copy it03:46
jamielennoxi already have https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L62703:46
jamielennoxwhat i'm wondering is if i just put the same to_dict, from_dict on that03:46
ayoungjamielennox, yes, but that assumes the form you've gotten in the token as a starting point03:47
*** amcrn has quit IRC03:47
ayoungI need to solve a wider array of problems, namely building the token up in the first place, as well as revocation events03:47
jamielennoxno, it assumes nothing03:47
jamielennoxayoung: which is why i consider client/server different things03:47
ayoungNo03:47
ayoungthe code in the client is going to run in the server eventually03:47
ayoungI need to fix the revocation evetns, and refresh that patch03:48
ayoungthis will come over when I do that03:48
jamielennoxthere's no reason non-keystone services need the ability to create tokens03:48
jamielennoxthis stuff is tightly coupled to auth_token middleware - i don't think it's relevant outside03:49
jamielennoxalthough i'm wondering whether i should have included it in auth_token middleware or made it a seperate piece03:49
jamielennoxanyway, all i would need to do is convert that _UserAuthPlugin into something with a to_dict() that matches what is currently required for policy03:50
ayoungthe term token is horrible.  It is no diffrent than cookie.  It means nothing except "remote handle to data"  so...lets kindof ignore that for a moment.,03:50
ayoungall this is to get the authorization data from keystone03:50
ayoungcall it auth context, or accsees info03:50
ayoungthey all need the same thing, and we are distributing our business logic03:50
ayoungnow,  yes, we have a wire format that is fairly well documented, so different consumers could parse it themselves03:51
ayoungbut this is what Keystone does, and it is our job to provide the common mechanisms around authorization03:51
ayoungso  beyond the token mechanism to deliver the data, we are going to do revocation checking and policy enforcement03:52
jamielennoxayoung: completely agree, and doing things on the server are great and that's not what matters at the moment03:52
jamielennoxayoung: right, this is all auth_token03:52
ayoungthis will be done in every server, and should be done in the client03:52
*** dimsum__ has joined #openstack-keystone03:52
jamielennoxright - but auth_token isn't used by keystone03:53
ayoungno, but policy is03:53
ayoungand revocation checking will be as well03:53
ayoungand they all need to use one mechanism03:53
ayoungauth_token with deferred evaluation will no longer be really doing anything other than ensuring that the token is unpacked03:54
ayoungand that the token itself is valid03:54
ayoungit really doesn't care about the body of the data itself...well, it does cuz it sets all the env vars03:55
ayoungnow, once we have revocation checking, then yes, it will care about the body of the token data.03:55
ayoungAnd that needs the access_info code03:55
*** dimsum__ has quit IRC03:57
jamielennoxayoung: so i guess what I need to know is a format that i can expose publicly that will work with current and future policy checking03:58
ayoungjamielennox, so that is what I am trying to document in that code03:58
ayoungjamielennox, can we switch over to talking about the Horizon stuff?03:59
jamielennoxayoung: you got time to do that now?04:00
ayoungyeah04:00
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Turn our auth plugin into a token intace  https://review.openstack.org/13726804:03
ayoungjamielennox, intace?04:03
jamielennoxayoung: so that's ^ really all i was thinking04:03
jamielennoxinterface04:04
ayoungand waht is IDT?04:04
jamielennoxayoung: comes from https://github.com/openstack/oslo-incubator/blob/master/openstack/common/context.py#L60 seems to be used04:04
ayoungI've heard of user = ID_10_T04:05
jamielennoxhuh, never thought of that04:05
ayoungI guess it is short for identity04:05
jamielennoxno, i'm not trying to be clever04:05
jamielennoxi want to have existing policy more or less work but not corner us on anything new04:06
jamielennoxto_dict probably shouldn't exist04:06
jamielennoxpolicy should create a dict based on the context object04:06
ayoungI mean in the original code:   'user_identity': user_idt04:07
jamielennoxbut given that that object already exists and contains an AccessInfo within itself, i've got a fairly good oportunity here to present a clean interface above it04:07
*** ncoghlan has joined #openstack-keystone04:07
ayoungthey are generating a unique id from the token's access data04:07
jamielennoxalready exists and is passed through auth_token middleware to everyone04:07
*** kobtea has joined #openstack-keystone04:07
jamielennoxunique to the auth, not to the request - possibly someone somewhere is using it as a hash key04:08
*** ncoghlan has quit IRC04:08
jamielennoxi'll remove it, i was just copying over things for a POC04:08
*** ncoghlan has joined #openstack-keystone04:08
ayoungI'd be interested to see where it is used.  It has domain info in it, which means it is relatively new04:08
jamielennoxso i'd need to add roles04:09
jamielennoxi don't want to add is_admin04:09
jamielennoxi think instance_uuid is a nova thing04:09
ayounghave you looked at what I laid out for policy?04:09
jamielennoxi was looking through that review you mentioned04:10
jamielennoxbut this is not that04:10
ayoungthe blog post04:10
ayoungif you are at all touching policy it most certainly is04:10
ayoungwe have a half dozen people going at policy, and we need to make sure we are not working at cross purposes04:11
jamielennoxi'm not touching really touching policy, if i don't include a to_dict then i04:11
jamielennox'm fairly indifferent04:11
ayoungso...please read http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/  to see where we are headed04:11
jamielennoxbut you're right, the AccessInfo structure is a mess and i don't really want to make that public to everyone04:11
jamielennoxso this is a chance to put a read only wrapper in front of it04:11
*** kobtea has quit IRC04:12
ayoungthe dictionary approach is only to keep from breaking existing code.  Places where we can use the straight python interface is obviously preferred04:12
ayounghence the focus on doing that first04:12
ayoungI'm really far more concerned that you understand and can guide what is going on in Horizon.  Working on that stuff in your absence was frustrating04:14
ayoungIts like the primary driver of requirements in Keystone04:14
ayoungand we've just got no clue there....04:14
morganfainbergayoung, no, horizon is *not* the primary driver.04:15
ayounghttps://review.openstack.org/#/c/121281/  is really something you need to take in hand04:15
ayoungmorganfainberg, stop contradicting me04:15
openstackgerritChangBo Guo(gcb) proposed openstack/keystone: Add library oslo.concurrency's option to keystone.conf.sample  https://review.openstack.org/13727004:15
morganfainbergayoung, horizon happens to be a reasonable consumer of Keystone04:15
morganfainbergayoung, haha i'm not strictly contradicting. there have been a lot of things i've agreed with you on recently04:15
jamielennoxayoung: i know this stuff, and that's not what i'm designing here04:16
jamielennoxi want this object to be considered your auth - in the same way that an auth_plugin should04:16
jamielennoxauth_token middleware will always produce the same type of plugin because it reads from keystone directly04:17
ayoungmorganfainberg, ok.  The # one thing we've had to deal with lately on my team is Federation04:17
ayoungand Federation and SAML really only works with WebUI04:17
jamielennoxi want to have this auth object passed to policy to make decisions04:17
morganfainbergAnd federation, whether that is via Horizon is a big driver for requirements in Keystone04:17
ayoungSo making Horizon work is essential to actualy having a consumable Federation  solution04:17
morganfainbergayoung, i'll definitely agree federation + the consumers of federation are drivers.04:18
jamielennoxso really what i'm concerned with here is presenting an interface that policy can read and make decisions on04:18
ayoungor, in short  Horizon is the primary driver of requirements in Keystone04:18
morganfainbergnope04:18
jamielennoxwhether that's a dictionary or not i don't care04:18
ayoungfor me04:18
ayoungfor jamielennox04:18
jamielennox(at the moment_04:18
ayoungfor nkinder04:18
morganfainbergayoung, jamielennox , there we go.04:18
ayoungOK?04:18
ayoungNow that we have the pedantry out of the way....04:19
morganfainbergayoung, mostly i didn't want someone else to step in and think we're only catering to Horizon. context.04:19
morganfainbergayoung, /me isn't sure what people are thinking / lurking /etc04:19
ayoungHorizon has been driving some of the limitations on Keystone, too, and the patch I linked to above is a prereq to fixing that, too04:19
* morganfainberg goes back to lurking.04:20
ayoungmorganfainberg, tell me if https://review.openstack.org/#/c/137231/ was basically what you want04:20
morganfainbergayoung, sec04:21
jamielennoxmorganfainberg: have a look at that WIP review, https://review.openstack.org/#/c/137268/04:21
ayoungI didn't do the workflow minus 1, but it is WIP04:21
morganfainbergmeh WIP or not, if i see a +2 on it i'd -2 if it wasn't ready... you know...04:21
ayoungmorganfainberg, I really didn't have too much fear of that happening.04:22
morganfainbergand i know you'd -2 if it you thought it was in jeapordy of going in too soon04:22
ayoung+2s are few and far between04:22
*** _cjones_ has quit IRC04:22
ayoungplus, I think only you and I are thinking this way on this topic....at least, I hope we are aligned04:22
morganfainbergwe were mostly there barring any implementation weirdness discussing it04:23
morganfainbergin general04:23
ayoungjamielennox, ok, you beat me...I'm too tired and near to bed time to discuss Django OpenStack Auth.   We'll postpone till next week04:24
jamielennoxayoung: i'm fine to do it, i just assume it'll take a while and it's got to be late04:24
ayoungjamielennox, lets get started now...04:24
ayoungstart here https://review.openstack.org/#/c/121281/7/openstack_auth/backend.py,cm04:25
morganfainbergayoung, so i have a neat trick to show you for applying some virtual / abstract methods to classes but this is the direction i was headed.04:25
ayoungmorganfainberg, Im not going to touch this code for a bit.  If you want to hack on it, please feel free04:25
morganfainbergnah, it may not be relevant here04:25
morganfainbergit's more of a, "you might like this for composition cases"04:25
ayoungI kindof want to avoid virtual/abstract actually for the core classes04:26
morganfainbergayoung, i'll show you the way it works after the weekend04:26
ayoungdeal04:26
morganfainbergayoung, i have like 40 work things to do this holiday :(04:26
morganfainbergsome HP some keystone.04:26
morganfainbergso, hacking on this is unlikely :P04:26
ayoungjamielennox, ok, so the issues are things like  where do we get the auth plugin, where we do put it after we authenticate and so on04:28
jamielennoxsure04:28
ayoungthe logic is split up somewhat arbitrarily between utils.py and backend.py04:28
ayoungthe Django form will call authenticate with the values on the form04:28
jamielennoxso if i see correctly the biggest problem is going to be that auth_plugins authenticate as required not when created04:28
ayoungjamielennox, we can almost work around that by treating the "list_projects" call as the authenticate04:29
jamielennoxright, but so what is the Token model they have? can we just replace that with an auth plugin?04:29
ayoungI think so04:30
ayoungas long as everything is contained within DOA, we can hack it04:30
ayoungI don';t think the token is passed to the actual Horizon app itself04:30
jamielennoxsomething has to cross that boundary04:31
ayoungjamielennox, http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/user.py#n5904:31
jamielennoxand ideally it would be the auth_plugin because that's what will get passed to the other clients04:31
ayoungso, yet another chunk of code that I want to replace with the Access Info code when it is ready...04:32
ayoungyeah04:32
ayoungusing the auth plugin in place of the token would be, I think, the right abstraction04:32
jamielennoxthere's no auth_token middleware involved here right?04:32
ayoungright04:32
jamielennoxobviously not here, but anyway in horizon?04:33
ayoungit requests tokens, it does not accept tokens04:33
jamielennoxs/anyway/anywhere04:33
ayoungnot yet.  If we make Horizon accept a token as a login form of authentication, that changes04:33
ayoungwe need either auth-token or an analogue04:33
jamielennoxif horizon is comfortable with AccessInfo as it is know then it can make a trivial plugin and control that interface itself04:34
jamielennoxs/know/now - really struggling with that one recently04:34
jamielennoxit would be essentially the same object that i created and just showed over in auth_token04:34
ayoungjamielennox, http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/backend.py#n18604:35
ayoungthat is where it is persisting the token across calls04:35
ayoungthe assumption is that the token is small enough to fit into a cookie04:35
ayoungright04:35
ayoung request.session['unscoped_token'] = unscoped_token.id04:36
jamielennoxayoung: so if we don't cross the boundary into horizon this is fairly simple, i was of the impression we would use that plugin throughout the entire request and pass that to other clients04:36
ayoungthere is a dashboard portion that is keystone specific, but it just makes KC type calls ... let's see04:37
ayounghttp://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py04:37
jamielennoxso line 190 it is saving the client to the request04:37
jamielennoxthat's what we want, to save the plugin to the request and be used everywher04:38
jamielennoxe04:38
ayounghttp://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py#n17104:38
ayoungline 190 of backend.py?  Yeah, I think so04:38
ayoungbut that is request scoped, not session, so once Horizon responds to the user, the object is gone04:39
ayoungSo we might have some slop over into Horizon04:39
ayoung conn = api_version['client'].Client(token=user.token.id,04:39
ayoungLet's get DOA settled, and we can then modify the Horizon code04:41
jamielennoxcool, so this works kind of how i think keystone should work04:41
jamielennoxthe request object is request scoped and gets passed to everything04:41
ayoungSo we'll have to leave the token id in the user object for the time being04:41
jamielennoxdifferent sections attach what they need and others use it04:42
ayoungFairly common in Server side scripting frameworks04:42
jamielennoxyep04:42
ayoungthe context object in Keystone used to be that way...it really is not a great abstraction for reusability, as you end up with lots of implied interfaces.04:43
ayoungBetter to treat the request as an explicit middleman, and have a "web API" specific set of classes for doing what you describe:  putting things into or getting them out of the request04:44
ayoungor the session, or the application, or global, as appropriate04:44
jamielennoxok, so if all we need to get is auth and get the token we can do this simply04:44
jamielennoxhttps://review.openstack.org/#/c/121281/7/openstack_auth/utils.py is no longer required04:44
jamielennoxreplaced by generic.Password04:44
jamielennoxnot sure about delete_token04:45
ayoungyeah, and if discovery is cached or shortcircuited, that wil work much better04:45
ayoungthat is wierd04:46
jamielennoxdiscovery is cached per session, to start that would probably be per client request04:46
ayoungthey delete tokens to revoke them when loggng out or switching projects04:46
ayoungif the KC session is scoped one-per to the Horizon application,  that should work04:46
ayoungthen KC.client  is request scoped, and the auth plugin is session scoped04:47
ayoungbut if all we can persist is the token id, maybe auth plugin becomes request scoped, too, for the first iteration04:48
jamielennoxwhat are the unit tests like?04:48
ayoungmediocre04:48
ayoungbut workable04:48
ayounghttp://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/tests04:48
jamielennoxdoesn't look like you've changed much04:49
jamielennoxprobably i just replace the mox with a requests_mock layer and it'll be the same04:49
ayoungIn that one,  I tried to make all the changes just straight refactorings04:49
ayoungI changed more in other commits04:49
ayoung++04:49
ayoungOK...I need to head to bed.04:50
jamielennoxok, i'll give it a look04:50
ayoungYou got enough to get started, I take it?04:50
jamielennoxyea, honestly it should be not too hard04:50
ayoungso, last piece of advice is to get friendly with rpdb04:50
ayoungif you do a devstack setup, use pip install rpdb and then you can step through code etc04:51
jamielennoxoh, damn yea, horizon will suck to debug04:51
openstackgerritWill Foster proposed openstack/keystone: skip assignment table migrate if duplicate entry exists. Closes-bug: #1395959 Change-Id: I394a0391ee074c3ee79bdb06391fc4d5fb9067a9  https://review.openstack.org/13694604:51
ayoungits not bad04:51
ayoungimport rpdb; rpdb.set_trace()04:51
ayoungthen from another window:  telnet localhost 444404:51
jamielennoxcould be worse - i could have to look at the javascript/css04:51
ayoungif you do cont, just remember to exit out of telnet04:52
ayoungyeah, I'll try to insulate you from that04:52
*** zzzeek has quit IRC04:52
jamielennoxno need to try - i'm not going anywhere near it04:52
ayoungyou can tell when I've been looking at javascript, as I start putting ; at the end of my lines04:52
jamielennoxheh04:53
ayoungthanks for looking at this.04:53
jamielennoxalright, i'll have a look and find you tomorrow with anything i don't understand04:53
ayoungthere is also a development server for Django04:53
ayoungdavid-lyle_afk, and company would be better for pointing you at how to get started with that, but rpdb should carry you through04:54
jamielennoxso do i need a db or anything for testing?04:55
jamielennoxrun_tests fails with a clean checkout04:55
*** henrynash_ has joined #openstack-keystone04:57
*** ChanServ sets mode: +v henrynash_04:57
*** henrynash has quit IRC04:57
*** henrynash_ is now known as henrynash04:57
ayoungjamielennox, if you do devstack, you need enough other services up to get logged in...really just keystone04:58
ayounghorizon itself has no database.  Which is why they keep trying to cram user info into Keystone04:58
ayoungOK..bed04:59
*** ayoung is now known as ayoung_ZZzz_zzZZ04:59
*** nellysmitt has joined #openstack-keystone05:03
openstackgerritWill Foster proposed openstack/keystone: skip assignment table migrate if duplicate entry exists.  https://review.openstack.org/13694605:04
*** bjornar has quit IRC05:06
*** nellysmitt has quit IRC05:08
*** _cjones_ has joined #openstack-keystone05:09
*** bjornar has joined #openstack-keystone05:11
*** stevemar has joined #openstack-keystone05:13
*** ChanServ sets mode: +v stevemar05:13
*** _cjones_ has quit IRC05:13
*** _cjones_ has joined #openstack-keystone05:28
samuelms_dolphm, did you already started sql-id-binary-16 ?05:34
openstackgerritMerged openstack/keystone: Move check_output and git() to test utils  https://review.openstack.org/13066205:35
*** stevemar has quit IRC05:36
openstackgerritMerged openstack/keystonemiddleware: Docstring cleanup  https://review.openstack.org/12708405:43
*** gokrokve has joined #openstack-keystone05:50
*** henrynash has quit IRC05:51
*** gokrokve has quit IRC05:52
*** _cjones_ has quit IRC05:59
*** stevemar has joined #openstack-keystone06:01
*** ChanServ sets mode: +v stevemar06:01
*** k4n0 has joined #openstack-keystone06:03
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/13624306:06
*** _cjones_ has joined #openstack-keystone06:08
openstackgerritMerged openstack/python-keystoneclient: Remove useless log message  https://review.openstack.org/13129406:10
openstackgerritDave Chen proposed openstack/keystone: Reduce database query statement  https://review.openstack.org/13313506:19
*** ukalifon1 has joined #openstack-keystone06:27
*** stevemar has quit IRC06:34
*** samuelms_ has quit IRC06:37
*** afazekas has joined #openstack-keystone06:50
*** jacorob_ has quit IRC06:51
*** ajayaa has joined #openstack-keystone06:52
*** Shohei has quit IRC07:00
*** Shohei has joined #openstack-keystone07:00
*** Shohei has quit IRC07:03
*** nellysmitt has joined #openstack-keystone07:04
*** nellysmitt has quit IRC07:09
*** fifieldt has quit IRC07:16
*** henrynash has joined #openstack-keystone07:22
*** ChanServ sets mode: +v henrynash07:22
*** ncoghlan has quit IRC07:35
*** henrynash has quit IRC07:46
*** mitz- has joined #openstack-keystone07:51
*** mitz_ has quit IRC07:51
*** nellysmitt has joined #openstack-keystone07:57
*** Shohei has joined #openstack-keystone08:11
*** _cjones_ has quit IRC08:15
*** oomichi has quit IRC08:17
*** ukalifon1 has quit IRC08:29
*** mitz_ has joined #openstack-keystone08:34
*** mitz- has quit IRC08:36
*** jistr has joined #openstack-keystone08:59
*** ukalifon1 has joined #openstack-keystone09:02
*** bjornar has quit IRC09:06
*** kobtea has joined #openstack-keystone09:15
*** kobtea has quit IRC09:20
*** bjornar has joined #openstack-keystone09:24
*** afazekas has quit IRC09:33
*** afazekas has joined #openstack-keystone09:48
*** afazekas has quit IRC10:07
*** afazekas has joined #openstack-keystone10:20
*** samuelms_ has joined #openstack-keystone10:25
*** KanagarajM has joined #openstack-keystone10:34
*** aix has joined #openstack-keystone10:34
*** tellesnobrega_ has quit IRC10:49
*** tellesnobrega_ has joined #openstack-keystone10:52
*** NM has joined #openstack-keystone10:56
*** junhongl has quit IRC11:01
*** junhongl has joined #openstack-keystone11:02
openstackgerritMarek Denis proposed openstack/keystone: Scope federated token with 'token' identity method  https://review.openstack.org/13059311:04
*** diegows has joined #openstack-keystone11:10
*** samuelms_ has quit IRC11:14
*** tellesnobrega_ has quit IRC11:14
openstackgerritMarek Denis proposed openstack/keystone-specs: Scope federated tokens with ``token`` auth method.  https://review.openstack.org/13702011:29
*** diegows has quit IRC11:30
*** diegows has joined #openstack-keystone11:47
*** jamielennox is now known as jamielennox|away11:48
*** ioram has joined #openstack-keystone11:48
*** aix has quit IRC12:07
*** ioram has quit IRC12:10
*** raildo has quit IRC12:13
*** raildo has joined #openstack-keystone12:26
*** KanagarajM has quit IRC12:28
*** ajayaa has quit IRC12:41
*** kobtea has joined #openstack-keystone12:53
*** kobtea has quit IRC12:58
*** bjornar has quit IRC13:05
*** ioram has joined #openstack-keystone13:07
samuelmshttps://blueprints.launchpad.net/keystone/+spec/remove-role-metadata13:14
*** aix has joined #openstack-keystone13:20
*** ioram has quit IRC13:23
*** ajayaa has joined #openstack-keystone13:36
*** toddnni has quit IRC13:39
*** gordc has joined #openstack-keystone13:42
openstackgerritgordon chung proposed openstack/keystonemiddleware: Adding audit middleware to keystonemiddleware  https://review.openstack.org/10295813:50
openstackgerritgordon chung proposed openstack/keystonemiddleware: documentation for audit middleware  https://review.openstack.org/13034413:50
*** dimsum__ has joined #openstack-keystone13:51
openstackgerritMarcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend  https://review.openstack.org/10224414:02
*** svasheka has joined #openstack-keystone14:08
svashekahi14:08
svashekacan someone tell me how to rename keystone role ?14:09
*** nkinder has quit IRC14:10
*** toddnni has joined #openstack-keystone14:17
*** ayoung_ZZzz_zzZZ is now known as ayoung14:21
samuelmssvasheka, I think we don't have this operation exposed to the API14:24
samuelmsayoung, morning, you confirm this ^ ?14:25
samuelmssvasheka, what roles you'd like to rename, specifically? admin one or other you've created?14:25
svashekaadmin14:26
svashekaI ment using mysql and stuff14:26
samuelmssvasheka, even if it were possible, I discourage you to do this ..14:27
samuelmssvasheka, the code in some projects are prepared to have the admin role changed .. (there are some hard coded checks that check for the role name 'admin')14:27
samuelmssvasheka, we have this in mind and need to fix this14:28
samuelmsdolphm, ping .. few minutes to talk about sql-id-binary-16 spec?14:36
*** r-daneel has joined #openstack-keystone14:37
openstackgerritBrant Knudson proposed openstack/keystone: Add missing translation marker for dependency  https://review.openstack.org/13682414:43
openstackgerritBrant Knudson proposed openstack/keystone: Fix tests using extension drivers  https://review.openstack.org/12460314:43
openstackgerritBrant Knudson proposed openstack/keystone: Avoid multiple instances for a provider  https://review.openstack.org/12459914:43
openstackgerritBrant Knudson proposed openstack/keystone: TestAuthPlugin doesn't use test_auth_plugin.conf  https://review.openstack.org/13736714:43
openstackgerritMarek Denis proposed openstack/keystone: Scope federated token with 'token' identity method  https://review.openstack.org/13059314:47
*** jjulien_ has joined #openstack-keystone14:49
*** zzzeek has joined #openstack-keystone14:53
*** jacorob_ has joined #openstack-keystone14:55
*** jacorob_ has quit IRC14:56
*** nkinder has joined #openstack-keystone14:58
ayoungsvasheka, if you want to see the complexity involved read this:  http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/15:04
*** saipandi has joined #openstack-keystone15:08
openstackgerritWill Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists.  https://review.openstack.org/13694615:09
*** david-lyle_afk is now known as david-lyle15:28
*** dimsum__ has quit IRC15:28
*** stevemar has joined #openstack-keystone15:28
*** ChanServ sets mode: +v stevemar15:28
*** dimsum__ has joined #openstack-keystone15:29
*** gokrokve has joined #openstack-keystone15:30
*** radez is now known as radez_g0n315:32
svashekaayoung, thank you15:34
svashekaI am reproducing bug connected with complexity you are telling about)15:34
openstackgerritMarcos Fermín Lobo proposed openstack/keystone: Templated catalog backend not implemented  https://review.openstack.org/12001115:42
*** afazekas has quit IRC15:58
*** dimsum__ is now known as dims16:03
*** ukalifon1 has quit IRC16:05
*** henrynash has joined #openstack-keystone16:08
*** ChanServ sets mode: +v henrynash16:08
*** _cjones_ has joined #openstack-keystone16:08
stevemarafter adding a 'paging' value to the keystone config file, i was hoping that user-list or group-list would work, but instead it's just crapping out with INSUFFICIENT_ACCESS: {'desc': 'Insufficient access'}16:11
stevemaranyone know whats up? lookin' at you ayoung since you're the ldap guy16:11
bknudsonstevemar: do you have domain-specific backends?16:13
stevemarbknudson, no, just one domain, and one identity backend being ldap16:14
stevemari bootstrapped and gave a user (me) the admin role on the admin project16:15
*** NM1 has joined #openstack-keystone16:15
bknudsonstevemar: it's the LDAP server returning insufficient access?16:16
stevemarbknudson, yep16:16
*** zigo has quit IRC16:16
bknudsonstevemar: are you connecting with a user that has authority to use the paging control?16:17
stevemarbknudson, probably not!16:17
stevemardidn't know that was a thing16:17
bknudsonI'm sure it depends on the server16:17
*** NM has quit IRC16:18
bknudsonI'd think a server wouldn't allow it for just anyone because it requires storing some state on the server and could be a potential DOS16:18
stevemari'm guessing our own ldap enforces that then, since i can't think of another reason16:18
bknudsondoing a user-list on an entire LDAP directory is probably not something you want to do anyways16:19
stevemaryeah, thats why i was playing around with paging16:20
stevemarbut meh16:20
stevemarbknudson, oh nice, do our CLIs not have filtering support for list operations?16:21
bknudsonstevemar: I don't know... haven't tried it. That's what curl is for.16:22
ayoungstevemar, paging dumb?16:23
stevemarayoung, not dumb just picky16:23
ayounginsufficient access looks like an access controll16:23
stevemarbknudson, quit using curl and help with the command line efforts :P16:23
ayoungno paging is a dumb idea...having gotten that out of the way...16:23
ayoungstevemar, I have not looked at how paging is implemented.  I'm guessing that it asks something of the LDAP serve rthat the server doesn't want to permit.  Paging requires a long lived connection, so I'm guessing it is that16:24
ayoungnkinder, does my explanation to stevemar make LDAP sense?16:25
stevemarayoung, yeah, i'm thinking that's the case16:25
stevemarbknudson, already explained the possible DoS scenario if everyone could page16:25
ayoungstevemar, more logging, find out "insufficient access" to what16:25
marekdmorganfainberg: around?16:26
*** zigo has joined #openstack-keystone16:27
*** nellysmitt has quit IRC16:30
*** gokrokve_ has joined #openstack-keystone16:30
*** k4n0 has quit IRC16:30
*** kobtea has joined #openstack-keystone16:30
*** gokrokve has quit IRC16:31
*** NM1 has quit IRC16:34
*** kobtea has quit IRC16:35
*** packet has joined #openstack-keystone16:35
*** packet has quit IRC16:37
marekdnkinder: hi. So if i understand correctly, you want to match groups a user brings in his assertion with a role assignments configured in keystone?16:38
openstackgerrithenry-nash proposed openstack/keystone: Split the assignments manager/driver.  https://review.openstack.org/13095416:42
stevemarmarekd, yeah nkinder brought this up in paris16:43
stevemari think it's worth investigating16:43
marekdthat's what i am doing.16:43
*** gokrokve_ has quit IRC16:45
henrynashmorganfainberg, samuelms: new patch with roles in their own backend, but part of assignment is up: https://review.openstack.org/#/c/130954/16:48
nkindermarekd: hey16:50
marekdnkinder: responding now to the e-mail.16:50
nkindermarekd: yeah, that's pretty much it.  Pass the groups through from the assertion and allow a role assignment to happen without group creation or mapping changes.16:50
marekdnkinder: ok, but then a group whitelisting is a must.16:51
marekdnkinder: otherwise my CERN's idp admin can make me a member of group 'superadmin' and i will automagically become admin member in Rackspace cloud.16:51
marekdnkinder: do you agree?16:51
*** NM has joined #openstack-keystone16:52
nkindermarekd: this would be useful in the case where you want to control roles purely off of the LDAP groups that the IdP uses when constructing the assertion16:52
samuelmshenrynash, great! I'm going to take a look at it tonight16:53
nkindermarekd: in the case you describe, that may not be desirable16:53
marekdwhy?16:53
nkindermarekd: so whitelisting/blacklisting would be a nice addition16:53
nkindermarekd: well, you seem to be saying that you don't want to just trust the assertion for the 'superadmin' group16:54
*** _cjones_ has quit IRC16:54
marekdnkinder: kind of. i trust the assertion but i want to be able to control who can do what on my cloud...16:54
nkindermarekd: and that's fine, but it's a deployment specific concern.  The blacklist/whitelist would solve that sort of case where one group wants to control the cloud, and one wants to control the IdP/LDAP.16:55
nkinderIf that is the same person/group that runs both, then may want to control it all via LDAP grouping16:55
nkinderSo 100% passthrough would be ideal in that scenario.16:55
marekdnkinder: in that case, yes16:55
nkindermarekd: they are both valid use cases16:55
marekdbut in general i'd make this black/white listing not an optional feature. rather a 100% passthrough a cornercase of empty black/whitelists16:56
nkinderso passthrough with a blacklist/whitelist adds a lot of flexibility16:56
nkindermarekd: sure, they can go together16:56
marekdnkinder: ok16:56
marekdnkinder: so you want to be able to add a role assignment poiting to a keystone group even though the group doesn't exist. Do you want the group to be created then (wile adding a role assignment)?16:57
nkindermarekd: no, no need to actually add it I think (though we may want a mapping table like the multi-domain feature uses)16:58
marekdnkinder: hm, i wonder if it would change a lot in role assignments code.16:59
marekdthose ephemeral groups.16:59
marekdnkinder: do you think we still need to tie IdPs to domains?16:59
*** jdennis1 has joined #openstack-keystone16:59
nkindermarekd: I think so, otherwise how do we differentiate between two groups with the same name from different IdPs?17:00
marekdnkinder: right, it is covered by mapping rules now.17:01
marekdbut, if we tie IdPs to different domains...17:01
*** jdennis has quit IRC17:01
marekdnkinder: how can we let users from 2 separate IdP work on one project together.17:01
marekdwe should let scope to different domains basing on other parameters?17:03
marekdnkinder: you know what i mean?17:06
marekdayoung: morganfainberg: dolphm: stevemar: appreciate if you could take a look at the 'alternatives' (esp bullet no. 2) in https://review.openstack.org/#/c/135604/6/specs/kilo/k2k-service-providers.rst as it is something that is being requested but this also complicates everything.17:14
marekdnkinder: ^^ you too17:14
marekdrodrigods: and you, sir!17:14
nkindermarekd: got pulled into a meeting.  Will look in a bit...17:15
marekdnkinder: sure.17:15
ayoungmarekd, I have real problems with a lot of K2K.  I've stayed out of it because I don't really have a reason to wade in.17:15
marekdayoung: understood.17:15
ayoungK2K to me is two completely separet things17:15
ayoung1.  Identity17:16
ayoung2. Authorization17:16
*** jorge_munoz has joined #openstack-keystone17:16
*** henrynash has quit IRC17:16
rodrigodsmarekd, ++ taking a look on it17:16
openstackgerritAlexander Makarov proposed openstack/keystone: Trust redelegation  https://review.openstack.org/12689717:17
stevemarmarekd, i dont like #2 because i feel it locks us in to using saml from now on17:18
marekdstevemar: how do you configure openid ?17:19
stevemarmarekd, there is no exchange, you just need the right client id and client secret17:19
openstackgerritAndre Aranha proposed openstack/keystone: Creating a policy sample  https://review.openstack.org/12350917:19
marekdstevemar: well, i don't think it makes us use saml only, as i proposed that metadata would be a blob, attribute in a RESTful JSON request.17:20
marekdstevemar: you could send something else for the openid17:20
marekdstevemar: but that's far away as we would need to implement all that stuff in Keystone17:21
*** jorge_munoz has quit IRC17:21
stevemaryeah... no need to take it into account for today17:21
marekdstevemar: what I am fearing that we may end up trying to make Keystone legitimate SAML IdP and prepare for being ready OpenId identity provider17:21
marekdok, please simply leave your comments17:22
stevemaryeah i fear the same thing17:22
marekdas i want to keep the ball rolling.17:22
openstackgerritAndre Aranha proposed openstack/keystone: Modify the default policy  https://review.openstack.org/12350917:22
marekdrodrigods: the point is to not make people make up SP names :-)17:23
stevemarnkinder, let me know when you get back from your meeting, have a question about listing users in a group from ldap17:23
marekdrodrigods: imagine you need to add 150 (or 1500) SPs17:23
marekdrodrigods: you'd need to make up 150 unique names17:23
marekdthat are informative enough17:23
marekdok, need to run, bbl.17:24
*** jorge_munoz has joined #openstack-keystone17:27
rodrigodsayoung, https://etherpad.openstack.org/p/policy-library-name :P17:27
ayoungrodrigods, it really is a rules engine...its like prolog implemented in pyuthon17:30
ayoungbut I can't quite craft that into a name17:31
ayoungrodrigods, maybe we should just replace the policy engine with prolog17:32
rodrigodsayoung, haha17:33
ayoungrodrigods, have you ever coded in prolog?  Once you get the hang of it, it is very elegant...and fun17:34
rodrigodsayoung, just in a tiny project in the university... Logic discipline17:34
ayoungMake files are the most exposure people ever get to this kind of coding....Make has too many idiosyncracies to make it a pleasant experience for most people, though.17:34
openstackgerritSergey Skripnick proposed openstack/python-keystoneclient: Raise proper exception in case of connection error  https://review.openstack.org/13742217:34
rodrigodsrodrigods, grandfather(X, Y) :- father(X, P), father(P, Y). :)17:35
rodrigodsayoung, ^17:35
ayoungthat is the usual example, isn't it17:35
rodrigodsayoung, yep17:35
rodrigodscousin too hehe17:36
ayoungmore like first-cousin-once-removed17:36
ayoungbut in this case, we are implementing rules logic in python.17:37
ayoungWe call it policy, but that is just what we *use* it for17:37
*** _cjones_ has joined #openstack-keystone17:37
rodrigodsayoung, yeah, good point17:37
ayoungI wonder if there is prior art...17:37
ayounghttp://pyke.sourceforge.net/17:38
ayounghttp://pyke.sourceforge.net/pyke_syntax/index.html17:38
ayounglooks familiar....17:38
*** gokrokve has joined #openstack-keystone17:39
ayoungyeah, we should be using something like that17:39
ayoungIf we want to use Prolog:  https://code.google.com/p/pyswip/17:40
rodrigodsayoung, we could just parse the policy rules and enforce using it17:40
ayoungrodrigods, have you ever heard me rant on the word  "just" before?17:41
ayoungheh17:41
rodrigodsayoung, hehe yeah, sorry :P17:41
ayoungyou parse our existing policy files and turn them into prolog?  Interesting.17:41
*** _cjones_ has quit IRC17:41
ayoungProbably not a "just"  but not a bad thought.17:41
*** _cjones_ has joined #openstack-keystone17:41
rodrigodsayoung, wonder if the person who introduced policies, thought about it being just logic programming paradigm17:42
ayoungI sense that they did, or at least suspected as much.17:43
openstackgerritWill Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists.  https://review.openstack.org/13694617:43
rodrigodsayoung, way to far from my Logic classes, didn't make the connection until now17:43
ayoungrodrigods, when last I coded in Prolog, Bush was the President.  And I don't mean 'W'17:48
rodrigodsayoung, http://alloy.mit.edu/alloy/ have you heard about it? People are using it here instead of prolog17:48
rodrigodsayoung, impressive memory than :P17:49
ayoungI think I took comparitive programming languages in Sophmore year,  so 1990-9117:49
ayoungone of the things is that we want the policy files limited to just checking policy.  Just like we wouldn't want people uploading python code and executing it blindly, Prolog is a general purpose language, and can have security implications17:50
rodrigodsayoung, didn't thought about *actually* using it anyway17:50
*** NM has quit IRC17:51
openstackgerritHenrique Truta proposed openstack/python-keystoneclient: Inherited role domain calls on keystoneclient v3  https://review.openstack.org/11608117:51
ayoungI think we want to stick with the existing policy file format for now, as it is the limited set of operations that we need.17:51
ayoungAs far as what to call it...meh17:51
ayoungI don't think Alloy, as it is a Java project.  Lets avoid adding in additional virtual machine formats17:52
*** jistr has quit IRC17:56
ayoungrodrigods, I really like what I'm seeing around Pyke17:57
ayoungrodrigods, the token and other stuff from the context would be the fact base18:00
ayoungthe policy would be the rules base18:00
ayoungIt might not be set up for the scalable querying that we need, though18:00
rodrigodsayoung, right18:01
ayoungrodrigods, i think the " my_engine.reset()" approach won't work.  We couldn't share the engine across multiple requests18:02
morganfainbergmarekd: will look at that spec this morning. But I am mostly out today due to family + travel.18:03
ayoungbutif we don't the engine would just explode in size18:03
ayoungso what we are doing has an additional constraint beyond prolog/pyke:  evaluate a given context while flyweight sharing of the rules.18:04
*** browne has joined #openstack-keystone18:04
*** harlowja_away is now known as harlowja18:04
morganfainbergAyoung: without context, this sounds like a request scoped object dep would be suitable? case but like I said... No context.18:05
rodrigodsayoung, yeah, let's just choose a name and once the lib is in place we can check alternatives for its growth :)18:05
rodrigodsmorganfainberg, fyi: ldap tests for HM are in place :)18:06
morganfainbergrodrigods: those probably are going to need a rebase against master. I'll help, so we can squash the topic branch ASAP.18:07
morganfainbergrodrigods: but awesome!!18:07
*** _cjones_ has quit IRC18:07
ayoungmorganfainberg, I was just looking for prior art on rules enforcement in the context of policy.  Pyke seems like a logical start point, but it really doesn't fit our usage18:07
*** _cjones_ has joined #openstack-keystone18:08
morganfainberg++ yay! I like prior art if we can use it. But step one: graduate what we have. Then grow the superpowers of the lib.18:08
morganfainbergI think a wholesale change is going to be too much in this one step. But adding / migrating to a better enforcement Lang. Is def on the table b18:09
morganfainbergIf we do it all at once I think we will never get adoption of the lib ( never more like v3 keystone never, not really never)18:10
rodrigodsmorganfainberg, ++18:12
ayoungmorganfainberg, all this grew out of what to name the library.  It is rules programming, but with the flyweight bent required by the load of a web application18:16
morganfainbergHehe.18:16
morganfainbergTwo hard things in computer science ...18:17
ayoungin the Authorization literature, it is the implmenetation of a policy decision point or PDP18:17
morganfainbergCache coherency , naming things, and off by one errors.18:17
ayoungoooh,m interesting http://en.wikipedia.org/wiki/Common_Open_Policy_Service18:18
ayoungKeystone COPS turns up again18:18
*** harlowja has quit IRC18:18
morganfainbergSome one totally backronymed that.18:18
ayoungdead link to the implementations, though18:18
morganfainberg:p18:19
ayoungJanuary 200018:19
ayoungnot new18:19
*** harlowja has joined #openstack-keystone18:19
rodrigodsayoung, morganfainberg, best name so far: pyrulz :D18:19
morganfainbergThat rfc, while potentially useful for our case is targeted at qos18:20
ayoungnice18:20
ayoungpyrulz rulz!18:20
morganfainbergrodrigods: I think I still want a coffee reference in there. :P18:21
rodrigodsmorganfainberg, https://etherpad.openstack.org/p/policy-library-name18:21
morganfainbergPyrulz isn't bad. It isn't taken is it?  Also remember we're going to need to get the tc and possibly openstack legal involved on this :(18:22
rodrigodsmorganfainberg, ayoung, honesty is nice too (by dolphm )18:22
ayounghe likes his word games, but you need to follow his logic first.  You need to explain to people why the project is named Kite, for example18:23
morganfainbergBut keys... Cloud... Yeah.18:24
*** NM has joined #openstack-keystone18:26
morganfainbergayoung: cloud open policy engine, COPE18:31
ayoungOooh18:31
* morganfainberg needs to bug Topol. We might actually want to push this to a standard like pycadf18:32
ayoungHypertext Open Policy Engine18:32
ayoungParallel Open Policy Engine18:32
ayoungScalable Open Policy Engine18:32
morganfainbergNo, not pope :P18:32
ayoungScalable Open Authorizatione Policy18:32
morganfainbergHah.18:33
rodrigodsnforce18:33
rodrigodspynforce (htruta)18:33
ayoungOpen Policy Engine Next18:33
samuelmsauthorizer18:33
ayoung^^ is something you'd get from the FSF18:34
ayoungTerribly Redundant Open Policy Engine18:34
ayoungNext Open Policy Engine18:35
* ayoung is enjoying himself way too much here18:35
samuelmshah18:36
htrutaGreat Open Authorization Technology18:36
nkinderstevemar: back.  What's up?18:37
ayoungGnu Open Authorization Technoloy Redundant Open Policy Engine18:37
morganfainbergYou need to get rodeo as the second word.18:38
ayoungthat is the CentoS version18:38
ayoungGnu Open Authorization Technology-RDO18:38
stevemarnkinder, so i think i narrowed it down18:39
morganfainbergHah.18:39
ayoungstevemar, this the authorization issue with paging?18:39
*** ajayaa has quit IRC18:40
stevemarnkinder, i was using emailAddress instead of uid as the ldap attribute, that was working for me initially, but died when i tried to do a user list for a known group18:40
stevemarayoung, nah18:40
stevemarnkinder, because the results of a group member list were just uids18:40
stevemaranyway, i'm playing around with it now, and set the user-id attribute to uid. but now i'm failing authorization18:41
*** harlowja_ has joined #openstack-keystone18:41
nkinderstevemar: the group members need to be DNs, not uids18:42
*** ajayaa has joined #openstack-keystone18:42
morganfainbergnkinder: unless you do evil standards breaking awfulness.18:43
morganfainberg*cough*ive never done that ever inswear*cough*18:43
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation  https://review.openstack.org/13154118:44
nkindermorganfainberg: you're not alone.... entire operating systems do that for LDAP group membership too18:44
*** harlowja has quit IRC18:45
*** aix has quit IRC18:45
morganfainbergI know :(18:46
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation  https://review.openstack.org/13154118:46
*** NM has quit IRC18:47
stevemarnkinder, sent you a bunch of PMs18:48
nkindermarekd: for the case you mentioned previously (users from multiple IdP sharing the same project), wouldn't you just use the same domain for those IdPs?18:48
nkindermarekd: there's nothing wrong with mapping multiple IdPs to one domain18:49
morganfainbergnkinder, doesn't even need to be the same domain (unless you're getting into strict HM-reseller security cases)18:50
morganfainbergnkinder, you just assign a role to that user/group/whatever on that project18:50
morganfainbergor even craft a good mapping rule to make it so *all* members from that IDP can share the project18:51
* morganfainberg wonders why he's not on vacation yet.18:51
crinklestevemar: do you happen to know how often distros update their packages for python-openstackclient? ubuntu seems to be lagging a little18:52
stevemarcrinkle, that i don't know, we just post to pypi, what version are you seeing?18:53
crinklestevemar: ubuntu has 0.3.0 http://packages.ubuntu.com/trusty/python/python-openstackclient18:53
stevemaryeesh thats old18:54
crinklefedora is a little more up to date https://apps.fedoraproject.org/packages/python-openstackclient18:54
morganfainbergcrinkle, UCA should be more up-to-date18:55
morganfainbergcrinkle, check cloud archive for ubuntu.18:55
morganfainbergthe base packages will always be waaaaay out of date18:55
morganfainbergand likely fedora will have a similar EPEL etc.18:56
morganfainbergthough ayoung and nkinder could speak to that more readily18:56
nkindercrinkle: so we update the version when preparing for new releases, then on-demand as needed (for fixing important bugs, pulling in a new feature that's important, etc.)18:57
ayoungmorganfainberg, I'm not really certain what the ubuntu process is.  Fedora is probably more akin to Debian upstream than to Ubuntu,  with Ubuntu more comparable to RHEL/CentOS.18:58
ayoungalbeit the parallels break down.18:58
crinklemorganfainberg: I'm not seeing it on uca18:58
morganfainbergcrinkle, thats unfortunate18:58
morganfainbergcrinkle, i am used to UCA being much more up to date18:58
ayoungcrinkle, you might want to start by looking in Debian testing, and then ....18:58
morganfainbergayoung, ++ or unstable18:59
ayoungnot sure the process to get Ubuntu to update,18:59
morganfainbergayoung, in this case i think it's really UCA needs to be updated.18:59
nkindercrinkle: 0.3.0 is pretty old...18:59
ayoungmorganfainberg, could be.  Not sure what the criteria is that Ubuntu uses to say that a package is ready for inclusion18:59
morganfainbergayoung, and UCA comes from upstream direct i think.18:59
morganfainbergnot debian18:59
ayoungUCA?18:59
morganfainbergthough zigo probably knows18:59
morganfainbergubuntu cloud archive18:59
morganfainbergits where releases of OpenStack are located19:00
morganfainbergcrinkle, i'd chase down zigo for packaging info, he's the openstack debian packager (and does it in his free time iirc), super awesome guy to get info on this from.19:01
crinklemorganfainberg: awesome, thank you19:01
* morganfainberg doesn't have any direct cannonical contacts or i'd point you at them as well19:01
*** NM has joined #openstack-keystone19:02
morganfainbergthough pliea2 (in openstack-infra) might have contacts, she's involved with ubuntu community i think.19:02
morganfainbergpleia2?19:02
* morganfainberg might be dyslexic today19:03
nkindermorganfainberg: I before E except after C... ;)19:03
crinkleokay cool19:04
morganfainbergnkinder, or as sounded as lay-ah as in P(rincess)Leia or way-uh?19:04
morganfainbergnkinder, /me thinks its coffee and go on vacation for a couple days time.19:04
morganfainbergnkinder, ;)19:05
morganfainbergnkinder, i only guess thats the pronounciation there because that's liz's website.19:06
*** browne has quit IRC19:08
*** browne has joined #openstack-keystone19:09
morganfainbergXML support removal in tempest is rapidly merging/19:09
morganfainbergyay19:09
morganfainbergno more XML [except in SAML]19:09
rodrigodsmorganfainberg, ++19:10
rodrigodsmorganfainberg, the buggy part in the SAML metadata retrieval was the XML bits heh19:10
openstackgerritSteve Martinelli proposed openstack/keystone: User ids that begin with 0 cannot authenticate through ldap  https://review.openstack.org/13744919:15
stevemarmorganfainberg, i found a nice bug :)19:15
stevemarcrinkle, dtroyer and i were really hoping to release a new version this week and last, but the gate is super broken for client builds19:16
stevemarwe haven't had a successful build in > 1 week now19:16
crinklestevemar: :'(19:17
bknudsonwe might have a fix for the keystoneclient / middleware issues19:25
openstackgerritAlexander Makarov proposed openstack/keystone: Trust redelegation  https://review.openstack.org/12689719:25
bknudsonit's an infra change: https://review.openstack.org/#/c/136512/19:26
*** NM has quit IRC19:29
*** edmondsw has joined #openstack-keystone19:30
samuelmsmorganfainberg, do you have a status of sql-id-binary-16 spec?19:46
*** NM has joined #openstack-keystone19:46
samuelmsmorganfainberg, I tried to ping dolphm but it looks like he's having a busy day19:46
samuelmsmorganfainberg, I'd like to grab that19:46
morganfainbergSql-id-binary-16?19:47
samuelmsmorganfainberg, https://blueprints.launchpad.net/keystone/+spec/sql-id-binary-1619:47
morganfainbergsamuelms: most us folks are going to be checked out today. Holiday tomorrow.19:47
morganfainbergThat bp might be dead, not all ids are uuids.19:48
*** NM has quit IRC19:48
morganfainbergSome are >32 bytes (sha256).19:48
samuelmsmorganfainberg, wow .. sure .. thanksgiving19:48
samuelmsmorganfainberg, those ids (sha256) are for what entities ?19:49
samuelmsmorganfainberg, I'd like to take a look on the code ..19:49
morganfainbergUsers and groups when using multi ldap backend.19:49
morganfainbergAnd in ldap userids arent uuid, that are db based.19:50
morganfainbergEtc.19:50
stevemarayoung, so apparently this code hasn't changed since 2012 when you wrote it, any chance you remember why you converted to int? https://github.com/openstack/keystone/commit/63437e9dca3b969c917fb138716aa4d3e5fabafa19:52
stevemarlooking specifically at the ldap2py function19:52
samuelmsmorganfainberg, yep .. makes sense .. thanks19:54
morganfainbergstevemar: some of that is just "it worked initially".19:55
morganfainbergstevemar: and without complaints bugs etc, it hasn't changed.19:55
stevemarmorganfainberg, yeah thats what i'm thinking19:55
stevemari've got a nice juicy corner case bug :)19:56
*** NM has joined #openstack-keystone19:56
*** dims has quit IRC19:56
morganfainbergFun.19:56
*** NM has quit IRC19:57
stevemarmorganfainberg, it's explained here: https://review.openstack.org/#/c/137449/ opening a LP bug now19:58
morganfainbergFun times.  Yeah def needs a bug.19:58
morganfainbergMake sure if you have confirmed it you prioritize and classify the bug. Don't leave it in new.19:59
*** NM has joined #openstack-keystone20:00
*** radez_g0n3 is now known as radez20:01
stevemarmorganfainberg, https://bugs.launchpad.net/keystone/+bug/139676320:21
uvirtbotLaunchpad bug 1396763 in keystone "user id beginning with 0 cannot authenticate through ldap" [Undecided,New]20:21
stevemarmed or high?20:22
stevemarbknudson, ayoung nkinder i'm open to suggestions on this one: https://bugs.launchpad.net/keystone/+bug/1396763 and y'all are the ldap gurus20:23
uvirtbotLaunchpad bug 1396763 in keystone "user id beginning with 0 cannot authenticate through ldap" [High,Confirmed]20:23
bknudsonstevemar: not really anything to do with ldap... the values have to be the right type.20:24
stevemarbknudson, well yes, i am wondering if we need the int() conversion still? whats the point of it if we mostly deal with strings anyway20:25
stevemareven if it's a timestamp, i think we would want a string20:25
bknudsonstevemar: have to go through the spec and see if there's values that are ints... mostly isn't good enough.20:25
ayoungstevemar, I think it is a python issue.  It is treating the value as a hex number?20:26
stevemarbknudson, but it's not just that, it's how we end up consuming that20:26
stevemarayoung, no, treating it as an integer, but by treating it as an integer it drops the leading zero20:27
ayoungyeah, that is wrong20:27
ayoungany reason to treat it as an integer?20:28
stevemarayoung, thats where it gets tricky, it attempts to convert any/all fields coming back from ldap20:28
*** nkinder has quit IRC20:28
ayoungyeah, I'm guessing due to posix userids20:28
*** _cjones_ has quit IRC20:28
*** ajayaa has quit IRC20:28
ayoungshudder20:29
stevemarbut it's converting these fields for our *own* use in the code / backends20:29
ayoungwhat happens if we just don't do that?20:29
bknudsonthe identity api spec says ids are strings so no reason to convert it to an int20:29
ayoungdoes Keystone still work20:29
stevemarthen i can authN fine20:29
ayoungyeah, drop the code that does that....then check what happens if you set a numeric field as the userid20:29
bknudsonI don't think users or groups have any ints.20:29
bknudsonit might cause a problem with enabled emulation20:30
bknudsonI mean the enabled mask or whatever it is20:30
stevemarayoung, i did comment out that code, that was the only way i could authN :)20:30
stevemarbknudson, yep, i pushed a patch that removes that logic, and the enabled stuff failed20:31
stevemarhttp://logs.openstack.org/49/137449/1/check/gate-keystone-python27/67dac9b/console.html20:31
bknudsonso maybe have a special case if the attribute is enabled then convert it... or change the enabled handling to convert it from a string.20:32
*** jdennis has joined #openstack-keystone20:34
*** _cjones_ has joined #openstack-keystone20:35
*** NM has quit IRC20:36
*** jdennis1 has quit IRC20:37
*** NM has joined #openstack-keystone20:37
*** henrynash has joined #openstack-keystone20:38
*** ChanServ sets mode: +v henrynash20:38
*** NM has quit IRC20:38
*** arunkant has quit IRC20:44
ayoungmorganfainberg, so I am going to drive on with the access info code and use it to update the way we are doing revocation events21:02
ayoungIn doing so, I'll make sure it works for policy as well21:02
ayoungI assume you are nowhere near getting ready to redo the token provider stuff.  I'm tempted to integrated it into that code as well21:02
*** edmondsw has quit IRC21:09
*** radez is now known as radez_g0n321:17
morganfainbergayoung: the access info stuff is part of that and can be done first.21:18
ayoungmorganfainberg, agreed.  Do you want me to take it on?21:18
morganfainbergGo for continuing with it. I'll show you the abstract stuff on Monday, you might include it then. If not should matter.21:18
ayoungdeal21:18
morganfainbergUp to you, I'm starting to see clear and have time to engineer things now that ptl suff is moving more smoothly.21:19
morganfainbergTaken a bit of time to get things on track.21:19
rodrigodsayoung, https://review.openstack.org/#/c/137476/ thiagop improved a bit the docstring :)21:22
ayoungmorganfainberg, I just suspect that the access info will be more fully featured if it is used in the token provider first.21:23
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: WIP - Improve list role assignments filters performance  https://review.openstack.org/13720221:27
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702121:28
*** NM has joined #openstack-keystone21:43
*** nkinder has joined #openstack-keystone21:45
nkinderjdennis: did you see stevemar's bug? https://bugs.launchpad.net/keystone/+bug/139676321:46
uvirtbotLaunchpad bug 1396763 in keystone "user id beginning with 0 cannot authenticate through ldap" [High,Confirmed]21:46
nkinderjdennis: I think that is code you are familiar with.  Do you know why we try to convert the value to an int before falling back to utf8?21:46
*** jdennis1 has joined #openstack-keystone21:46
*** jdennis has quit IRC21:47
nkinderjdennis1: In stevemar's case, he has a numeric identifier for the user in LDAP, which happens to be prefixed by a 021:48
stevemarwhich causes all sorts of calamity when we convert to int()21:48
nkinderstevemar: my concern is that something else might be depending on that conversion to int21:49
nkinderstevemar: did you run through the tests with the conversion removed?21:49
stevemarnkinder, yes, bknudson called it - enabled emulation stuff21:50
nkinderstevemar: I'd also check the use of userAccountControl with active directory since that's a numeric value that we do a bitmask check on21:50
openstackgerritWill Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists.  https://review.openstack.org/13694621:52
nkinderstevemar: yeah, it's the enabled mask stuff that's failing in your review21:53
stevemaryep21:53
nkinderstevemar: I would expect that enabled emulation to work since that's not actually getting a numeric value from LDAP (it's just using group membership)21:53
openstackgerritSteve Martinelli proposed openstack/keystone: User ids that begin with 0 cannot authenticate through ldap  https://review.openstack.org/13744921:53
stevemarnkinder, ^21:53
nkinderand a boolean LDAP attribute returns "True" and "False" strings21:54
stevemarnkinder, i can't imagine there are many that return t/f aside from enabled21:55
nkinderstevemar: no, and it's not even t/f which is a problem since LDAP represents those as actual strings21:55
nkinderThe enabled attribute is the only attribute that we care about treating as a number, and that's only when using the mask option.21:56
stevemarnkinder, ahhh, because it's a bit mask21:56
nkinderstevemar: so it can be special cased (which might be what your most recent patch does)...21:56
nkinderstevemar: yes, exactly21:56
stevemarnkinder, thats exactly what it does21:56
*** kobtea has joined #openstack-keystone21:57
stevemarwe have a surprisingly large amount of id's that start with 0 (ibm ldap), i'm kinda surprised it wasn't found earlier21:57
stevemarbut i guess that user would have to authN, or someone would be detailed enough to notice someone missing from a returned user/group listing21:59
ayoungmight there be other AD issues?  I wonder if this code is from CERN's AD effort?22:00
*** lhcheng has joined #openstack-keystone22:01
nkinderayoung: userAccountControl should be the only need for an int conversion22:01
ayoungNah...I wrote that, direct port from the Nova/Pre KSL code22:01
*** kobtea has quit IRC22:01
*** lhcheng_ has joined #openstack-keystone22:03
*** NM has quit IRC22:04
*** lhcheng has quit IRC22:05
*** lhcheng_ is now known as lhcheng22:06
ayoungnkinder, https://review.openstack.org/#/c/129951/  still is not showing up as either merged or in Zuul.  I went through a recheck when I set reverify, but then, Bupkis22:07
nkinderayoung: yeah, I looked at it this morning.  Not sure what's up with that...22:07
nkindermaybe time to bug infra...22:08
ayounggonna ask in infra22:08
nkinderayoung: thx22:08
openstackgerritWill Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists.  https://review.openstack.org/13694622:19
*** lhcheng has quit IRC22:34
*** lhcheng has joined #openstack-keystone22:35
*** tellesnobrega_ has joined #openstack-keystone22:40
*** EmilienM has quit IRC22:47
*** EmilienM has joined #openstack-keystone22:47
*** stevemar has quit IRC22:50
*** jamielennox|away is now known as jamielennox22:51
openstackgerritAndre Aranha proposed openstack/keystone: Modify the default policy  https://review.openstack.org/12350922:54
*** gordc has quit IRC22:55
jamielennoxbknudson: well found on that neutron postgres issue - i went through those logs and didn't see anything that linked to that bug22:59
zigomorganfainberg: I'm not doing OpenStack packaging "on my free time", this was the case 3 years ago, now I'm a full time employee of Mirantis, after I was a contractor of eNovance for 2 years. :)23:02
zigocrinkle: How may I help?23:02
jdennis1nkinder, stevemar: the fundamental problem is the code that returns values from LDAP needs to know the LDAP schema in order to know the syntax of the attribute23:03
nkinderjdennis1: yeah, but we at least know how we expect to treat the values for things like the id or name23:03
jdennis1without that information everything else is just a hack and will fail one way or another23:03
crinklezigo: hello, we were wondering about getting up-to-date python-openstackclient for Debian and UCA and thought you could point us in the right direction23:03
zigoWhat is UCA btw? Google suggests "University of Central Arkansas" though I'm sure you were not referencing that! :)23:04
jdennis1nkinder: are you suggesting a hard coded table of syntax?23:04
crinklepleia2 has directed me to #ubuntu-server and I'm waiting for some folks to wake up23:04
crinkleubuntu cloud archive23:04
zigoAh ok...23:05
nkinderjdennis1: not exactly.  I'm mainly stating that we know that we will take the 'id' attriute value and use it later in a search filter, so we know that it should never be transformed in the way that int() is doing it23:06
zigocrinkle: I can update it *now* if you wish.23:06
zigocrinkle: Though we have 0.4.0 in Debian, and Ubuntu has just 0.4.1.23:06
jdennis1nkinder: in IPA we retrieve the schema from the server and the code that does the ldap to python conversion utilizes that information to convert it to a python type23:07
zigocrinkle: There was no more new tags since...23:07
zigocrinkle: Do you need something even newer?23:07
crinklezigo: I wasn't able to find it in ubuntu, could you point it out to me?23:07
crinkleI think 0.4.1 is the newest23:07
nkinderjdennis1: yes, that's the right approach to take23:07
jdennis1nkinder: but the code that does the int conversion occurs before you receive the ldap attribute from the ldap code23:07
zigocrinkle: http://packages.ubuntu.com/search?keywords=python-openstackclient&searchon=names&suite=all&section=all23:07
crinkleoh, I was only looking at trusty23:08
crinkleI didn't even know there was a v23:08
zigocrinkle: The package in Ubuntu is based on the one in Debian, made by Gustavo Panizzo. He's the 2nd active openstack package contributor in Debian, though he hasn't done much over the last few months, since he moved in China.23:09
jdennis1nkinder: so the logic not to convert that attribute to an int has to occur there, right?23:09
jdennis1not at a higher level23:10
crinklezigo: we're going to be wanting this for trusty i think23:11
nkinderjdennis1: no, it was a value we got from LDAP which we then convert23:11
nkinderjdennis1: we just happen to then later reuse that converted value in an LDAP filter for another operation23:11
zigocrinkle: hang on for a few minutes and I will make the backport for it.23:13
*** browne has quit IRC23:13
crinklezigo: I don't really need it right this second, I was more trying to feel out who to talk to and what kind of timeline to expect23:13
crinkleit's great that you're so responsive :)23:14
zigocrinkle: it's just that I forgot to add it to my jenkins for trusty, otherwise it would be there already.23:14
crinkleaha :)23:14
jdennis1nkinder: well, I'm confused, I thought the issue was the LDAP syntax is string but we converted it to int after the ldap query23:16
nkinderjdennis1: It is, but we then use that converted value to perform a second search operation23:17
nkinderjdennis1: for example, you log in with "jdennis" as your username, and I lookup your id from LDAP23:17
nkinderjdennis1: ...let's say that id is "0123"23:17
jdennis1nkinder: right, so the problem is we should not have converted from string to int, or am I missing something?23:18
nkinderjdennis1: We convert that, and it's represented as "123" in the user object23:18
nkinderjdennis1: We then try to look up what groups your in with "(&(uid=123)(objectclass-user))", but that won't find you23:18
jdennis1nkinder: isn't the converted value the integer 123, not the string "123"23:18
*** tellesnobrega_ has quit IRC23:18
nkinderjdennis1: yes, but it ends up as a string when we create the LDAP filter23:19
jdennis1nkinder: doesn't the problem simply go away if the int conversion for that attribute does not occur and the original string is returned instead?23:19
nkinderjdennis1: so yes, the conversion is the problem.  We take the path of "looks like an int, smells like an int, ..."23:19
nkinderjdennis1: yep, that works fine that way23:20
nkinderjdennis1: did you see stevemar's patch?23:20
jdennis1nkinder: so we need a lookup table of some sort to drive the conversion23:20
jdennis1no, have not looked at the patch23:20
nkinderok, it's a special case hack (but it works) - https://review.openstack.org/#/c/13744923:20
nkinderjdennis1: it's still guessing at the possible syntax23:21
nkinderjdennis1: but we should only need an int for the enabled attribute, as AD uses a numeric userAccountControl value23:22
nkinderjdennis1: I wonder if AD actually uses the "Integer" syntax for UserAccountControl...  I'm not confident enough to bet either way23:24
jdennis1nkinder: why not a lookup table (i.e. a dict) that maps from an attribute name to a python class? i.e. return table[attr](value)23:25
nkinderthat would be a fine solution23:26
jdennis1the value is a type obect, i.e. a constructor, for instance str, unicode, int, bool, etc23:26
*** gokrokve has quit IRC23:27
nkinderjdennis1: it requires some LDAP know-how to look up the details and set things properly, but it would allow for a proper configuration23:27
jdennis1for the time being instead of using the schema we can have a small table of known attributes, this can later be replaced by a full table populated by the schema23:27
nkinderjdennis1: that's only a forward looking solution though (doesn't meet the stable backport requirements)23:27
jdennis1why not?23:28
nkinderjdennis1: not supposed to add new config23:28
jdennis1I'm not suggesting a new config, the table is hardcoded into ldap.py23:28
jdennis1er, rather ldap/core.py23:29
nkinderjdennis1: so is 'attr' in your proposal the LDAP attribute name or the keystone attribute?23:30
nkinderjdennis1: I'm guessing the keystone attribute since you're saying it's hardcoded23:30
jdennis1nkinder: actually for a while we ran that way in IPA, a small table of known "special" attributes, until it got unweildy23:30
nkinderjdennis1: we need flexibility though.  Take the 'enabled' attribute as an example...23:31
nkinderjdennis1: if it's AD, the enabled attribute is an int23:31
jdennis1no, I mean the ldap attribute name, which technically is the type, a very confusing word :-)23:31
nkinderjdennis1: if it's IPA, the enabled attribute is a boolean23:31
jdennis1that's a problem :-)23:32
jdennis1what other information disabiguates the two?23:32
jdennis1is it the object class?23:32
morganfainbergzigo: I though you did packaging on free time and other stuff else time.23:36
morganfainbergzigo: I apologize for being wrong. :)23:36
morganfainbergAhh23:36
zigomorganfainberg: No need to apologize, but think about it: I'm doing *all* of the Python module dependencies for *both* Debian and Ubuntu (they just "sync" form Debian, right?).23:37
zigomorganfainberg: How could I humanly just do this "on my free time" ?!? :)23:37
zigoThat's 200 packages that we're talking about ...23:37
zigohttp://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org23:37
morganfainbergzigo: fist point.23:38
zigo:)23:38
zigoOh gosh, we're really at more than 200 now !!! :(23:42
*** htruta_ has joined #openstack-keystone23:43
*** tellesnobrega_ has joined #openstack-keystone23:47
zigocrinkle: http://juno-trusty.pkgs.mirantis.com/debian/pool/trusty-juno-backports/main/p/python-openstackclient/23:53
zigoJust fresh out of my Jenkiins! :)23:53
zigoLet me know if you find some issue.23:53

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