Wednesday, 2014-02-26

*** stevemar has joined #openstack-keystone00:19
*** ChanServ sets mode: +v stevemar00:19
*** dolphm is now known as dolphm_50300:25
*** dolphm_503 is now known as dolphm00:47
*** amcrn has joined #openstack-keystone00:52
*** gokrokve_ has quit IRC01:10
*** nkinder has joined #openstack-keystone01:17
*** achampion has joined #openstack-keystone01:21
*** lnxnut has quit IRC01:33
*** gokrokve has joined #openstack-keystone01:39
*** devlaps1 has quit IRC01:42
*** browne has joined #openstack-keystone01:43
*** devlaps has joined #openstack-keystone01:43
*** stevemar has quit IRC01:48
*** amcrn has quit IRC01:49
*** gyee has quit IRC02:00
*** gyee has joined #openstack-keystone02:03
*** theocean154 has joined #openstack-keystone02:04
*** gyee has quit IRC02:04
*** gyee has joined #openstack-keystone02:05
*** marcoemorais has quit IRC02:11
*** ayoung has quit IRC02:12
*** arborism has joined #openstack-keystone02:12
*** marcoemorais has joined #openstack-keystone02:12
*** arborism is now known as amcrn02:12
*** theocean_ has joined #openstack-keystone02:20
*** marcoemorais has quit IRC02:21
*** theocean154 has quit IRC02:21
*** amcrn has quit IRC02:32
*** devlaps has quit IRC02:43
*** david-lyle has joined #openstack-keystone02:52
*** ayoung has joined #openstack-keystone02:56
ayoungmorganfainberg, just a gentle reminder that  could really use a review by you02:59
*** richm has quit IRC03:01
achampionif I have a user with role admin in domain X, should I be able to rescope a token to project Y in domain X if a the user has no explicit role in project Y but have enabled role inheritance03:14
*** lbragstad has joined #openstack-keystone03:17
*** morganfainberg is now known as morganfainberg_Z03:19
*** topol has joined #openstack-keystone03:35
*** theocean154 has joined #openstack-keystone03:47
*** theocean_ has quit IRC03:47
*** gyee has quit IRC03:52
*** harlowja is now known as harlowja_away03:57
*** stevemar has joined #openstack-keystone03:59
*** ChanServ sets mode: +v stevemar03:59
*** huats has quit IRC03:59
*** huats has joined #openstack-keystone04:11
ayoung  jamielennox, second nod on this would be appreciated04:25
jamielennoxayoung: i don't think you can give the first +2 yourself04:28
ayoungjamielennox, dstanek and I can both together, though04:28
*** KanagarajM_ has joined #openstack-keystone04:28
ayoungI wasn't going to approve it without either him or another core04:28
jamielennoxayoung: i would say that lets you do a +1 each04:29
*** topol has quit IRC04:29
ayoungdolphm, bknudson morganfainberg_Z, stevemar can one of you kick this one over the limit
dolphmayoung: done04:45
stevemarayoung, taking a quick ... nevermind04:46
ayoungdolphm, thanks.  You to stevemar04:46
ayoungdolphm, can we loosen the pep8 on the autogenerated config rule?  Its causing a lot of rebase issues?  Just until I3?  I'm sure we are millions of times better than we were before it went in04:51
*** ayoung is now known as ayoung_zZzZZzz_04:55
*** stevemar has quit IRC05:00
*** chandan_kumar has joined #openstack-keystone05:07
*** gokrokve has quit IRC05:31
*** gokrokve has joined #openstack-keystone05:31
*** browne has quit IRC05:35
*** gokrokve has quit IRC05:36
*** gokrokve has joined #openstack-keystone05:38
*** dolphm is now known as dolphm_50305:41
*** marcoemorais has joined #openstack-keystone05:58
*** marcoemorais1 has joined #openstack-keystone06:01
*** marcoemorais has quit IRC06:03
*** lbragstad is now known as lbragstad|away06:10
*** dolphm_503 is now known as dolphm06:11
*** gokrokve has quit IRC06:20
*** gokrokve has joined #openstack-keystone06:20
*** gokrokve has quit IRC06:21
*** theocean154 has quit IRC06:23
*** dolphm is now known as dolphm_50306:23
*** rwsu has quit IRC06:27
*** saju_m has joined #openstack-keystone06:50
*** dolphm_503 is now known as dolphm06:56
*** dolphm is now known as dolphm_50307:05
*** gokrokve has joined #openstack-keystone07:21
*** gokrokve has quit IRC07:26
*** bvandenh has joined #openstack-keystone07:44
*** marekd|email-me is now known as marekd07:52
*** dolphm_503 is now known as dolphm07:56
*** leseb has joined #openstack-keystone08:04
*** dolphm is now known as dolphm_50308:06
*** leseb has quit IRC08:07
*** leseb has joined #openstack-keystone08:07
*** gokrokve has joined #openstack-keystone08:22
*** gokrokve has quit IRC08:27
*** KanagarajM_ has quit IRC08:27
*** Kanagaraj has joined #openstack-keystone08:27
*** marcoemorais1 has quit IRC08:38
*** dolphm_503 is now known as dolphm08:57
*** marcoemorais has joined #openstack-keystone09:05
*** dolphm is now known as dolphm_50309:09
*** marcoemorais has quit IRC09:10
*** gokrokve has joined #openstack-keystone09:22
*** gokrokve has quit IRC09:27
*** Kanagaraj has quit IRC09:36
*** jamielennox has quit IRC09:36
*** jamielennox has joined #openstack-keystone09:39
*** ChanServ sets mode: +v jamielennox09:39
*** dolphm_503 is now known as dolphm10:00
*** marcoemorais has joined #openstack-keystone10:06
*** dolphm is now known as dolphm_50310:09
*** marcoemorais has quit IRC10:11
*** david-lyle has quit IRC10:19
*** florentflament has joined #openstack-keystone10:25
*** dolphm_503 is now known as dolphm11:00
*** jamielennox has quit IRC11:04
*** jamielennox has joined #openstack-keystone11:05
*** ChanServ sets mode: +v jamielennox11:05
*** marcoemorais has joined #openstack-keystone11:07
*** bvandenh has quit IRC11:08
*** dolphm is now known as dolphm_50311:10
*** marcoemorais has quit IRC11:11
*** gokrokve has joined #openstack-keystone11:22
*** leseb has quit IRC11:26
*** gokrokve has quit IRC11:27
*** leseb has joined #openstack-keystone11:37
*** leseb has quit IRC11:39
*** dolphm_503 is now known as dolphm12:01
*** marcoemorais has joined #openstack-keystone12:07
*** bvandenh has joined #openstack-keystone12:09
*** dolphm is now known as dolphm_50312:11
*** marcoemorais has quit IRC12:12
*** bvandenh has quit IRC12:19
*** gokrokve has joined #openstack-keystone12:22
*** gokrokve has quit IRC12:27
*** leseb has joined #openstack-keystone12:50
*** achampio1 has joined #openstack-keystone12:51
*** achampion has quit IRC12:53
*** leseb has quit IRC12:54
*** leseb has joined #openstack-keystone12:55
*** dolphm_503 is now known as dolphm12:57
*** bvandenh has joined #openstack-keystone12:57
*** achampion has joined #openstack-keystone13:02
*** achampio1 has quit IRC13:04
*** marcoemorais has joined #openstack-keystone13:08
*** bvandenh has quit IRC13:12
*** marcoemorais has quit IRC13:13
*** gokrokve has joined #openstack-keystone13:22
*** browne has joined #openstack-keystone13:25
*** gokrokve has quit IRC13:27
*** topol has joined #openstack-keystone13:34
*** dstanek has joined #openstack-keystone13:37
*** ChanServ sets mode: +v dstanek13:37
*** leseb has quit IRC13:50
*** leseb has joined #openstack-keystone13:51
*** amichon has joined #openstack-keystone13:52
*** leseb has quit IRC13:55
*** bknudson has quit IRC14:00
*** leseb has joined #openstack-keystone14:02
*** achampion has quit IRC14:05
*** marcoemorais has joined #openstack-keystone14:09
*** marcoemorais has quit IRC14:14
*** dolphm is now known as dolphm_50314:15
*** lbragstad|away has quit IRC14:18
*** bknudson has joined #openstack-keystone14:20
*** ayoung_zZzZZzz_ is now known as ayoung14:20
marekdbknudson: any opinion on line 289?14:21
bknudsonmarekd: assignment types only exist in the sql backend.14:22
*** gokrokve has joined #openstack-keystone14:22
bknudsonso this check should be done in the sql backend.14:22
bknudsonAssignmentType is defined at line 30 in backends.sql14:23
marekdbknudson: yep14:23
*** dolphm_503 is now known as dolphm14:25
dstanekayoung: what does the @ mean in policy.json?14:25
dstanekayoung: that's the first time i have seen that14:25
marekdbknudson: thanks for the comment14:26
ayoungdstanek, "always true"14:27
*** gokrokve has quit IRC14:27
dstanekayoung: looks like i need to read through that module later; thanks for the link14:28
ayoungdstanek, its not too complicated:  @  for always pass ! for always fail, the role checks, and the "and" and "or" rules14:29
amichonhi, I want to contribute to
dstanekayoung: i'm just wondering what other little things are hidden in there14:29
ayoungdstanek, I had to read through it when doing the trusts work.  That is where the "flatten" logic came from, in order to match deeper properties inside the token14:30
*** dolphm is now known as dolphm_50314:30
dstanekamichon: hi14:38
dstanekamichon: did you have anything in mind?14:41
dstanekayoung: so the revoke extension is enabled by default?14:45
ayoungdstanek, yes14:45
ayoungdstanek, It should be self balancing memory wise, and revocation events are fairly light weight.  Figured better to get it in and tested14:45
amichondstanek, yes I'd to be notified for create_grant for instance14:50
ayoungdstanek, speaking of policy   is that right?14:50
bknudsondo we need flush_tokens for revocation events?14:51
ayoungbknudson, for the time being, we need to clean up tokens.  Once we go ephemeral, not14:52
ayoungbknudson, the prune functions make sure the databases don't get overfull as well14:52
ayoungwith the events themselves14:52
bknudsonok, that happens for sql, too?14:52
bknudson(the prune function)14:53
*** achampion has joined #openstack-keystone14:56
*** lbragstad has joined #openstack-keystone15:00
achampionif I have a user with role admin in domain X, should I be able to rescope a token to project Y in domain X if a the user has no explicit role in project Y but have enabled role inheritance15:02
*** saju_m has quit IRC15:02
*** gokrokve has joined #openstack-keystone15:02
achampionI would have thought that the user should be able to get admin role on the project15:02
*** marcoemorais has joined #openstack-keystone15:10
dstanekayoung: i wouldn't think so15:10
*** leseb has quit IRC15:13
*** leseb_ has joined #openstack-keystone15:13
ayoungdstanek, would is_admin be a more reasonable role for listing users in groups?15:14
*** marcoemorais has quit IRC15:15
*** rwsu has joined #openstack-keystone15:18
*** leseb_ has quit IRC15:18
dstanekayoung: as a default i think that would be fine15:19
ayoungmarekd,  is pretty close.  I think the policy defaults are my one quibble.  Any reason why they should be []  ?15:22
bknudsonFor backwards compatibility, do we need to support setting the endpoint enabled attribute to a non-boolean?15:23
dstanekayoung: i'm not sure i get test_past_expiry_are_removed() - what is it actually testing for?15:23
marekdayoung: you mean this: etc/policy.v3cloudsample.json ?15:23
bknudsone.g., "enabled": "puppies"15:23
ayoungmarekd, and the other, yes15:24
lbragstadbknudson: there was no check if it was a boolean or not?15:24
bknudsonlbragstad: it wasn't defined in the model, so it got stuck in the "extras" attribute15:24
bknudsonthere's no checking anything not in the model.15:24
bknudsonextras are free-form.15:25
marekdayoung: admin_required is impossible here, as a normal user is going to call it, and he has only federated, unscoped token.15:25
marekdthis call is to list all project i can try scoping...15:25
lbragstadbknudson:  because it can be specific to the backend, right?15:25
marekdayoung: well..nothing is impossible :-)15:25
ayoungmarekd, we would want the check scoped appropriately15:25
ayounglet me think...think think think15:25
bknudsonlbragstad: well, that's specific to the sql backend... I guess there's a kvs backend for catalog too but I didn't look at what it does.15:26
marekdayoung: <hint> this is something proposed by dolph.15:26
marekdayoung: well, not proposed, but this is a feedback i got from him and he was fine with setting those policies to ""15:26
ayoungok,  not admin makes sense.  We would want the user to have a token.  When you list roles for groups, ideally you would want the userto be a member of the group, right?15:26
ayounghmmmm,  but list_roles_for groups in federation token granting should not be limited by a policy check.  THat should only be on the public facing API15:27
marekdayoung: the workflow is: issue an unscoped token with a list of groups, list accessible projects/domains (so /os-federation/projects)  only with this unscoped, federated token, choose project/domain and scope my token to this project/domain15:27
ayoungand for populating a token, it should be done internal....15:27 user is selecting groups that they can potentially be part of.15:28
marekdayoung: no15:28
marekdayoung: list of groups is a result of RuleProcessor15:28
ayoungmarekd, do we filter the list?15:28
marekdayoung: what list?15:28
ayoungbased on the user data>15:29
bknudsonI thought it was only going to return enabled groups15:29
ayoungonly let a user see rules for a group that they are a part of15:29
bknudsonoops, enabled projects and domains15:29
marekdbknudson: RuleProcessor? not at the moment, i added a test today (still not pushed) and e-mailed dolph and stevemar whether we should take care of that...15:29
marekdactualy, maybe its a good moment to raise it up here. RuleProcessor will issue any group_id, whetever stays in the rules.15:30
bknudsonI think it makes sense for RuleProcessor to do it.15:31
bknudsonbut then there should be someplace where we make sure the groups exist.15:31
bknudsonand are enabled.15:31
*** dolphm_503 is now known as dolphm15:31
marekdnow either we don't care and expect admins to raise bugs 'because it doesn't map correctly' just because they made a typo, and non existent group was mapped.15:31
marekdso we could either reject such queries or AT LEAST log warning.15:32
lbragstadbknudson: doesn't look like the catalog kvs backend does any really that different from the sql backend15:32
marekdbknudson: I would leave RuleProcessor as a blackbox that's the only task is to map rules....15:32
ayoungmarekd, OK...I think we are OK.  It can go on with [], but only because there is an implicit policy check.  You have to find out who the user is before you can list their groups.15:32
lbragstadbknudson: s/any/anthing/15:33
bknudsonlbragstad: what does it do with enabled?15:33
marekdayoung: specify "who the user is". It's ephemeral user, so tomorrow there will be no trace of his activity...15:33
marekdthe other scenario is: what should happend, when I create an unscoped token with groups {A,B,C} and in the meantime somebody deletes group B15:34
ayoungmarekd, yeah, but it was deduced from the SAML assertion, so you do know "who."  THe policy check should ideally specify "user must be authenticated"  which [] policy rule does not, but I think that is OK.   Controller actually enforces that for us.  You are good15:34
ayoungmarekd, if group B is deleted it should just be silently dropped from the results15:35
ayoungthe roles for the group, that is15:35
marekdpossible fix: validate the groups every time this unscoped token is used (for scoping usaally)15:35
ayoungmarekd, only if there is a 500 or something.  I think you are OK for now.   So long as a user can't get a role once the group is deleted (and they shouldn't)15:36
marekdayoung: actually, that'd be a good test...15:37
marekdi will add it.15:37
bknudsonthat would require referential integrity between the assignment and identity backend15:38
bknudsonif they have groups in ldap and are maintaining with ldap then keystone doesn't know if a group was deleted15:38
ayoung   for planning meetings with Australia15:38
lbragstadbknudson:  nothing specifically. It doesn't check the endpoint reference for anything with enabled:
bknudsonlbragstad: looks like kvs just takes whatever you give it for the endpoint, so enabled could be anything (as could any other field)15:40
lbragstadbknudson: right, just takes the reference and shoves it into the backend.15:40
marekdayoung: i just re-read your last msg to me. so you suggest we don't need to whether RuleProcessor issues valid group ids ? In other words if it issued group_id: "this_rules_doesn't exist" it will do nothing (like it does now)?15:42
lbragstadbknudson: afaict the one parameters that get checked when creating an endpoint are publicurl and service_id15:42
bknudsonlbragstad: where is publicurl checked?15:43
ayoungmarekd, yep..I think that is OK.   If I ask for roles for a group that doesn't exist, I could either expect a 404 or a 200 with no content.  Either are acceptable, depending on your point of view15:43
lbragstads/one/only ^^ can't type today15:44
bknudsonlbragstad: that's v2, what about v3?15:44
* lbragstad must need more coffee15:44
lbragstadoh yep, sorry you're right. service_id and interface15:44
*** lnxnut has joined #openstack-keystone15:44
bknudsonlbragstad: looks like we just require that the attribute exists? not that it's a string?15:45
lbragstadbknudson: right...15:45
lbragstadI am trying to help change that here too15:45
bknudsonso it would happily accept "interface": 315:45
marekdayoung: like i said if we silently pass mapping to non-valid groups we can expect users coming and saying that their rules were fine, but "it didn't work", just because they made a typo in the group_id and it was not even logged....15:45
lbragstadyou know.. that might be a good idea for the _BaseController15:45
lbragstadfor the required attribute (or all attribs) for that matter, make sure they are the proper type15:46
bknudsonwell, we already know that we need to do better input validation15:46
lbragstadbknudson: yeah, this would be a good step15:46
marekdayoung: hm, let me check if we have a full test for asking for roles from non-existing group...15:46
bknudsonwe don't want to wind up slowly and poorly reimplementing JSONSchema.15:46
lbragstadstill need to handle the XML case though don't we, for now?15:48
bknudsonlbragstad: what does XML have to do with it?15:49
bknudsonthe XML input just gets converted to JSON.15:49
lbragstadbknudson: ah yep15:49
*** stevemar has joined #openstack-keystone15:49
*** ChanServ sets mode: +v stevemar15:49
*** richm has joined #openstack-keystone15:50
*** kibad has joined #openstack-keystone15:50
kibadthis question is regarding keystone spec15:50
kibadin build requires we have mentioned "python2-devel"15:50
kibadis that a typo? or we actually have that particular package?15:50
kibadbecause I'm rebuilding keystone package for python 2.6 on centos 5.8 and I'm unable to find this particular package's source.. :(15:50
lbragstadbknudson: so, how would we want to go about this? continue with the validation impl in common.controllers._BaseController15:51
dolphmkibad: what are you looking at, exactly? that might be referencing python-dev in debian land, for example15:51
bknudsonlbragstad: I don't want to have a new validation library.15:51
ayoungmarekd, to be clear, I'm only concenred that we don't accidentally grant permission to something that we shouldn't.  Either failure to generate a token at all or granting  a token with only the legitimate roles are acceptable.15:51
bknudsonlet's go with an existing one instead15:51
dstanekayoung: why is everything guarded with 'CONF.token.revoke_by_id' now? does that break expectations of users that don't have that set?15:51
kibaddolphm: I'm trying to configure openstack on centos 5.815:51
bknudsonfind out what nova's doing. I think it's JSONSchema.15:51
marekdayoung: ++15:51
kibadsince centos runs on python 2.415:52
*** chandan_kumar has quit IRC15:52
dolphmkibad: there's a python-devel in centos 615:52
ayoungCONF.token.revoke_by_id is default to true dstanek and allows us to phase that out over time15:52
kibadI've installed python2.6 on it and building python26 openstack packages for centos 5.815:52
kibaddolphm: both python2-devel and python-devle are one and same?15:52
dolphmkibad: i'm assuming so, since python2 is the default, as you said15:53
kibaddolphm: this search shows existence of python2-devel :( confused..
*** bvandenh has joined #openstack-keystone15:54
*** ayoung is now known as ayoung-mtg15:55
dolphmkibad: sorry, i don't spend much time in rpm land -- ayoung would know better than i15:55
*** chandan_kumar has joined #openstack-keystone15:56
kibaddolphm: Thanks.. looks like ayoung-mtg is away :(15:57
*** david-lyle has joined #openstack-keystone15:57
dstanekkibad: so python-devel is 2.4 on centos?15:58
dolphmoh that's a blocker then15:58
dolphmi think it's 2.6 on centos 615:58
kibaddstanek: yes I can find python-devel for default python 2.4 on centos 5.815:59
dolphmkibad: openstack doesn't support < 2.615:59
*** thedodd has joined #openstack-keystone15:59
kibaddolphm: yes15:59
kibaddolphm: That's the reason I'm rebuilding python26 packages for centos 5.815:59
dolphmoh that doesn't sound fun at all16:00
dstanekkibad: the reason you need the devel package is likely for building all of the C-based dependencies16:01
dstanekkibad: if you install 2.6 from source I think you get the headers and the libs already16:01
kibaddstanek: I've installed 2.6 via epel16:02
kibaddstanek: and you are right16:02
*** david_lyle_ has joined #openstack-keystone16:02
kibaddstanek: devel lib is not required for keystone installtion16:02
lbragstadbknudson: Nova uses a validator
lbragstadwhich looks like it just wraps jsonschema16:04
bknudsonlbragstad: interesting.16:04
bknudsonlet's steal it16:04
dolphmcool ^16:05
*** david-lyle has quit IRC16:06
*** david-lyle has joined #openstack-keystone16:08
*** amichon has quit IRC16:10
*** ayoung-mtg is now known as ayoung16:11
lbragstadbknudson: doesn't look like it's used very much at the moment16:11
ayoungkibad, 2.6, not 2.416:12
*** david_lyle_ has quit IRC16:12
kibadayoung: yes I'm rebuilding packages for 2.616:12
kibadon  5.816:12
ayoungkibad, why are you doing this?16:12
ayoungIt sounds slighly insane from my perspective16:12
kibadayoung: requirements :(16:12
*** david_lyle_ has joined #openstack-keystone16:13
ayoungkibad, find the people that wrote those requirements and kneecap them16:13
kibadayoung: :D16:13
kibadayoung: left with no choice :)16:14
lbragstadbknudson: ah nevermind... users @validator.schema() wrapper16:15
ayoungkibad, seriously, it ia really bad idea16:15
ayoungnone of the virt stuff in nova etc is going to work right16:15
kibadayoung: if I get the relevant packages rebuild for 5.8 and python 2.6 do you think there will be issues?16:16
ayoungKeystone should be run on its own machine, and can be  a VM16:16
*** david-lyle has quit IRC16:16
ayoungkibad, too many to count16:16
kibadayoung: :(16:16
ayoungA horror of Lovecraftian Proportions16:16
ayoungkibad, seriosuly,  why?16:17
kibadayoung: its part of investigation16:18
ayoungI mean, Centos 6 is old enough to be a pain to support,  Centos 5 is really for maintain systems that work fine, shoiuld not be touched, and just need to be maintained. I would not do new development on 5, and certainly not something like Cloud.16:18
*** david-lyle has joined #openstack-keystone16:19
kibadayoung: I will try to suggest this :) probably I will be ignored..16:21
*** david_lyle_ has quit IRC16:21
ayoungkibad, if you want help, you need to provide sufficient rationalization for the effort.  I can't think that it would be worth anyone's while to pursue that, and I would actively dissuade you from attempting.   No one is going to suppport python2.6 on Centos 5 for OpenStack.  Run it on a Centos 6 VM and be done with it.16:22
*** david_lyle_ has joined #openstack-keystone16:23
ayoungtell them it is a security issue16:23
kibadayoung: ok, I will keep these points and try to convince them..16:25
kibadayoung & dolphm: thanks!16:27
*** david-lyle has quit IRC16:27
*** david_lyle_ is now known as david-lyle16:27
*** david_lyle_ has joined #openstack-keystone16:28
richmhow long does it typically take to run tox -e py27?16:28
ayoungfor ev er richm16:29
ayoungthe first time16:29
richmwhat about subsequent times?16:29
ayoungrichm, it is doing all sorts of downloads in the background16:29
ayoung300 seconds16:30
ayoungmore or less16:30
richmI can see the .tox/py27 directory being updated16:30
ayoungI had  find  .tox/py27  -print | wc -l  on watch while I was running it16:30
richm300 seconds???  I'm on 1200 seconds already16:30
ayoungit tops out at about 12000 files, then drops to 7000 and starts running tests16:30
dstanekstevemar: hi16:31
richmyeah, it's past the download/update stage16:31
richmwell past16:31
*** david-lyle has quit IRC16:31
dstanekayoung: i see what you mean. any reason we don't give the user an indication that the functionality is disabled?16:33
stevemardstanek, ahoy hoy16:33
dstanekstevemar: i just -1ed the limited trusts - what do you think of my comments here:
stevemardstanek, mostly nits, but better to get them out of the way now i suppose16:35
stevemaractually, the copyright one isn't a nit, i take that back. It's easy to fix though :)16:35
ayoungdstanek, what  kind of indication?16:35
stevemardstanek, were you okay otherwise?16:36
ayoungcopyright is not a nit?  I beg to differ....16:36
stevemarayoung, tell that to legal16:36
ayoungHeh...OK, m,aybe to you it isn't a nit16:36
*** david_lyle_ has quit IRC16:36
*** marekd is now known as marekd|away16:37
stevemardstanek, i might just push a new change if mhu doesn't, but i'll let a few others look it over16:38
dstanekayoung: i was thinking an error code from the api - you would want to think you operation happened, but it doesn't because the server is configured to ignore it16:38
ayoungdstanek, we talking about the revoke_by_id thing?16:38
mhustevemar, go ahead if you want, I am not available for making the changes for an hour or two16:39
dstanekstevemar: what do you think of the comment about deleting the ones set to 0 too? am i right to assume we need to do that?16:39
ayoungthe idea is that there are two mechanisms, and we are transitioning from one to another.16:39
dstanekayoung: yes, the revoke_by_id setting16:39 think it would be an error if both revoke_by_id was disabled and no revocation events?16:39
stevemardstanek, they would be useless, i brought this up early on16:40
dstanekstevemar: why would they be useless?16:40
ayoungor...if revoke_by_id is disabled, we should do a 503 if they do a call to get revoked tokens?  THat I could buy,16:40
stevemarbecause the use count is at 0, they can't update it, and they can't get another trust / token with it16:41
*** devlaps has joined #openstack-keystone16:41
dstanekayoung: the 503 idea - that lets people know their crap isn't working16:41
ayoungdstanek, ++  I'll add that16:41
dstanekstevemar: maybe i'm confused on what downgrading is for...i'm assuming it's rolling back the change to support some new functionality. is that not correct?16:42
*** henrynash has joined #openstack-keystone16:45
*** david-lyle has joined #openstack-keystone16:46
ayoung410  Gone dstanek?16:46
stevemardstanek, nvm, i was doing too many things, i didn't realize that when you mentioned delete trusts that has 0 use count, you meant when downgrading.16:48
stevemardstanek, i meant in general, i don't get the point of having a 0 use count trust hanging around16:48
dstanekstevemar: ah, i see - am i right on my assumption about downgrading?16:49
stevemari believe so16:49
mhudstanek, agreed on 0 use trusts, good catch16:49
dstanekayoung: i think a 410 could work16:50
*** kibad has quit IRC16:50
dstanekstevemar, mhu: you really just want to delete any records that are not null right?16:54
dstanekmhu: thx16:54
mhudstanek, yes16:54
dstanekstevemar, mhu: where do we document limited use trusts? do we call out that the number of uses is approximate and that it's possible more than the configured number of times?16:55
stevemardstanek, what do you mean by approximate?16:56
*** marcoemorais has joined #openstack-keystone16:58
dstanekstevemar: it looks like it is possible to have a race condition (for a very, very brief period of time) in between the check and the decrement16:58
stevemardstanek, only docs for remaining trusts:
dstanekstevemar: it's possible that it's so small it's not worth mentioning, but the little security guy on my shoulder keeps bringing it up16:59
mhudstanek, I updated the document on trusts in identity-api to mention the new remaining_uses parameter16:59
*** gokrokve has quit IRC17:02
mhudstanek, the sql backend should be protected from race conditions thanks to "with_lockmode('update')" when opening the session17:03
*** gokrokve has joined #openstack-keystone17:03
*** gyee has joined #openstack-keystone17:04
dstanekmhu: ah, yes. i didn't see that. You are absolutely right.17:05
*** saju_m has joined #openstack-keystone17:06
mhudstanek, it was a legitimate concern, and I'd feel better if it was possible to test the race conditions, but I don't really see how to do this, if possible at all17:06
*** gokrokve has quit IRC17:08
*** gabriel-bezerra has joined #openstack-keystone17:10
dstanekmhu: as far as the SQL backend is concerned i think you did that for any reasonable database17:11
dstanekmhu: nice work on this17:11
stevemardstanek, could you review the links here:,n,z17:22
dstanekstevemar: shore17:25
stevemardstanek, noice17:25
mhudstanek, about the copyright, should I drop the line entirely or replace it by something like "Copyright  (c) 2014 Matthieu Huin <>" ?17:30
dstanekmhu: that's up to you, i normally leave it our for my stuff - i have not bothered to find out the legal ramifications either way17:37
dstanekstevemar: can you have different protocols using the saml2 method?17:45
*** amcrn has joined #openstack-keystone17:46
dolphmmhu: your employer might not like you claiming copyright for yourself, but know that copyright lines in files have zero legal relevance anyway17:56
dolphmmhu: with the CLA and project-level LICENSE file etc, file-level copyright claims basically serve as nothing more than advertising for employers17:56
dtroyerand cruft that accumulates and needs cleaning out...18:01
dtroyerDolphm:  new topic: where does moving the middleware out of keystoneclient stand?  still on the table?18:01
bknudsondtroyer: what middleware?18:03
bknudsonoh, keystoneclient18:03
dolphmdtroyer: i haven't seen any discussion on it recently... to a middleware-specific repo, correct?18:03
dolphmbknudson: auth_token and the other one or two in there now18:03
dtroyerauth_token and s3_token18:03
dtroyermy concern is just the additional prereqs (however small) it adds to client-only installations18:04
dolphmnot sure why netaddr is in there, but there's not really any left today18:04
dolphmauth_token doesn't depend on webob needlessly anymore or anything18:05
bknudsonnetaddr is used by auth_token18:05
bknudsonand jsonutils18:05
dolphmlooks like netaddr is for ipv6 support in auth_token18:05
richmtox -e py27 running for 2 hours and counting . . .18:07
dolphmrichm: unless your internet connection is insanely slow or you're on really weak hardware, it shouldn't take that long18:08
dolphmrichm: i'd rerun and give it 10 or 15 minutes tops for a first run18:08
dolphmrichm: a normal run is < 5 min for me18:08
richmit is 2 hours past the point of downloading/installing python env in .tox/py2718:09
nkinderrichm: that's crazy.  I'll try a run of tox on my F18 box right now18:11
richmps shows the process is python -m discover -t ./ ./keystone/tests18:13
dolphmrichm: kill tox and run that directly18:13
dolphmrichm: you can use tox's venv (.tox/venv/bin/activate first)18:14
richmno venv or .venv under .tox18:15
richmoh, I see - py2718:16
*** gokrokve has joined #openstack-keystone18:19
*** devlaps has quit IRC18:24
*** devlaps has joined #openstack-keystone18:24
*** devlaps has quit IRC18:24
*** devlaps has joined #openstack-keystone18:25
*** gabriel-bezerra has quit IRC18:29
lbragstadbknudson: looks like some of the nova plugins use this for setting the schema for validation18:32
richm16 minutes and counting . . .18:33
bknudsonlbragstad: looks like a good format18:33
*** harlowja_away is now known as harlowja18:34
ayoungdstanek,  for k, v in locals().copy().iteritems():   becomes what with six?18:34
lbragstadI agree, each plugin could have a schema subdir that holds it18:34
bknudsonrichm: have you tried setting up tmpfs for keystone/tests/tmp?
richmno, will try that18:34
ayoungrichm, BTW...there is a hack to speed up database access:18:34
dolphmayoung: six.iteritems(locals().copy()) ?18:34
dolphmthat looks like nasty code though18:35
*** saju_m has quit IRC18:35
ayoung dolphm its just copying the parameter list before any local variables get defined.  Its in an init function18:35
ayoungdolphm, basically, it does18:36
ayoung        for k, v in locals().copy().iteritems():18:36
ayoung            setattr(self, k, v)18:36
*** morganfainberg_Z is now known as morganfainberg18:36
ayoungso creates a member for each paramer list item18:36
ayoungseemed silly to have to create each one explicitly.  Is there a problem with my approach?18:37
dolphmayoung: why are you starting with locals() instead of something explicit? and why are you making a copy?18:37
ayoungrichm, I mount a ramdisk over keystone/tests/tmp and checkout HEAD18:37
richmok - will try that18:37
ayoungsudo mount -t tmpfs -o size=256M tmpfs /opt/stack/keystone/keystone/tests/tmp18:38
ayoungcd /opt/stack/keystone18:38
ayounggit checkout HEAD keystone/tests/tmp18:38
ayoungrichm, ext3 and later are really slow when used with sqlite.18:38
richmthen that may explain it - my keystone dir is nfs mounted18:38
ayoungdolphm, I copy because...I think something gets created in the locals collection as a side effect.  It didn't work without the copy.  Been a while since I got that working, I forget the exact error18:38
ayoungYes.  richm that is, how do you say, suboptimal?18:39
richmthat's one way to put it18:39
dolphmayoung: if that's in an __init__ or something, then the magic will be very confusing for those new to python18:39
dolphmyou're just going to cause headaches ;(18:39
ayoungdolphm, I was going for DRY here....18:39
ayoungI'd rather leave it as is an comment18:40
ayoungsix might reduce the need for the copy, though.  going to test18:40
nkinderrichm: I'm 30 minutes in, and it's sitting at "running=${PYTHON:-python} -m discover"18:41
nkinderI'm using a local disk with ext418:42
ayoungRuntimeError: dictionary changed size during iteration18:43
ayoungnkinder, do the mount trick18:43
*** chandan_kumar has quit IRC18:46
nkinderayoung: for some strange reason, that comment caused me to get "do the hustle" stuck in my head... thanks a lot. ;)18:46
ayoungNice, Nice, day for it18:46
ayoungdstanek,  to what magic do you refer?18:47
richmayoung: could I just mkdir /dev/shm/tmp ; ln -s /dev/shm/tmp `pwd`/keystone/tests/tmp18:53
dstanekayoung: just the whole read from __dict__; i wouldn't block anything because of it, i'm just not a fan18:54
dstanekayoung: for your earlier question: six.iteritems(locals().copy())18:55
richmyes, looks like that is working18:55
dstanekdolphm: yeah, the locals needs a copy when there are local environment changes18:55
dolphmdstanek: that wasn't mutating any locals though (?)18:56
morganfainberghenrynash, ayoung, should talk about the uid->domain mapping table idea (re: email about user_id length change) today if possible. cc dolphm18:56
dolphmdstanek: is this something where if i ran it i would facepalm? lol18:56
morganfainbergunless it was already talked about. and i didn't see it in the backlog18:56
dolphmmorganfainberg: o/ i haven't18:56
dolphmmorganfainberg: other than sort of responding on list18:56
morganfainbergdolphm, yah, my email didn't get the send button clicked18:57
morganfainberglast night18:57
morganfainbergyou covered most of it though18:57
morganfainbergayoung, KVS stuff, you're only doing in-memory in this patchset?18:58
henrynashmorganfainberg: so let's think who that would work18:59
dolphmhenrynash: (i'd also like to focus on solving for the multi-ldap backend per domain problem first)19:00
dolphmmorganfainberg: henrynash: so, all that i *think* is needed there is a function that reverses a user_id to the owning domain_id, correct?19:00
dolphmeffectively get_domain_id(user_id)19:00
dolphmregardless of whether we're parsing apart the user_id or referencing a lookup table, that's the required interface19:01
morganfainbergif we did a map-table, we should be issuing something "unique" like a UUID for the ldap users as well, and map the DN related info separate from the user_id (of course, only new users not existing)19:01
henrynashdolphm: yes, and we would build the underlying mapping dynamically upon response to any user/group get,list,create call19:01
dolphmso to me, this sounds like a new internal-only manager/driver with exactly two calls (a get and an optional set), that could be backed to SQL19:02
henrynashdolphm: yes19:02
dolphmor to dogpile (i imagine an LRU backend to be useful here)19:03
morganfainbergdolphm, sounds correct ot me19:03
dstanekdolphm: probably :-) i stay away from it when i can because most people have no idea why...they assume it's more than saving lines or code and get hung up on it19:03
henrynashdolphm: it would replace the current current bit where I extract the domain_id from the user_id19:03
morganfainbergdolphm, would we internally encode the IDP for LDAP users into the user_id?19:03
henrynashone issue…so this could be a BIG table19:03
morganfainbergdolphm, because the major issue we saw before was that DN on LDAP1 could... be DN on LDAP219:04
dolphmmorganfainberg: that's crossing problem domains -- you mean the DN for LDAP users or something?19:04
dolphmor domain_id?19:04
morganfainbergdolphm, we use the DN to create the id19:04
morganfainbergdolphm, so we would need something that is guaranteed unique for those users19:04
morganfainbergDNs suffer from the same problem as federated users... keystone can't trust that they will be unique (or the derived user_id will be unique)19:05
morganfainbergthat was the reason to move to the user_id@@domain model19:05
henrynashmorganfainberg: I think we would generate a new UUID for any LDAP user we had not seen before, tagging it with the domain and the actual ID the LDAP backend returned19:05
dolphmwhat i really want to do is something like indexing into a bunch of identity backends by domain, and performing operations there, like: self.identity_backends[get_domain_id(user_id)].get_user(user_id)19:05
morganfainberghenrynash, that was my thought, that also means we can't LRU (ever) this map table19:05
morganfainbergas much as i like dogpile, anything that could lose state would be horrific and break keystone19:06
morganfainbergdolphm, ++ yes.19:06
henrynashdolphm: and that's essentially what the current code does…you just have to wrap it in a bunch of pre and post processing19:07
morganfainberghenrynash, right, but we're relying on encoded information in the user_id, we just need to pull that out so user_id stays "the same" as it always has19:07
*** luisbg has joined #openstack-keystone19:08
henrynashmorganfainbrg: sure….19:08
morganfainberghenrynash, dolphm, I don't like it, but i think SQL is ... perhaps our only clear option here - fully stateful table.19:08
morganfainbergactually.. i wonder19:08
henrynashmorganfainberg: one issue is…how would LDAP entries ever get deleted?19:09
morganfainberghenrynash, UUID519:09
morganfainbergGenerate a UUID from the SHA-1 hash of a namespace UUID and a name.19:09
morganfainberghenrynash, oh uhm. same issue we have w/ grants tbh19:10
dolphmhenrynash: i'd like to keep the table updated with date created and last accessed and then worry about it later19:10
dolphmbut that's just wishlist19:10
morganfainbergwhen we solve grants, we can solve this table19:10
morganfainbergdolphm, but we can use uuid5 i think to cover DN-derived-id+domain_id19:10
henrynashmorganfainberg: since most LDAPs will be RO…we'll never see deletes….could imagine some creative ways of culling stale data19:11
luisbgdoes anybody have an idea why this change ( triggers an issue with cinder in the build tests? but doesn't happen if the two line change in oslo.config isn't called from the tests?19:11
morganfainberghenrynash, like i said, if we solve the issue for grants we solve for map-table.19:11
morganfainbergbut if we can't solve that... we can't solve either19:11
ayoungmorganfainberg, to run to an appointmnet19:12
morganfainberghenrynash, we could probably just do a correlate to the grant table, and if the id isn't in the grant table we can clean it up19:12
morganfainbergayoung, k. just checking before i comment on that19:12
morganfainberghenrynash, s/grant table/grant assignment stuff/19:13
henrynashmorganfainberg: probably being dumb here, but what's the specific isuee with the assignment table?19:13
morganfainberghenrynash, if an ldap user disappears... the grant entries linger around19:14
henrynashmorganfainberg: oh, right..sure19:14
morganfainberghenrynash, same exact issue as the map table stuff19:14
morganfainberghenrynash, dolphm, so if we used something like uuid5 for LDAP users, we can generate a sha1 (unique enough?) user_id based on the two elements.19:16
morganfainberghenrynash, dolphm, same for Federated users.19:16
*** andreaf has joined #openstack-keystone19:16
*** ved_ has joined #openstack-keystone19:16
morganfainberginfo can go into the new user_id map table19:16
henrynashmorganfainberg: obviously we could have some garbage-collection style polling going on…or piggyback real commands coming in (e.g. if we saws  list_users() command go by, we could cull things that we have in the tables but were not returned)19:17
morganfainberghenrynash, ++19:17
morganfainbergthe only other question i have is do we need to store any extra metadata (e.g. DN?) in this map table19:17
*** ayoung has quit IRC19:17
morganfainberginitial impl should be SQL, we can figure out if we want dogpile along the way19:17
morganfainbergi know the user id hashing is one way, but if we have a lookup, it doesn't matter19:18
henrynashmorganfainberg: I don;'t *think* we would have to store anything else…LDAP backend already has an "id_to/from_DN"19:18
morganfainberghenrynash, if we used uuid5 we cant take the uuid5 and get the DN info back19:19
morganfainberghenrynash, or any uuid for that matter (i like 5 because it's a combination of 2 elements)19:19
henrynashmorganfainberg: hmmm19:19
morganfainbergbrb caffination calls19:21
morganfainbergok back19:23
henrynashmorganfainberg: not sure, whether, uuid5 really helps19:26
richmok - with tests/tmp in /dev/shm tests completed in 30 minutes19:27
henrynashmorganfainberg: I think it may be a simple SQL: UUID -> Domain + localID19:27
morganfainberghenrynash, well the advantage to uuid5 is that it's not random data.  so if you "cleaned up" the table, you'd get the same uuid for the same LDAP DN-Derived-ID19:27
morganfainberghenrynash, if we use uuid4() you get something random that isn't replicatable19:27
henrynashmorganfainberg: agh, so you're tying to ensure we can delete entries, re-create them later and end up with the same (externally facing) UUID....19:28
morganfainberghenrynash, SQL users would still be uuid4, but since we're seeding with external data, uuid5 might buy us repeatable data19:28
morganfainberghenrynash, thinking worst-case scenarios19:28
morganfainberghenrynash, you can tell me i'm being overly defensive here19:29
morganfainberghenrynash, thats ok19:29
henrynashmorganfainberg: no, it's an intersteding idea19:29
morganfainbergactually.. it wouldn't work like that :P19:30
morganfainbergbecause you still can't reverse the uuid -> LDAP DN19:30
morganfainbergit just means you can side-band repopulate things if you needed19:30
henrynashmorganfainberg: so there's no way we can cull the table periodically (since we never know when we will be presented with some UUID we gave out 6 months ago)19:30
morganfainberghenrynash, yeah.19:30
morganfainberghenrynash, =/ grr.19:31
henrynashmorganfainberg: Ok, I gotta go to a meeting..back on in a couple of hours - will mull on this!19:31
morganfainberghenrynash, sounds good19:32
*** ved_ has quit IRC19:33
*** henrynash has quit IRC19:33
*** dstanek_afk has joined #openstack-keystone19:38
*** ChanServ sets mode: +v dstanek_afk19:38
luisbgdolphm, ping19:41
luisbgdolphm, can I get some help understanding the build problems with this patch I have very close to review?19:42
*** huats_ has joined #openstack-keystone19:42
*** huats_ has quit IRC19:42
*** huats_ has joined #openstack-keystone19:42
*** bvandenh_ has joined #openstack-keystone19:43
dstanek_afkluisbg: what is the patch?19:43
luisbgI can explain you the issue if you are !afk :)19:44
*** dstanek has quit IRC19:44
*** dstanek_afk is now known as dstanek19:44
luisbgahhh, there19:44
luisbgdstanek, <-- when I don't change the test, it builds fine in Jenkins19:45
luisbgbut the error I get with the test change, is not test related, it is Cinder not starting19:45
*** gyee has quit IRC19:47
*** bvandenh has quit IRC19:47
*** huats has quit IRC19:47
*** nkinder has quit IRC19:47
dstanekluisbg: the build failures are not from your code changes - at least not that i can tell19:48
dstanekthis actually looks like an error i saw on one of my changesets19:48
luisbgdstanek, but why does it only happen when I change the test case? notice the build passed when I removed that to experiment19:50
luisbgdstanek, have you found the issue in Rechecks?19:50
*** marcoemorais has quit IRC19:52
*** gyee has joined #openstack-keystone19:53
*** andreaf has quit IRC19:53
*** nkinder has joined #openstack-keystone19:54
morganfainbergdolphm, are we dropping kite on the floor? if so i'm ready to abandon the gerrit/etc change19:56
stevemardstanek, thanks for the reviews :)19:56
dolphmmorganfainberg: i was only going to create a feature branch from the current state of the repo, and then propose a git rm from master19:56
dolphmmorganfainberg: then worry about it after icehouse releases19:57
morganfainbergdolphm, i'll drop the add the repos stuff19:57
*** jraim has quit IRC19:57
morganfainbergcan always restore later19:57
*** marcoemorais has joined #openstack-keystone19:58
*** browne is now known as 20WABD4PL19:58
*** browne has joined #openstack-keystone19:58
*** jraim has joined #openstack-keystone19:58
*** jraim has quit IRC19:59
*** browne has quit IRC19:59
*** marcoemorais has quit IRC19:59
*** marcoemorais has joined #openstack-keystone20:01
*** nkinder has quit IRC20:01
*** achampion has quit IRC20:01
*** nkinder has joined #openstack-keystone20:01
*** 20WABD4PL has quit IRC20:01
lbragstadstevemar: responded to your question on my documentation patch20:02
*** amcrn has quit IRC20:03
*** achampion has joined #openstack-keystone20:03
dstanekstevemar: yw20:03
dstanekluisbg: i found it for my review (assuming it's the same issue)20:03
dstanekluisbg: it's interesting that it would only fail if you changed the tests20:03
*** jraim has joined #openstack-keystone20:05
*** browne has joined #openstack-keystone20:05
*** jraim has quit IRC20:05
*** jraim has joined #openstack-keystone20:05
*** huats_ is now known as huats20:06
dstanekluisbg: i think lbragstad rechecked on the bug that i was thinking of20:07
stevemarlbragstad, responded to your response20:07
*** henrynash has joined #openstack-keystone20:09
*** browne has left #openstack-keystone20:10
*** henrynash has quit IRC20:11
*** nkinder_ has joined #openstack-keystone20:11
*** doddstack has joined #openstack-keystone20:11
dstanekluisbg: actually i think that is what i was thinking of20:12
*** browne has joined #openstack-keystone20:13
stevemarlbragstad, i have no idea why the bug i copied went to a ubuntu launchpad page20:15
lbragstadit truncates the latest character of the bug number20:16
lbragstadhappens to me too20:16
lbragstadfor some reason we can't use full links, it has to be 'bug ######' or something20:16
luisbgdstanek, sorry, a bit new with the process, so what should I do? do a recheck in my review pointing to that bug?20:18
*** nkinder has quit IRC20:18
*** thedodd has quit IRC20:18
stevemardstanek, regarding you latest comment, yes, you would use an unscoped token to access the list projects/domains resources20:22
dstanekluisbg: i think so - seems like the errors are unrelated to your changes20:22
luisbgdstanek, doing so, thanks20:22
dstanekstevemar: :-) do we call that our anywhere? i assumed so, but wanted to make sure20:23
stevemardstanek, hmmm technically: "The user can then select a project and request a scoped token."20:24
stevemardepends on how good the reader is :)20:24
dstanekstevemar: do you always need an unscoped token to request a scoped token?20:26
stevemardstanek, in the case of federation, yes :)20:26
stevemardstanek, but i'll try and add something20:27
dstanekstevemar: it may say that in another part of the doc. i only read the diffs20:27
stevemardstanek, before the second sentence "To access the resource, an unscoped token is used, the user can then ... "20:28
luisbgdstanek, when Jenkins rechecks, how does it now to ignore the issues of this bug and not others? or furthermore how does it know what are the issues this bug brings?20:28
stevemarluisbg, it doesn't ignore anything!20:28
luisbgstevemar, so what does it do? I'm confused20:29
stevemarluisbg, i'm glad i was not the only person to think that..20:29
luisbgstevemar, hahaha you thought the same the first time?20:29
stevemarluisbg, it just adds another checkmark to the recheck list:
stevemarthey won't occur every run20:29
luisbgstevemar, so my patch will only be retested when the other bug is fixed?20:29
stevemarluisbg, as dolphm told me, the point of recheck is: "identifying and prioritizing transient issues to be fixed20:31
stevemartransient being one of the key words20:32
*** jamielennox is now known as jamielennox|away20:34
luisbgstevemar, ahhh OK20:34
dstanekluisbg, stevemar: yeah, it'll put then into the queue shortly after you leave the comment20:35
*** marcoemorais has quit IRC20:36
dstanekstevemar, mhu: are one of you guys working on the limited trusts review?20:37
stevemardstanek, i think mhu is likely done for the day20:39
*** marcoemorais has joined #openstack-keystone20:41
dstanekstevemar: i may fix up some of the nits that i found to help us along20:42
stevemardstanek, i'll do it quickly no worries20:42
dstanekstevemar: sounds good to me :-)20:43
stevemardstanek, line 89, just return, or delete the conditional entirely?20:44
stevemardstanek, definitely can't just delete it20:46
dstanekstevemar: yeah, you'd have to do a return - assuming i am right about the flush20:46
stevemardstanek, could pass?20:47
stevemaror break20:48
stevemarpass it si20:50
*** henrynash has joined #openstack-keystone20:53
stevemardstanek, done sir20:54
dstanekstevemar: checking. sorry, was afk20:56
stevemardstanek, np dude20:57
dstanekstevemar: the only thing i see is the downgrade again. mhu and I were discussin needing to delete all non-nulls21:02
dstanekstevemar: that would get rid of anything what would be overly decremented (only possible with KVS I think)21:03
stevemarah i see what you mean21:03
*** david_lyle_ has joined #openstack-keystone21:23
*** gokrokve_ has joined #openstack-keystone21:24
*** ayoung_ has joined #openstack-keystone21:25
*** henrynash_ has joined #openstack-keystone21:25
*** stevemar has quit IRC21:28
*** arborism has joined #openstack-keystone21:31
*** gokrokve has quit IRC21:34
*** henrynash has quit IRC21:34
*** henrynash_ is now known as henrynash21:34
*** david-lyle has quit IRC21:35
*** devlaps1 has joined #openstack-keystone21:52
*** devlaps has quit IRC21:53
henrynashdolphm: so is it your view that we should avoid increasing the size of the ID fields and that some kind of mapping is preferable?21:54
*** theocean154 has joined #openstack-keystone21:54
*** leseb has joined #openstack-keystone21:54
ayoung_dstanek, morganfainberg gyee would it make sense for me to squash  and  into the revoke extensions review?21:56
ayoung_the whole thing really is one system, and I would feel better if all of the code got commited. The revoke_by_tree stuff especially is important, as it provides a much more sane way to do revocation checking21:56
henrynashayoung_: did you see the discussion earlier on possibly using a mapping table (UUID -> domain_id + local_id) instead of encoding the domain in the ID?21:59
ayoung_henrynash, yuck21:59
ayoung_henrynash, lots of problems with that22:01
henrynashayoung_: it was just a discussion…based on push back on field size increase (not 'cause it breaks too much, but rather…"surely a UUID is enough bits to allow you to map to whatever you want")22:01
gyeeayoung_, looking22:01
henrynashayoung_: oh, yes22:01
*** ayoung_ is now known as ayoung22:01
henrynashayoung_: like mapping table size, how to you know when to delete an entry (since if the LDAP is RO we will never see the delete) etc.22:02
*** marcoemorais has quit IRC22:02
ayounghenrynash, bascially we would have a clone of every user in the SQL backend22:02
henrynashayoung: well, a mapping of UUID to domainID+local_id22:03
ayoungand all of the data consistancy issues that come with it.  Also, on the LDAP side, we have the problem of users coming in on dmand and getting a UUID....22:03
ayoungits just....22:03
henrynashayoung: I think it's do-able, but I worry about the just table size of large installations and the garbage collection we'd have to do22:04
*** marcoemorais has joined #openstack-keystone22:04
henrynashayoung: as i said, it was just raised for discussion22:05
ayounghenrynash, I would sooner make the rule len( domainid) len(ldapuserid) < 6322:05
theocean154ayoung: will update you on tfa stuff after our open academy meeting tonight 9pm eastern time22:05
henrynashayoung: funny, I was thinking along those lines!22:05
*** theocean154 has quit IRC22:05
*** theocean154 has joined #openstack-keystone22:06
*** henrynash has quit IRC22:07
ayounghenrynash, is there such a thing as a len 32 char uuid?22:07
morganfainbergtopol, ping22:14
topolmorganfainberg, Hi22:14
*** achampion has quit IRC22:36
*** lbragstad has quit IRC22:44
*** marcoemorais has quit IRC22:47
simoayoung: and what do you wehn domain_id + user_id >= 64 ?22:53
simoayoung: a uuid IIRc is a 128bit number == 32 bytes22:53
*** lnxnut has quit IRC22:55
*** leseb has quit IRC23:04
*** harlowja is now known as harlowja_away23:05
*** bknudson has quit IRC23:05
ayoungsimo, yeah, I know...the length thing is ugly.23:07
morganfainbergsimo, yep 32bytes23:07
morganfainbergayoung, and there is a valid point we shouldn't increase the maximum field side.  that has merit23:07
ayoungits longer than 32 chars cuz uuencode or whatever it uses23:07
morganfainbergayoung, it's 36 bytes atm23:08
morganfainbergayoung, iirc23:08
ayoungso close...23:08
morganfainbergif you do an explicit .hex it's 32 bytes23:08
morganfainbergwe do .hex23:08
morganfainbergwhich using .hex removes the '-' which limits expansion due to other encodings (uuencode etc)23:09
*** jamielennox|away is now known as jamielennox23:10
morganfainbergayoung, so far we have 1 place that expects the size of the user_id to be <= 36 (nova)23:10
morganfainbergand that should be fixed in the nova schema (i'll propose that fix this weekend) to match our schema of 6423:11
jamielennoxayoung, gyee: auth plugins merged!23:12
*** doddstack has quit IRC23:12
ayoungso if we go 64...we are still 2 chars short if uuid@@uuid23:13
*** browne has quit IRC23:22
gyeejamielennox, yes, we need them23:24
gyeewe need the OS clients to start integrating with it23:24
jamielennoxgyee: yea - and i thought v2 had definitely been scrutinized enough, and then i see v3 passed as well!23:24
*** dstanek is now known as dstanek_afk23:25
gyeejamielennox, that code's pretty solid I think23:25
jamielennoxgyee: i generally thing most of my reviews are pretty solid - then we go through 15 odd reviews :) - i'm good with it though23:26
*** marcoemorais has joined #openstack-keystone23:50
jamielennoxgyee: and anyone else interested - where do you think is the right place to handle region_name23:52
jamielennoxso far i've not had it on the session object, because i don't think you want to always connect to the same region with a session23:52
gyeejamielennox, for what, catalog search?23:52
jamielennoxgyee: yea, determining an endpoint URL23:52
*** dolphm is now known as dolphm_50323:52
jamielennoxso i've had it as a parameter to the client23:52
gyeejamielennox, go with LDAP search filter style23:52
jamielennoxlol, hell no this is python23:53
jamielennoxi'm fine with passing region_name=XXX, endpoint_type='public' as kwargs23:53
jamielennoxthat's not a problem23:54
gyeeI was half kidding, but we need a way to pinpoint the endpoint we need23:54
gyeeand that's filtering my friend23:54
*** marcoemorais has quit IRC23:54
jamielennoxgyee: sure but whilst the only things you can filter on are limited we don't need to worry about that too far23:54
gyeejamielennox, what is an endpoint?23:54
gyeeurl + metadata23:54
*** henrynash has joined #openstack-keystone23:55
gyeeand what's the best way to do lookup? filtering23:55
jamielennoxgyee: so i'm cleaning up this one before resubmitting
jamielennoxyou can see endpoint lookup here:23:56
jamielennox<jamielennox> gyee: sure but whilst the only things you can filter on are limited we don't need to worry about that too far23:56
*** marcoemorais has joined #openstack-keystone23:56
gyeeendpoint_type and region_name is not going to be good enough23:58
gyeefor now maybe yes, but you want to make it more flexible23:58
gyeeservice catalog is essentially a tree23:59
gyeeyou want to have a generic lookup mechanism23:59

Generated by 2.14.0 by Marius Gedminas - find it at!