| *** stevemar has joined #openstack-keystone | 00:19 | |
| *** ChanServ sets mode: +v stevemar | 00:19 | |
| *** dolphm is now known as dolphm_503 | 00:25 | |
| *** dolphm_503 is now known as dolphm | 00:47 | |
| *** amcrn has joined #openstack-keystone | 00:52 | |
| *** gokrokve_ has quit IRC | 01:10 | |
| *** nkinder has joined #openstack-keystone | 01:17 | |
| *** achampion has joined #openstack-keystone | 01:21 | |
| *** lnxnut has quit IRC | 01:33 | |
| *** gokrokve has joined #openstack-keystone | 01:39 | |
| *** devlaps1 has quit IRC | 01:42 | |
| *** browne has joined #openstack-keystone | 01:43 | |
| *** devlaps has joined #openstack-keystone | 01:43 | |
| *** stevemar has quit IRC | 01:48 | |
| *** amcrn has quit IRC | 01:49 | |
| *** gyee has quit IRC | 02:00 | |
| *** gyee has joined #openstack-keystone | 02:03 | |
| *** theocean154 has joined #openstack-keystone | 02:04 | |
| *** gyee has quit IRC | 02:04 | |
| *** gyee has joined #openstack-keystone | 02:05 | |
| *** marcoemorais has quit IRC | 02:11 | |
| *** ayoung has quit IRC | 02:12 | |
| *** arborism has joined #openstack-keystone | 02:12 | |
| *** marcoemorais has joined #openstack-keystone | 02:12 | |
| *** arborism is now known as amcrn | 02:12 | |
| *** theocean_ has joined #openstack-keystone | 02:20 | |
| *** marcoemorais has quit IRC | 02:21 | |
| *** theocean154 has quit IRC | 02:21 | |
| *** amcrn has quit IRC | 02:32 | |
| *** devlaps has quit IRC | 02:43 | |
| *** david-lyle has joined #openstack-keystone | 02:52 | |
| *** ayoung has joined #openstack-keystone | 02:56 | |
| ayoung | morganfainberg, just a gentle reminder that https://review.openstack.org/#/c/55908/59/keystone/contrib/revoke/backends/kvs.py could really use a review by you | 02:59 |
|---|---|---|
| *** richm has quit IRC | 03:01 | |
| achampion | if 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 inheritance | 03:14 |
| *** lbragstad has joined #openstack-keystone | 03:17 | |
| *** morganfainberg is now known as morganfainberg_Z | 03:19 | |
| *** topol has joined #openstack-keystone | 03:35 | |
| *** theocean154 has joined #openstack-keystone | 03:47 | |
| *** theocean_ has quit IRC | 03:47 | |
| *** gyee has quit IRC | 03:52 | |
| *** harlowja is now known as harlowja_away | 03:57 | |
| *** stevemar has joined #openstack-keystone | 03:59 | |
| *** ChanServ sets mode: +v stevemar | 03:59 | |
| *** huats has quit IRC | 03:59 | |
| *** huats has joined #openstack-keystone | 04:11 | |
| ayoung | jamielennox, second nod on this would be appreciated | 04:25 |
| ayoung | https://review.openstack.org/#/c/71455/ | 04:26 |
| jamielennox | ayoung: i don't think you can give the first +2 yourself | 04:28 |
| ayoung | jamielennox, dstanek and I can both together, though | 04:28 |
| *** KanagarajM_ has joined #openstack-keystone | 04:28 | |
| ayoung | I wasn't going to approve it without either him or another core | 04:28 |
| jamielennox | ayoung: i would say that lets you do a +1 each | 04:29 |
| ayoung | sure | 04:29 |
| *** topol has quit IRC | 04:29 | |
| ayoung | dolphm, bknudson morganfainberg_Z, stevemar can one of you kick this one over the limit https://review.openstack.org/#/c/71455/ | 04:44 |
| dolphm | ayoung: done | 04:45 |
| stevemar | ayoung, taking a quick ... nevermind | 04:46 |
| ayoung | dolphm, thanks. You to stevemar | 04:46 |
| ayoung | dolphm, 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 in | 04:51 |
| *** ayoung is now known as ayoung_zZzZZzz_ | 04:55 | |
| *** stevemar has quit IRC | 05:00 | |
| *** chandan_kumar has joined #openstack-keystone | 05:07 | |
| *** gokrokve has quit IRC | 05:31 | |
| *** gokrokve has joined #openstack-keystone | 05:31 | |
| *** browne has quit IRC | 05:35 | |
| *** gokrokve has quit IRC | 05:36 | |
| *** gokrokve has joined #openstack-keystone | 05:38 | |
| *** dolphm is now known as dolphm_503 | 05:41 | |
| *** marcoemorais has joined #openstack-keystone | 05:58 | |
| *** marcoemorais1 has joined #openstack-keystone | 06:01 | |
| *** marcoemorais has quit IRC | 06:03 | |
| *** lbragstad is now known as lbragstad|away | 06:10 | |
| *** dolphm_503 is now known as dolphm | 06:11 | |
| *** gokrokve has quit IRC | 06:20 | |
| *** gokrokve has joined #openstack-keystone | 06:20 | |
| *** gokrokve has quit IRC | 06:21 | |
| *** theocean154 has quit IRC | 06:23 | |
| *** dolphm is now known as dolphm_503 | 06:23 | |
| *** rwsu has quit IRC | 06:27 | |
| *** saju_m has joined #openstack-keystone | 06:50 | |
| *** dolphm_503 is now known as dolphm | 06:56 | |
| *** dolphm is now known as dolphm_503 | 07:05 | |
| *** gokrokve has joined #openstack-keystone | 07:21 | |
| *** gokrokve has quit IRC | 07:26 | |
| *** bvandenh has joined #openstack-keystone | 07:44 | |
| *** marekd|email-me is now known as marekd | 07:52 | |
| *** dolphm_503 is now known as dolphm | 07:56 | |
| *** leseb has joined #openstack-keystone | 08:04 | |
| *** dolphm is now known as dolphm_503 | 08:06 | |
| *** leseb has quit IRC | 08:07 | |
| *** leseb has joined #openstack-keystone | 08:07 | |
| *** gokrokve has joined #openstack-keystone | 08:22 | |
| *** gokrokve has quit IRC | 08:27 | |
| *** KanagarajM_ has quit IRC | 08:27 | |
| *** Kanagaraj has joined #openstack-keystone | 08:27 | |
| *** marcoemorais1 has quit IRC | 08:38 | |
| *** dolphm_503 is now known as dolphm | 08:57 | |
| *** marcoemorais has joined #openstack-keystone | 09:05 | |
| *** dolphm is now known as dolphm_503 | 09:09 | |
| *** marcoemorais has quit IRC | 09:10 | |
| *** gokrokve has joined #openstack-keystone | 09:22 | |
| *** gokrokve has quit IRC | 09:27 | |
| *** Kanagaraj has quit IRC | 09:36 | |
| *** jamielennox has quit IRC | 09:36 | |
| *** jamielennox has joined #openstack-keystone | 09:39 | |
| *** ChanServ sets mode: +v jamielennox | 09:39 | |
| *** dolphm_503 is now known as dolphm | 10:00 | |
| *** marcoemorais has joined #openstack-keystone | 10:06 | |
| *** dolphm is now known as dolphm_503 | 10:09 | |
| *** marcoemorais has quit IRC | 10:11 | |
| *** david-lyle has quit IRC | 10:19 | |
| *** florentflament has joined #openstack-keystone | 10:25 | |
| *** dolphm_503 is now known as dolphm | 11:00 | |
| *** jamielennox has quit IRC | 11:04 | |
| *** jamielennox has joined #openstack-keystone | 11:05 | |
| *** ChanServ sets mode: +v jamielennox | 11:05 | |
| *** marcoemorais has joined #openstack-keystone | 11:07 | |
| *** bvandenh has quit IRC | 11:08 | |
| *** dolphm is now known as dolphm_503 | 11:10 | |
| *** marcoemorais has quit IRC | 11:11 | |
| *** gokrokve has joined #openstack-keystone | 11:22 | |
| *** leseb has quit IRC | 11:26 | |
| *** gokrokve has quit IRC | 11:27 | |
| *** leseb has joined #openstack-keystone | 11:37 | |
| *** leseb has quit IRC | 11:39 | |
| *** dolphm_503 is now known as dolphm | 12:01 | |
| *** marcoemorais has joined #openstack-keystone | 12:07 | |
| *** bvandenh has joined #openstack-keystone | 12:09 | |
| *** dolphm is now known as dolphm_503 | 12:11 | |
| *** marcoemorais has quit IRC | 12:12 | |
| *** bvandenh has quit IRC | 12:19 | |
| *** gokrokve has joined #openstack-keystone | 12:22 | |
| *** gokrokve has quit IRC | 12:27 | |
| *** leseb has joined #openstack-keystone | 12:50 | |
| *** achampio1 has joined #openstack-keystone | 12:51 | |
| *** achampion has quit IRC | 12:53 | |
| *** leseb has quit IRC | 12:54 | |
| *** leseb has joined #openstack-keystone | 12:55 | |
| *** dolphm_503 is now known as dolphm | 12:57 | |
| *** bvandenh has joined #openstack-keystone | 12:57 | |
| *** achampion has joined #openstack-keystone | 13:02 | |
| *** achampio1 has quit IRC | 13:04 | |
| *** marcoemorais has joined #openstack-keystone | 13:08 | |
| *** bvandenh has quit IRC | 13:12 | |
| *** marcoemorais has quit IRC | 13:13 | |
| *** gokrokve has joined #openstack-keystone | 13:22 | |
| *** browne has joined #openstack-keystone | 13:25 | |
| *** gokrokve has quit IRC | 13:27 | |
| *** topol has joined #openstack-keystone | 13:34 | |
| *** dstanek has joined #openstack-keystone | 13:37 | |
| *** ChanServ sets mode: +v dstanek | 13:37 | |
| *** leseb has quit IRC | 13:50 | |
| *** leseb has joined #openstack-keystone | 13:51 | |
| *** amichon has joined #openstack-keystone | 13:52 | |
| *** leseb has quit IRC | 13:55 | |
| *** bknudson has quit IRC | 14:00 | |
| *** leseb has joined #openstack-keystone | 14:02 | |
| *** achampion has quit IRC | 14:05 | |
| *** marcoemorais has joined #openstack-keystone | 14:09 | |
| *** marcoemorais has quit IRC | 14:14 | |
| *** dolphm is now known as dolphm_503 | 14:15 | |
| *** lbragstad|away has quit IRC | 14:18 | |
| *** bknudson has joined #openstack-keystone | 14:20 | |
| *** ayoung_zZzZZzz_ is now known as ayoung | 14:20 | |
| marekd | bknudson: any opinion on https://review.openstack.org/#/c/71353/42/keystone/assignment/backends/sql.py line 289? | 14:21 |
| bknudson | marekd: assignment types only exist in the sql backend. | 14:22 |
| *** gokrokve has joined #openstack-keystone | 14:22 | |
| bknudson | so this check should be done in the sql backend. | 14:22 |
| bknudson | AssignmentType is defined at line 30 in backends.sql | 14:23 |
| marekd | bknudson: yep | 14:23 |
| *** dolphm_503 is now known as dolphm | 14:25 | |
| dstanek | ayoung: what does the @ mean in policy.json? | 14:25 |
| dstanek | ayoung: that's the first time i have seen that | 14:25 |
| marekd | bknudson: thanks for the comment | 14:26 |
| ayoung | dstanek, "always true" | 14:27 |
| *** gokrokve has quit IRC | 14:27 | |
| ayoung | dstanek, https://github.com/openstack/keystone/blob/master/keystone/openstack/common/policy.py#L49 | 14:27 |
| dstanek | ayoung: looks like i need to read through that module later; thanks for the link | 14:28 |
| ayoung | dstanek, its not too complicated: @ for always pass ! for always fail, the role checks, and the "and" and "or" rules | 14:29 |
| amichon | hi, I want to contribute to https://blueprints.launchpad.net/keystone/+spec/notifications | 14:29 |
| dstanek | ayoung: i'm just wondering what other little things are hidden in there | 14:29 |
| ayoung | dstanek, 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 token | 14:30 |
| *** dolphm is now known as dolphm_503 | 14:30 | |
| dstanek | amichon: hi | 14:38 |
| dstanek | amichon: did you have anything in mind? | 14:41 |
| dstanek | ayoung: so the revoke extension is enabled by default? | 14:45 |
| ayoung | dstanek, yes | 14:45 |
| ayoung | dstanek, It should be self balancing memory wise, and revocation events are fairly light weight. Figured better to get it in and tested | 14:45 |
| amichon | dstanek, yes I'd to be notified for create_grant for instance | 14:50 |
| ayoung | dstanek, speaking of policy https://review.openstack.org/#/c/71353/42/etc/policy.v3cloudsample.json is that right? | 14:50 |
| bknudson | do we need flush_tokens for revocation events? | 14:51 |
| ayoung | bknudson, for the time being, we need to clean up tokens. Once we go ephemeral, not | 14:52 |
| ayoung | bknudson, the prune functions make sure the databases don't get overfull as well | 14:52 |
| ayoung | with the events themselves | 14:52 |
| bknudson | ok, that happens for sql, too? | 14:52 |
| bknudson | (the prune function) | 14:53 |
| *** achampion has joined #openstack-keystone | 14:56 | |
| *** lbragstad has joined #openstack-keystone | 15:00 | |
| achampion | if 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 inheritance | 15:02 |
| *** saju_m has quit IRC | 15:02 | |
| *** gokrokve has joined #openstack-keystone | 15:02 | |
| achampion | I would have thought that the user should be able to get admin role on the project | 15:02 |
| *** marcoemorais has joined #openstack-keystone | 15:10 | |
| dstanek | ayoung: i wouldn't think so | 15:10 |
| *** leseb has quit IRC | 15:13 | |
| *** leseb_ has joined #openstack-keystone | 15:13 | |
| ayoung | dstanek, would is_admin be a more reasonable role for listing users in groups? | 15:14 |
| *** marcoemorais has quit IRC | 15:15 | |
| *** rwsu has joined #openstack-keystone | 15:18 | |
| *** leseb_ has quit IRC | 15:18 | |
| dstanek | ayoung: as a default i think that would be fine | 15:19 |
| ayoung | ++ | 15:19 |
| ayoung | marekd, https://review.openstack.org/#/c/71353/ is pretty close. I think the policy defaults are my one quibble. Any reason why they should be [] ? | 15:22 |
| bknudson | For backwards compatibility, do we need to support setting the endpoint enabled attribute to a non-boolean? | 15:23 |
| dstanek | ayoung: i'm not sure i get test_past_expiry_are_removed() - what is it actually testing for? | 15:23 |
| marekd | ayoung: you mean this: etc/policy.v3cloudsample.json ? | 15:23 |
| bknudson | e.g., "enabled": "puppies" | 15:23 |
| ayoung | marekd, and the other, yes | 15:24 |
| lbragstad | bknudson: there was no check if it was a boolean or not? | 15:24 |
| bknudson | lbragstad: it wasn't defined in the model, so it got stuck in the "extras" attribute | 15:24 |
| bknudson | there's no checking anything not in the model. | 15:24 |
| bknudson | extras are free-form. | 15:25 |
| lbragstad | ahh | 15:25 |
| lbragstad | ok | 15:25 |
| marekd | ayoung: admin_required is impossible here, as a normal user is going to call it, and he has only federated, unscoped token. | 15:25 |
| marekd | this call is to list all project i can try scoping... | 15:25 |
| lbragstad | bknudson: because it can be specific to the backend, right? | 15:25 |
| marekd | ayoung: well..nothing is impossible :-) | 15:25 |
| ayoung | marekd, hmmm....so we would want the check scoped appropriately | 15:25 |
| ayoung | let me think...think think think | 15:25 |
| bknudson | lbragstad: 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 |
| marekd | ayoung: <hint> this is something proposed by dolph. | 15:26 |
| marekd | ayoung: well, not proposed, but this is a feedback i got from him and he was fine with setting those policies to "" | 15:26 |
| ayoung | ok, 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 |
| ayoung | hmmmm, 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 API | 15:27 |
| marekd | ayoung: 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/domain | 15:27 |
| ayoung | and for populating a token, it should be done internal.... | 15:27 |
| ayoung | ah...so user is selecting groups that they can potentially be part of. | 15:28 |
| marekd | ayoung: no | 15:28 |
| marekd | ayoung: list of groups is a result of RuleProcessor | 15:28 |
| ayoung | marekd, do we filter the list? | 15:28 |
| marekd | ayoung: what list? | 15:28 |
| ayoung | based on the user data> | 15:29 |
| bknudson | I thought it was only going to return enabled groups | 15:29 |
| ayoung | only let a user see rules for a group that they are a part of | 15:29 |
| bknudson | oops, enabled projects and domains | 15:29 |
| marekd | bknudson: 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 |
| marekd | actualy, maybe its a good moment to raise it up here. RuleProcessor will issue any group_id, whetever stays in the rules. | 15:30 |
| bknudson | I think it makes sense for RuleProcessor to do it. | 15:31 |
| bknudson | but then there should be someplace where we make sure the groups exist. | 15:31 |
| bknudson | and are enabled. | 15:31 |
| *** dolphm_503 is now known as dolphm | 15:31 | |
| marekd | now 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 |
| marekd | so we could either reject such queries or AT LEAST log warning. | 15:32 |
| lbragstad | bknudson: doesn't look like the catalog kvs backend does any really that different from the sql backend | 15:32 |
| marekd | bknudson: I would leave RuleProcessor as a blackbox that's the only task is to map rules.... | 15:32 |
| ayoung | marekd, 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 |
| lbragstad | bknudson: s/any/anthing/ | 15:33 |
| bknudson | lbragstad: what does it do with enabled? | 15:33 |
| marekd | ayoung: specify "who the user is". It's ephemeral user, so tomorrow there will be no trace of his activity... | 15:33 |
| marekd | the other scenario is: what should happend, when I create an unscoped token with groups {A,B,C} and in the meantime somebody deletes group B | 15:34 |
| ayoung | marekd, 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 good | 15:34 |
| ayoung | marekd, if group B is deleted it should just be silently dropped from the results | 15:35 |
| ayoung | the roles for the group, that is | 15:35 |
| marekd | possible fix: validate the groups every time this unscoped token is used (for scoping usaally) | 15:35 |
| ayoung | marekd, 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 |
| marekd | ayoung: actually, that'd be a good test... | 15:37 |
| marekd | i will add it. | 15:37 |
| ayoung | ++ | 15:37 |
| bknudson | that would require referential integrity between the assignment and identity backend | 15:38 |
| bknudson | if they have groups in ldap and are maintaining with ldap then keystone doesn't know if a group was deleted | 15:38 |
| ayoung | http://xkcd.com/1335/ for planning meetings with Australia | 15:38 |
| lbragstad | bknudson: nothing specifically. It doesn't check the endpoint reference for anything with enabled: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/kvs.py#L113-L119 | 15:39 |
| bknudson | lbragstad: looks like kvs just takes whatever you give it for the endpoint, so enabled could be anything (as could any other field) | 15:40 |
| lbragstad | bknudson: right, just takes the reference and shoves it into the backend. | 15:40 |
| marekd | ayoung: 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 |
| lbragstad | bknudson: afaict the one parameters that get checked when creating an endpoint are publicurl and service_id | 15:42 |
| bknudson | lbragstad: where is publicurl checked? | 15:43 |
| ayoung | marekd, 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 view | 15:43 |
| lbragstad | bknudson: https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L93 | 15:43 |
| lbragstad | s/one/only ^^ can't type today | 15:44 |
| bknudson | lbragstad: that's v2, what about v3? | 15:44 |
| * lbragstad must need more coffee | 15:44 | |
| lbragstad | oh yep, sorry you're right. service_id and interface | 15:44 |
| lbragstad | https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L243-L244 | 15:44 |
| *** lnxnut has joined #openstack-keystone | 15:44 | |
| bknudson | lbragstad: looks like we just require that the attribute exists? not that it's a string? | 15:45 |
| lbragstad | bknudson: right... | 15:45 |
| lbragstad | I am trying to help change that here too | 15:45 |
| lbragstad | https://review.openstack.org/#/c/76030/2/keystone/catalog/controllers.py | 15:45 |
| bknudson | so it would happily accept "interface": 3 | 15:45 |
| marekd | ayoung: 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 |
| lbragstad | you know.. that might be a good idea for the _BaseController | 15:45 |
| lbragstad | for the required attribute (or all attribs) for that matter, make sure they are the proper type | 15:46 |
| bknudson | well, we already know that we need to do better input validation | 15:46 |
| lbragstad | bknudson: yeah, this would be a good step | 15:46 |
| marekd | ayoung: hm, let me check if we have a full test for asking for roles from non-existing group... | 15:46 |
| bknudson | we don't want to wind up slowly and poorly reimplementing JSONSchema. | 15:46 |
| lbragstad | ++ | 15:48 |
| lbragstad | still need to handle the XML case though don't we, for now? | 15:48 |
| bknudson | lbragstad: what does XML have to do with it? | 15:49 |
| bknudson | the XML input just gets converted to JSON. | 15:49 |
| lbragstad | bknudson: ah yep | 15:49 |
| *** stevemar has joined #openstack-keystone | 15:49 | |
| *** ChanServ sets mode: +v stevemar | 15:49 | |
| *** richm has joined #openstack-keystone | 15:50 | |
| *** kibad has joined #openstack-keystone | 15:50 | |
| kibad | this question is regarding keystone spec | 15:50 |
| kibad | in build requires we have mentioned "python2-devel" | 15:50 |
| kibad | is that a typo? or we actually have that particular package? | 15:50 |
| kibad | because 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 |
| lbragstad | bknudson: so, how would we want to go about this? continue with the validation impl in common.controllers._BaseController | 15:51 |
| dolphm | kibad: what are you looking at, exactly? that might be referencing python-dev in debian land, for example | 15:51 |
| bknudson | lbragstad: I don't want to have a new validation library. | 15:51 |
| ayoung | marekd, 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 |
| bknudson | let's go with an existing one instead | 15:51 |
| dstanek | ayoung: 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 |
| kibad | dolphm: I'm trying to configure openstack on centos 5.8 | 15:51 |
| bknudson | find out what nova's doing. I think it's JSONSchema. | 15:51 |
| marekd | ayoung: ++ | 15:51 |
| kibad | since centos runs on python 2.4 | 15:52 |
| *** chandan_kumar has quit IRC | 15:52 | |
| dolphm | kibad: there's a python-devel in centos 6 | 15:52 |
| ayoung | CONF.token.revoke_by_id is default to true dstanek and allows us to phase that out over time | 15:52 |
| kibad | I've installed python2.6 on it and building python26 openstack packages for centos 5.8 | 15:52 |
| kibad | dolphm: both python2-devel and python-devle are one and same? | 15:52 |
| dolphm | kibad: i'm assuming so, since python2 is the default, as you said | 15:53 |
| kibad | dolphm: this search shows existence of python2-devel :( confused.. http://www.rpmfind.net/linux/rpm2html/search.php?query=python2-devel | 15:54 |
| *** bvandenh has joined #openstack-keystone | 15:54 | |
| *** ayoung is now known as ayoung-mtg | 15:55 | |
| dolphm | kibad: sorry, i don't spend much time in rpm land -- ayoung would know better than i | 15:55 |
| *** chandan_kumar has joined #openstack-keystone | 15:56 | |
| kibad | dolphm: Thanks.. looks like ayoung-mtg is away :( | 15:57 |
| *** david-lyle has joined #openstack-keystone | 15:57 | |
| dstanek | kibad: so python-devel is 2.4 on centos? | 15:58 |
| dolphm | oh that's a blocker then | 15:58 |
| dolphm | i think it's 2.6 on centos 6 | 15:58 |
| kibad | dstanek: yes I can find python-devel for default python 2.4 on centos 5.8 | 15:59 |
| dolphm | kibad: openstack doesn't support < 2.6 | 15:59 |
| *** thedodd has joined #openstack-keystone | 15:59 | |
| kibad | dolphm: yes | 15:59 |
| kibad | dolphm: That's the reason I'm rebuilding python26 packages for centos 5.8 | 15:59 |
| dolphm | oh that doesn't sound fun at all | 16:00 |
| dstanek | kibad: the reason you need the devel package is likely for building all of the C-based dependencies | 16:01 |
| dstanek | kibad: if you install 2.6 from source I think you get the headers and the libs already | 16:01 |
| kibad | dstanek: I've installed 2.6 via epel | 16:02 |
| kibad | dstanek: and you are right | 16:02 |
| *** david_lyle_ has joined #openstack-keystone | 16:02 | |
| kibad | dstanek: devel lib is not required for keystone installtion | 16:02 |
| lbragstad | bknudson: Nova uses a validator https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py | 16:04 |
| lbragstad | which looks like it just wraps jsonschema | 16:04 |
| bknudson | lbragstad: interesting. | 16:04 |
| bknudson | let's steal it | 16:04 |
| lbragstad | ++++ | 16:05 |
| dolphm | cool ^ | 16:05 |
| *** david-lyle has quit IRC | 16:06 | |
| *** david-lyle has joined #openstack-keystone | 16:08 | |
| *** amichon has quit IRC | 16:10 | |
| *** ayoung-mtg is now known as ayoung | 16:11 | |
| lbragstad | bknudson: doesn't look like it's used very much at the moment | 16:11 |
| ayoung | kibad, 2.6, not 2.4 | 16:12 |
| *** david_lyle_ has quit IRC | 16:12 | |
| kibad | ayoung: yes I'm rebuilding packages for 2.6 | 16:12 |
| kibad | on 5.8 | 16:12 |
| ayoung | kibad, why are you doing this? | 16:12 |
| ayoung | It sounds slighly insane from my perspective | 16:12 |
| kibad | ayoung: requirements :( | 16:12 |
| *** david_lyle_ has joined #openstack-keystone | 16:13 | |
| ayoung | kibad, find the people that wrote those requirements and kneecap them | 16:13 |
| kibad | ayoung: :D | 16:13 |
| kibad | ayoung: left with no choice :) | 16:14 |
| lbragstad | bknudson: ah nevermind... users @validator.schema() wrapper | 16:15 |
| ayoung | kibad, seriously, it ia really bad idea | 16:15 |
| ayoung | none of the virt stuff in nova etc is going to work right | 16:15 |
| kibad | ayoung: if I get the relevant packages rebuild for 5.8 and python 2.6 do you think there will be issues? | 16:16 |
| ayoung | Keystone should be run on its own machine, and can be a VM | 16:16 |
| *** david-lyle has quit IRC | 16:16 | |
| ayoung | kibad, too many to count | 16:16 |
| kibad | ayoung: :( | 16:16 |
| ayoung | A horror of Lovecraftian Proportions | 16:16 |
| ayoung | kibad, seriosuly, why? | 16:17 |
| kibad | ayoung: its part of investigation | 16:18 |
| ayoung | I 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-keystone | 16:19 | |
| kibad | ayoung: I will try to suggest this :) probably I will be ignored.. | 16:21 |
| *** david_lyle_ has quit IRC | 16:21 | |
| ayoung | kibad, 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-keystone | 16:23 | |
| ayoung | tell them it is a security issue | 16:23 |
| kibad | ayoung: ok, I will keep these points and try to convince them.. | 16:25 |
| kibad | ayoung & dolphm: thanks! | 16:27 |
| *** david-lyle has quit IRC | 16:27 | |
| ayoung | YW | 16:27 |
| *** david_lyle_ is now known as david-lyle | 16:27 | |
| *** david_lyle_ has joined #openstack-keystone | 16:28 | |
| richm | how long does it typically take to run tox -e py27? | 16:28 |
| ayoung | for ev er richm | 16:29 |
| ayoung | the first time | 16:29 |
| richm | what about subsequent times? | 16:29 |
| ayoung | richm, it is doing all sorts of downloads in the background | 16:29 |
| richm | yes | 16:30 |
| ayoung | 300 seconds | 16:30 |
| ayoung | more or less | 16:30 |
| richm | I can see the .tox/py27 directory being updated | 16:30 |
| ayoung | I had find .tox/py27 -print | wc -l on watch while I was running it | 16:30 |
| richm | 300 seconds??? I'm on 1200 seconds already | 16:30 |
| ayoung | it tops out at about 12000 files, then drops to 7000 and starts running tests | 16:30 |
| dstanek | stevemar: hi | 16:31 |
| richm | yeah, it's past the download/update stage | 16:31 |
| richm | well past | 16:31 |
| *** david-lyle has quit IRC | 16:31 | |
| dstanek | ayoung: i see what you mean. any reason we don't give the user an indication that the functionality is disabled? | 16:33 |
| stevemar | dstanek, ahoy hoy | 16:33 |
| dstanek | stevemar: i just -1ed the limited trusts - what do you think of my comments here: https://review.openstack.org/#/c/56243/20/keystone/common/sql/migrate_repo/versions/041_add_remaining_uses_count_to_trusts.py | 16:33 |
| stevemar | dstanek, mostly nits, but better to get them out of the way now i suppose | 16:35 |
| stevemar | actually, the copyright one isn't a nit, i take that back. It's easy to fix though :) | 16:35 |
| ayoung | dstanek, what kind of indication? | 16:35 |
| stevemar | dstanek, were you okay otherwise? | 16:36 |
| ayoung | copyright is not a nit? I beg to differ.... | 16:36 |
| stevemar | ayoung, tell that to legal | 16:36 |
| ayoung | Heh...OK, m,aybe to you it isn't a nit | 16:36 |
| *** david_lyle_ has quit IRC | 16:36 | |
| stevemar | hehe | 16:37 |
| *** marekd is now known as marekd|away | 16:37 | |
| stevemar | dstanek, i might just push a new change if mhu doesn't, but i'll let a few others look it over | 16:38 |
| dstanek | ayoung: 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 it | 16:38 |
| ayoung | dstanek, we talking about the revoke_by_id thing? | 16:38 |
| mhu | stevemar, go ahead if you want, I am not available for making the changes for an hour or two | 16:39 |
| dstanek | stevemar: 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 |
| ayoung | the idea is that there are two mechanisms, and we are transitioning from one to another. | 16:39 |
| dstanek | ayoung: yes, the revoke_by_id setting | 16:39 |
| ayoung | so...you think it would be an error if both revoke_by_id was disabled and no revocation events? | 16:39 |
| stevemar | dstanek, they would be useless, i brought this up early on | 16:40 |
| dstanek | stevemar: why would they be useless? | 16:40 |
| ayoung | or...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 |
| stevemar | because the use count is at 0, they can't update it, and they can't get another trust / token with it | 16:41 |
| *** devlaps has joined #openstack-keystone | 16:41 | |
| dstanek | ayoung: the 503 idea - that lets people know their crap isn't working | 16:41 |
| ayoung | dstanek, ++ I'll add that | 16:41 |
| dstanek | stevemar: 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-keystone | 16:45 | |
| *** david-lyle has joined #openstack-keystone | 16:46 | |
| ayoung | 410 Gone dstanek? | 16:46 |
| stevemar | dstanek, 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 |
| stevemar | dstanek, i meant in general, i don't get the point of having a 0 use count trust hanging around | 16:48 |
| dstanek | stevemar: ah, i see - am i right on my assumption about downgrading? | 16:49 |
| stevemar | i believe so | 16:49 |
| mhu | dstanek, agreed on 0 use trusts, good catch | 16:49 |
| dstanek | ayoung: i think a 410 could work | 16:50 |
| *** kibad has quit IRC | 16:50 | |
| dstanek | stevemar, mhu: you really just want to delete any records that are not null right? | 16:54 |
| dstanek | mhu: thx | 16:54 |
| mhu | dstanek, yes | 16:54 |
| dstanek | stevemar, 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 |
| stevemar | dstanek, what do you mean by approximate? | 16:56 |
| *** marcoemorais has joined #openstack-keystone | 16:58 | |
| dstanek | stevemar: 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 decrement | 16:58 |
| stevemar | dstanek, only docs for remaining trusts: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md | 16:59 |
| dstanek | stevemar: it's possible that it's so small it's not worth mentioning, but the little security guy on my shoulder keeps bringing it up | 16:59 |
| mhu | dstanek, I updated the document on trusts in identity-api to mention the new remaining_uses parameter | 16:59 |
| *** gokrokve has quit IRC | 17:02 | |
| mhu | dstanek, the sql backend should be protected from race conditions thanks to "with_lockmode('update')" when opening the session | 17:03 |
| *** gokrokve has joined #openstack-keystone | 17:03 | |
| *** gyee has joined #openstack-keystone | 17:04 | |
| dstanek | mhu: ah, yes. i didn't see that. You are absolutely right. | 17:05 |
| *** saju_m has joined #openstack-keystone | 17:06 | |
| mhu | dstanek, 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 all | 17:06 |
| *** gokrokve has quit IRC | 17:08 | |
| *** gabriel-bezerra has joined #openstack-keystone | 17:10 | |
| dstanek | mhu: as far as the SQL backend is concerned i think you did that for any reasonable database | 17:11 |
| dstanek | mhu: nice work on this | 17:11 |
| stevemar | dstanek, could you review the links here: https://review.openstack.org/#/q/project:openstack/identity-api+status:open+owner:stevemar,n,z | 17:22 |
| stevemar | :) | 17:22 |
| dstanek | stevemar: shore | 17:25 |
| stevemar | dstanek, noice | 17:25 |
| mhu | dstanek, about the copyright, should I drop the line entirely or replace it by something like "Copyright (c) 2014 Matthieu Huin <mhu@enovance.com>" ? | 17:30 |
| dstanek | mhu: that's up to you, i normally leave it our for my stuff - i have not bothered to find out the legal ramifications either way | 17:37 |
| dstanek | stevemar: can you have different protocols using the saml2 method? | 17:45 |
| *** amcrn has joined #openstack-keystone | 17:46 | |
| dolphm | mhu: your employer might not like you claiming copyright for yourself, but know that copyright lines in files have zero legal relevance anyway | 17:56 |
| dolphm | mhu: with the CLA and project-level LICENSE file etc, file-level copyright claims basically serve as nothing more than advertising for employers | 17:56 |
| dtroyer | and cruft that accumulates and needs cleaning out... | 18:01 |
| dtroyer | Dolphm: new topic: where does moving the middleware out of keystoneclient stand? still on the table? | 18:01 |
| bknudson | dtroyer: what middleware? | 18:03 |
| bknudson | oh, keystoneclient | 18:03 |
| dolphm | dtroyer: i haven't seen any discussion on it recently... to a middleware-specific repo, correct? | 18:03 |
| dolphm | bknudson: auth_token and the other one or two in there now | 18:03 |
| dtroyer | auth_token and s3_token | 18:03 |
| dtroyer | yes | 18:03 |
| dtroyer | my concern is just the additional prereqs (however small) it adds to client-only installations | 18:04 |
| dolphm | ++ | 18:04 |
| dolphm | https://github.com/openstack/python-keystoneclient/blob/master/requirements.txt | 18:04 |
| dolphm | not sure why netaddr is in there, but there's not really any left today | 18:04 |
| dolphm | auth_token doesn't depend on webob needlessly anymore or anything | 18:05 |
| bknudson | netaddr is used by auth_token | 18:05 |
| bknudson | and jsonutils | 18:05 |
| dolphm | looks like netaddr is for ipv6 support in auth_token | 18:05 |
| richm | tox -e py27 running for 2 hours and counting . . . | 18:07 |
| dolphm | richm: unless your internet connection is insanely slow or you're on really weak hardware, it shouldn't take that long | 18:08 |
| dolphm | richm: i'd rerun and give it 10 or 15 minutes tops for a first run | 18:08 |
| dolphm | richm: a normal run is < 5 min for me | 18:08 |
| richm | it is 2 hours past the point of downloading/installing python env in .tox/py27 | 18:09 |
| nkinder | richm: that's crazy. I'll try a run of tox on my F18 box right now | 18:11 |
| richm | ps shows the process is python -m subunit.run discover -t ./ ./keystone/tests | 18:13 |
| dolphm | richm: kill tox and run that directly | 18:13 |
| dolphm | richm: you can use tox's venv (.tox/venv/bin/activate first) | 18:14 |
| richm | no venv or .venv under .tox | 18:15 |
| richm | oh, I see - py27 | 18:16 |
| richm | running | 18:17 |
| *** gokrokve has joined #openstack-keystone | 18:19 | |
| *** devlaps has quit IRC | 18:24 | |
| *** devlaps has joined #openstack-keystone | 18:24 | |
| *** devlaps has quit IRC | 18:24 | |
| *** devlaps has joined #openstack-keystone | 18:25 | |
| *** gabriel-bezerra has quit IRC | 18:29 | |
| lbragstad | bknudson: looks like some of the nova plugins use this https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/v3/agents.py for setting the schema for validation | 18:32 |
| richm | 16 minutes and counting . . . | 18:33 |
| bknudson | lbragstad: looks like a good format | 18:33 |
| *** harlowja_away is now known as harlowja | 18:34 | |
| ayoung | dstanek, for k, v in locals().copy().iteritems(): becomes what with six? | 18:34 |
| lbragstad | I agree, each plugin could have a schema subdir that holds it | 18:34 |
| bknudson | richm: have you tried setting up tmpfs for keystone/tests/tmp? http://adam.younglogic.com/2012/06/sqlite-unit-tests/ | 18:34 |
| richm | no, will try that | 18:34 |
| ayoung | richm, BTW...there is a hack to speed up database access: | 18:34 |
| dolphm | ayoung: six.iteritems(locals().copy()) ? | 18:34 |
| dolphm | that looks like nasty code though | 18:35 |
| *** saju_m has quit IRC | 18:35 | |
| ayoung | dolphm its just copying the parameter list before any local variables get defined. Its in an init function | 18:35 |
| richm | c | 18:36 |
| ayoung | dolphm, basically, it does | 18:36 |
| ayoung | for k, v in locals().copy().iteritems(): | 18:36 |
| ayoung | setattr(self, k, v) | 18:36 |
| *** morganfainberg_Z is now known as morganfainberg | 18:36 | |
| ayoung | so creates a member for each paramer list item | 18:36 |
| ayoung | seemed silly to have to create each one explicitly. Is there a problem with my approach? | 18:37 |
| dolphm | ayoung: why are you starting with locals() instead of something explicit? and why are you making a copy? | 18:37 |
| ayoung | richm, I mount a ramdisk over keystone/tests/tmp and checkout HEAD | 18:37 |
| richm | ok - will try that | 18:37 |
| ayoung | sudo mount -t tmpfs -o size=256M tmpfs /opt/stack/keystone/keystone/tests/tmp | 18:38 |
| ayoung | cd /opt/stack/keystone | 18:38 |
| ayoung | git checkout HEAD keystone/tests/tmp | 18:38 |
| ayoung | richm, ext3 and later are really slow when used with sqlite. | 18:38 |
| richm | ok | 18:38 |
| richm | then that may explain it - my keystone dir is nfs mounted | 18:38 |
| ayoung | dolphm, 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 error | 18:38 |
| ayoung | Yes. richm that is, how do you say, suboptimal? | 18:39 |
| richm | that's one way to put it | 18:39 |
| dolphm | ayoung: if that's in an __init__ or something, then the magic will be very confusing for those new to python | 18:39 |
| dolphm | you're just going to cause headaches ;( | 18:39 |
| ayoung | dolphm, I was going for DRY here.... | 18:39 |
| ayoung | I'd rather leave it as is an comment | 18:40 |
| ayoung | six might reduce the need for the copy, though. going to test | 18:40 |
| nkinder | richm: I'm 30 minutes in, and it's sitting at "running=${PYTHON:-python} -m subunit.run discover" | 18:41 |
| nkinder | I'm using a local disk with ext4 | 18:42 |
| ayoung | RuntimeError: dictionary changed size during iteration | 18:43 |
| ayoung | nkinder, do the mount trick | 18:43 |
| *** chandan_kumar has quit IRC | 18:46 | |
| nkinder | ayoung: for some strange reason, that comment caused me to get "do the hustle" stuck in my head... thanks a lot. ;) | 18:46 |
| ayoung | Nice, Nice, day for it | 18:46 |
| ayoung | dstanek, https://review.openstack.org/#/c/55908/59/keystone/contrib/revoke/model.py to what magic do you refer? | 18:47 |
| richm | ayoung: could I just mkdir /dev/shm/tmp ; ln -s /dev/shm/tmp `pwd`/keystone/tests/tmp | 18:53 |
| dstanek | ayoung: just the whole read from __dict__; i wouldn't block anything because of it, i'm just not a fan | 18:54 |
| dstanek | ayoung: for your earlier question: six.iteritems(locals().copy()) | 18:55 |
| richm | yes, looks like that is working | 18:55 |
| dstanek | dolphm: yeah, the locals needs a copy when there are local environment changes | 18:55 |
| dolphm | dstanek: that wasn't mutating any locals though (?) | 18:56 |
| morganfainberg | henrynash, ayoung, should talk about the uid->domain mapping table idea (re: email about user_id length change) today if possible. cc dolphm | 18:56 |
| dolphm | dstanek: is this something where if i ran it i would facepalm? lol | 18:56 |
| morganfainberg | unless it was already talked about. and i didn't see it in the backlog | 18:56 |
| dolphm | morganfainberg: o/ i haven't | 18:56 |
| dolphm | morganfainberg: other than sort of responding on list | 18:56 |
| morganfainberg | dolphm, yah, my email didn't get the send button clicked | 18:57 |
| morganfainberg | last night | 18:57 |
| morganfainberg | you covered most of it though | 18:57 |
| morganfainberg | ayoung, KVS stuff, you're only doing in-memory in this patchset? | 18:58 |
| henrynash | morganfainberg: so let's think who that would work | 18:59 |
| dolphm | henrynash: (i'd also like to focus on solving for the multi-ldap backend per domain problem first) | 19:00 |
| dolphm | morganfainberg: 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 |
| dolphm | effectively get_domain_id(user_id) | 19:00 |
| dolphm | regardless of whether we're parsing apart the user_id or referencing a lookup table, that's the required interface | 19:01 |
| morganfainberg | if 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 |
| henrynash | dolphm: yes, and we would build the underlying mapping dynamically upon response to any user/group get,list,create call | 19:01 |
| dolphm | so 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 SQL | 19:02 |
| henrynash | dolphm: yes | 19:02 |
| dolphm | or to dogpile (i imagine an LRU backend to be useful here) | 19:03 |
| morganfainberg | dolphm, sounds correct ot me | 19:03 |
| dstanek | dolphm: 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 it | 19:03 |
| henrynash | dolphm: it would replace the current current bit where I extract the domain_id from the user_id | 19:03 |
| morganfainberg | dolphm, would we internally encode the IDP for LDAP users into the user_id? | 19:03 |
| henrynash | one issue…so this could be a BIG table | 19:03 |
| morganfainberg | dolphm, because the major issue we saw before was that DN on LDAP1 could... be DN on LDAP2 | 19:04 |
| dolphm | morganfainberg: that's crossing problem domains -- you mean the DN for LDAP users or something? | 19:04 |
| dolphm | or domain_id? | 19:04 |
| morganfainberg | dolphm, we use the DN to create the id | 19:04 |
| morganfainberg | dolphm, so we would need something that is guaranteed unique for those users | 19:04 |
| morganfainberg | DNs 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 |
| morganfainberg | that was the reason to move to the user_id@@domain model | 19:05 |
| henrynash | morganfainberg: 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 returned | 19:05 |
| dolphm | what 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 |
| morganfainberg | henrynash, that was my thought, that also means we can't LRU (ever) this map table | 19:05 |
| morganfainberg | as much as i like dogpile, anything that could lose state would be horrific and break keystone | 19:06 |
| morganfainberg | dolphm, ++ yes. | 19:06 |
| henrynash | dolphm: and that's essentially what the current code does…you just have to wrap it in a bunch of pre and post processing | 19:07 |
| morganfainberg | henrynash, 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 has | 19:07 |
| *** luisbg has joined #openstack-keystone | 19:08 | |
| henrynash | morganfainbrg: sure…. | 19:08 |
| morganfainberg | henrynash, dolphm, I don't like it, but i think SQL is ... perhaps our only clear option here - fully stateful table. | 19:08 |
| morganfainberg | actually.. i wonder | 19:08 |
| henrynash | morganfainberg: one issue is…how would LDAP entries ever get deleted? | 19:09 |
| morganfainberg | henrynash, UUID5 | 19:09 |
| morganfainberg | ? | 19:09 |
| morganfainberg | Generate a UUID from the SHA-1 hash of a namespace UUID and a name. | 19:09 |
| morganfainberg | henrynash, oh uhm. same issue we have w/ grants tbh | 19:10 |
| dolphm | henrynash: i'd like to keep the table updated with date created and last accessed and then worry about it later | 19:10 |
| dolphm | but that's just wishlist | 19:10 |
| morganfainberg | when we solve grants, we can solve this table | 19:10 |
| morganfainberg | dolphm, but we can use uuid5 i think to cover DN-derived-id+domain_id | 19:10 |
| henrynash | morganfainberg: since most LDAPs will be RO…we'll never see deletes….could imagine some creative ways of culling stale data | 19:11 |
| luisbg | does anybody have an idea why this change (https://review.openstack.org/#/c/73694) 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 |
| morganfainberg | henrynash, like i said, if we solve the issue for grants we solve for map-table. | 19:11 |
| morganfainberg | but if we can't solve that... we can't solve either | 19:11 |
| ayoung | morganfainberg, yep...got to run to an appointmnet | 19:12 |
| morganfainberg | henrynash, 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 up | 19:12 |
| morganfainberg | ayoung, k. just checking before i comment on that | 19:12 |
| morganfainberg | henrynash, s/grant table/grant assignment stuff/ | 19:13 |
| henrynash | morganfainberg: probably being dumb here, but what's the specific isuee with the assignment table? | 19:13 |
| morganfainberg | henrynash, if an ldap user disappears... the grant entries linger around | 19:14 |
| henrynash | morganfainberg: oh, right..sure | 19:14 |
| morganfainberg | henrynash, same exact issue as the map table stuff | 19:14 |
| morganfainberg | henrynash, 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 |
| morganfainberg | henrynash, dolphm, same for Federated users. | 19:16 |
| *** andreaf has joined #openstack-keystone | 19:16 | |
| *** ved_ has joined #openstack-keystone | 19:16 | |
| morganfainberg | info can go into the new user_id map table | 19:16 |
| henrynash | morganfainberg: 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 |
| morganfainberg | henrynash, ++ | 19:17 |
| morganfainberg | the only other question i have is do we need to store any extra metadata (e.g. DN?) in this map table | 19:17 |
| *** ayoung has quit IRC | 19:17 | |
| morganfainberg | initial impl should be SQL, we can figure out if we want dogpile along the way | 19:17 |
| morganfainberg | i know the user id hashing is one way, but if we have a lookup, it doesn't matter | 19:18 |
| henrynash | morganfainberg: I don;'t *think* we would have to store anything else…LDAP backend already has an "id_to/from_DN" | 19:18 |
| morganfainberg | henrynash, if we used uuid5 we cant take the uuid5 and get the DN info back | 19:19 |
| morganfainberg | henrynash, or any uuid for that matter (i like 5 because it's a combination of 2 elements) | 19:19 |
| henrynash | morganfainberg: hmmm | 19:19 |
| morganfainberg | brb caffination calls | 19:21 |
| morganfainberg | ok back | 19:23 |
| henrynash | morganfainberg: not sure, whether, uuid5 really helps | 19:26 |
| richm | ok - with tests/tmp in /dev/shm tests completed in 30 minutes | 19:27 |
| henrynash | morganfainberg: I think it may be a simple SQL: UUID -> Domain + localID | 19:27 |
| morganfainberg | henrynash, 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-ID | 19:27 |
| morganfainberg | henrynash, if we use uuid4() you get something random that isn't replicatable | 19:27 |
| henrynash | morganfainberg: 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 |
| morganfainberg | henrynash, SQL users would still be uuid4, but since we're seeding with external data, uuid5 might buy us repeatable data | 19:28 |
| morganfainberg | henrynash, thinking worst-case scenarios | 19:28 |
| morganfainberg | henrynash, you can tell me i'm being overly defensive here | 19:29 |
| morganfainberg | henrynash, thats ok | 19:29 |
| henrynash | morganfainberg: no, it's an intersteding idea | 19:29 |
| morganfainberg | actually.. it wouldn't work like that :P | 19:30 |
| morganfainberg | because you still can't reverse the uuid -> LDAP DN | 19:30 |
| morganfainberg | it just means you can side-band repopulate things if you needed | 19:30 |
| henrynash | morganfainberg: 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 |
| morganfainberg | henrynash, yeah. | 19:30 |
| morganfainberg | henrynash, =/ grr. | 19:31 |
| henrynash | morganfainberg: Ok, I gotta go to a meeting..back on in a couple of hours - will mull on this! | 19:31 |
| morganfainberg | henrynash, sounds good | 19:32 |
| *** ved_ has quit IRC | 19:33 | |
| *** henrynash has quit IRC | 19:33 | |
| *** dstanek_afk has joined #openstack-keystone | 19:38 | |
| *** ChanServ sets mode: +v dstanek_afk | 19:38 | |
| luisbg | dolphm, ping | 19:41 |
| luisbg | dolphm, can I get some help understanding the build problems with this patch I have very close to review? | 19:42 |
| *** huats_ has joined #openstack-keystone | 19:42 | |
| *** huats_ has quit IRC | 19:42 | |
| *** huats_ has joined #openstack-keystone | 19:42 | |
| *** bvandenh_ has joined #openstack-keystone | 19:43 | |
| dstanek_afk | luisbg: what is the patch? | 19:43 |
| luisbg | dstanek_afk, https://review.openstack.org/#/c/73694 | 19:44 |
| luisbg | I can explain you the issue if you are !afk :) | 19:44 |
| *** dstanek has quit IRC | 19:44 | |
| *** dstanek_afk is now known as dstanek | 19:44 | |
| luisbg | ahhh, there | 19:44 |
| luisbg | dstanek, https://review.openstack.org/#/c/73694/6/tests/test_cfg.py <-- when I don't change the test, it builds fine in Jenkins | 19:45 |
| luisbg | but the error I get with the test change, is not test related, it is Cinder not starting | 19:45 |
| luisbg | http://logs.openstack.org/94/73694/6/check/check-devstack-dsvm-cells/32a9f2e/console.html#_2014-02-26_18_33_38_322 | 19:46 |
| *** gyee has quit IRC | 19:47 | |
| *** bvandenh has quit IRC | 19:47 | |
| *** huats has quit IRC | 19:47 | |
| *** nkinder has quit IRC | 19:47 | |
| dstanek | luisbg: the build failures are not from your code changes - at least not that i can tell | 19:48 |
| dstanek | this actually looks like an error i saw on one of my changesets | 19:48 |
| luisbg | dstanek, but why does it only happen when I change the test case? notice the build passed when I removed that to experiment | 19:50 |
| luisbg | dstanek, have you found the issue in Rechecks? | 19:50 |
| *** marcoemorais has quit IRC | 19:52 | |
| *** gyee has joined #openstack-keystone | 19:53 | |
| *** andreaf has quit IRC | 19:53 | |
| *** nkinder has joined #openstack-keystone | 19:54 | |
| morganfainberg | dolphm, are we dropping kite on the floor? if so i'm ready to abandon the gerrit/etc change | 19:56 |
| stevemar | dstanek, thanks for the reviews :) | 19:56 |
| dolphm | morganfainberg: i was only going to create a feature branch from the current state of the repo, and then propose a git rm from master | 19:56 |
| morganfainberg | ok | 19:57 |
| dolphm | morganfainberg: then worry about it after icehouse releases | 19:57 |
| morganfainberg | dolphm, i'll drop the add the repos stuff | 19:57 |
| *** jraim has quit IRC | 19:57 | |
| morganfainberg | can always restore later | 19:57 |
| *** marcoemorais has joined #openstack-keystone | 19:58 | |
| *** browne is now known as 20WABD4PL | 19:58 | |
| *** browne has joined #openstack-keystone | 19:58 | |
| *** jraim has joined #openstack-keystone | 19:58 | |
| *** jraim has quit IRC | 19:59 | |
| *** browne has quit IRC | 19:59 | |
| *** marcoemorais has quit IRC | 19:59 | |
| *** marcoemorais has joined #openstack-keystone | 20:01 | |
| *** nkinder has quit IRC | 20:01 | |
| *** achampion has quit IRC | 20:01 | |
| *** nkinder has joined #openstack-keystone | 20:01 | |
| *** 20WABD4PL has quit IRC | 20:01 | |
| lbragstad | stevemar: responded to your question on my documentation patch | 20:02 |
| lbragstad | http://paste.openstack.org/show/69942/ | 20:03 |
| *** amcrn has quit IRC | 20:03 | |
| *** achampion has joined #openstack-keystone | 20:03 | |
| dstanek | stevemar: yw | 20:03 |
| dstanek | luisbg: i found it for my review (assuming it's the same issue) | 20:03 |
| dstanek | luisbg: it's interesting that it would only fail if you changed the tests | 20:03 |
| *** jraim has joined #openstack-keystone | 20:05 | |
| *** browne has joined #openstack-keystone | 20:05 | |
| *** jraim has quit IRC | 20:05 | |
| *** jraim has joined #openstack-keystone | 20:05 | |
| *** huats_ is now known as huats | 20:06 | |
| dstanek | luisbg: i think lbragstad rechecked on the bug that i was thinking of | 20:07 |
| stevemar | lbragstad, responded to your response | 20:07 |
| *** henrynash has joined #openstack-keystone | 20:09 | |
| *** browne has left #openstack-keystone | 20:10 | |
| *** henrynash has quit IRC | 20:11 | |
| *** nkinder_ has joined #openstack-keystone | 20:11 | |
| *** doddstack has joined #openstack-keystone | 20:11 | |
| dstanek | luisbg: actually i think that https://bugs.launchpad.net/nova/+bug/1252618 is what i was thinking of | 20:12 |
| *** browne has joined #openstack-keystone | 20:13 | |
| stevemar | lbragstad, i have no idea why the bug i copied went to a ubuntu launchpad page | 20:15 |
| lbragstad | it truncates the latest character of the bug number | 20:16 |
| lbragstad | happens to me too | 20:16 |
| lbragstad | for some reason we can't use full links, it has to be 'bug ######' or something | 20:16 |
| luisbg | dstanek, 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 IRC | 20:18 | |
| *** thedodd has quit IRC | 20:18 | |
| stevemar | dstanek, regarding you latest comment, yes, you would use an unscoped token to access the list projects/domains resources | 20:22 |
| dstanek | luisbg: i think so - seems like the errors are unrelated to your changes | 20:22 |
| luisbg | dstanek, doing so, thanks | 20:22 |
| dstanek | stevemar: :-) do we call that our anywhere? i assumed so, but wanted to make sure | 20:23 |
| stevemar | dstanek, hmmm technically: "The user can then select a project and request a scoped token." | 20:24 |
| stevemar | depends on how good the reader is :) | 20:24 |
| dstanek | stevemar: do you always need an unscoped token to request a scoped token? | 20:26 |
| stevemar | dstanek, in the case of federation, yes :) | 20:26 |
| stevemar | dstanek, but i'll try and add something | 20:27 |
| dstanek | stevemar: it may say that in another part of the doc. i only read the diffs | 20:27 |
| stevemar | dstanek, before the second sentence "To access the resource, an unscoped token is used, the user can then ... " | 20:28 |
| luisbg | dstanek, 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 |
| stevemar | luisbg, it doesn't ignore anything! | 20:28 |
| luisbg | stevemar, so what does it do? I'm confused | 20:29 |
| stevemar | luisbg, i'm glad i was not the only person to think that.. | 20:29 |
| luisbg | stevemar, hahaha you thought the same the first time? | 20:29 |
| stevemar | luisbg, it just adds another checkmark to the recheck list: http://status.openstack.org/rechecks/ | 20:29 |
| stevemar | they won't occur every run | 20:29 |
| luisbg | stevemar, so my patch will only be retested when the other bug is fixed? | 20:29 |
| stevemar | luisbg, as dolphm told me, the point of recheck is: "identifying and prioritizing transient issues to be fixed | 20:31 |
| stevemar | " | 20:31 |
| stevemar | transient being one of the key words | 20:32 |
| *** jamielennox is now known as jamielennox|away | 20:34 | |
| luisbg | stevemar, ahhh OK | 20:34 |
| dstanek | luisbg, stevemar: yeah, it'll put then into the queue shortly after you leave the comment | 20:35 |
| *** marcoemorais has quit IRC | 20:36 | |
| dstanek | stevemar, mhu: are one of you guys working on the limited trusts review? | 20:37 |
| stevemar | dstanek, i think mhu is likely done for the day | 20:39 |
| *** marcoemorais has joined #openstack-keystone | 20:41 | |
| dstanek | stevemar: i may fix up some of the nits that i found to help us along | 20:42 |
| stevemar | dstanek, i'll do it quickly no worries | 20:42 |
| dstanek | stevemar: sounds good to me :-) | 20:43 |
| stevemar | dstanek, https://review.openstack.org/#/c/56243/20/keystone/trust/backends/sql.py line 89, just return, or delete the conditional entirely? | 20:44 |
| stevemar | dstanek, definitely can't just delete it | 20:46 |
| dstanek | stevemar: yeah, you'd have to do a return - assuming i am right about the flush | 20:46 |
| stevemar | dstanek, could pass? | 20:47 |
| stevemar | or break | 20:48 |
| stevemar | pass it si | 20:50 |
| *** henrynash has joined #openstack-keystone | 20:53 | |
| stevemar | dstanek, done sir | 20:54 |
| dstanek | stevemar: checking. sorry, was afk | 20:56 |
| stevemar | dstanek, np dude | 20:57 |
| dstanek | stevemar: the only thing i see is the downgrade again. mhu and I were discussin needing to delete all non-nulls | 21:02 |
| dstanek | stevemar: that would get rid of anything what would be overly decremented (only possible with KVS I think) | 21:03 |
| stevemar | ah i see what you mean | 21:03 |
| *** david_lyle_ has joined #openstack-keystone | 21:23 | |
| *** gokrokve_ has joined #openstack-keystone | 21:24 | |
| *** ayoung_ has joined #openstack-keystone | 21:25 | |
| *** henrynash_ has joined #openstack-keystone | 21:25 | |
| *** stevemar has quit IRC | 21:28 | |
| *** arborism has joined #openstack-keystone | 21:31 | |
| *** gokrokve has quit IRC | 21:34 | |
| *** henrynash has quit IRC | 21:34 | |
| *** henrynash_ is now known as henrynash | 21:34 | |
| *** david-lyle has quit IRC | 21:35 | |
| *** devlaps1 has joined #openstack-keystone | 21:52 | |
| *** devlaps has quit IRC | 21:53 | |
| henrynash | dolphm: 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-keystone | 21:54 | |
| *** leseb has joined #openstack-keystone | 21:54 | |
| ayoung_ | dstanek, morganfainberg gyee would it make sense for me to squash https://review.openstack.org/#/c/69531/ and https://review.openstack.org/#/c/67372/20 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 checking | 21:56 |
| henrynash | ayoung_: 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, yuck | 21:59 |
| ayoung_ | henrynash, lots of problems with that | 22:01 |
| henrynash | ayoung_: 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 |
| gyee | ayoung_, looking | 22:01 |
| henrynash | ayoung_: oh, yes | 22:01 |
| *** ayoung_ is now known as ayoung | 22:01 | |
| henrynash | ayoung_: 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 IRC | 22:02 | |
| ayoung | henrynash, bascially we would have a clone of every user in the SQL backend | 22:02 |
| henrynash | ayoung: well, a mapping of UUID to domainID+local_id | 22:03 |
| ayoung | and 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 |
| ayoung | ugh | 22:03 |
| ayoung | its just.... | 22:03 |
| henrynash | ayoung: 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 do | 22:04 |
| *** marcoemorais has joined #openstack-keystone | 22:04 | |
| henrynash | ayoung: as i said, it was just raised for discussion | 22:05 |
| ayoung | henrynash, I would sooner make the rule len( domainid) len(ldapuserid) < 63 | 22:05 |
| theocean154 | ayoung: will update you on tfa stuff after our open academy meeting tonight 9pm eastern time | 22:05 |
| henrynash | ayoung: funny, I was thinking along those lines! | 22:05 |
| *** theocean154 has quit IRC | 22:05 | |
| *** theocean154 has joined #openstack-keystone | 22:06 | |
| *** henrynash has quit IRC | 22:07 | |
| ayoung | henrynash, is there such a thing as a len 32 char uuid? | 22:07 |
| morganfainberg | topol, ping | 22:14 |
| topol | morganfainberg, Hi | 22:14 |
| *** achampion has quit IRC | 22:36 | |
| *** lbragstad has quit IRC | 22:44 | |
| *** marcoemorais has quit IRC | 22:47 | |
| simo | ayoung: and what do you wehn domain_id + user_id >= 64 ? | 22:53 |
| simo | ayoung: a uuid IIRc is a 128bit number == 32 bytes | 22:53 |
| *** lnxnut has quit IRC | 22:55 | |
| *** leseb has quit IRC | 23:04 | |
| *** harlowja is now known as harlowja_away | 23:05 | |
| *** bknudson has quit IRC | 23:05 | |
| ayoung | simo, yeah, I know...the length thing is ugly. | 23:07 |
| morganfainberg | simo, yep 32bytes | 23:07 |
| morganfainberg | ayoung, and there is a valid point we shouldn't increase the maximum field side. that has merit | 23:07 |
| ayoung | its longer than 32 chars cuz uuencode or whatever it uses | 23:07 |
| morganfainberg | ayoung, it's 36 bytes atm | 23:08 |
| morganfainberg | ayoung, iirc | 23:08 |
| ayoung | so close... | 23:08 |
| morganfainberg | yeah | 23:08 |
| morganfainberg | if you do an explicit .hex it's 32 bytes | 23:08 |
| morganfainberg | we do .hex | 23:08 |
| morganfainberg | which using .hex removes the '-' which limits expansion due to other encodings (uuencode etc) | 23:09 |
| *** jamielennox|away is now known as jamielennox | 23:10 | |
| morganfainberg | ayoung, so far we have 1 place that expects the size of the user_id to be <= 36 (nova) | 23:10 |
| morganfainberg | and that should be fixed in the nova schema (i'll propose that fix this weekend) to match our schema of 64 | 23:11 |
| jamielennox | ayoung, gyee: auth plugins merged! | 23:12 |
| ayoung | nice | 23:12 |
| *** doddstack has quit IRC | 23:12 | |
| ayoung | so if we go 64...we are still 2 chars short if uuid@@uuid | 23:13 |
| *** browne has quit IRC | 23:22 | |
| gyee | jamielennox, yes, we need them | 23:24 |
| gyee | we need the OS clients to start integrating with it | 23:24 |
| jamielennox | gyee: 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_afk | 23:25 | |
| gyee | jamielennox, that code's pretty solid I think | 23:25 |
| jamielennox | gyee: i generally thing most of my reviews are pretty solid - then we go through 15 odd reviews :) - i'm good with it though | 23:26 |
| *** marcoemorais has joined #openstack-keystone | 23:50 | |
| jamielennox | gyee: and anyone else interested - where do you think is the right place to handle region_name | 23:52 |
| jamielennox | so 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 session | 23:52 |
| gyee | jamielennox, for what, catalog search? | 23:52 |
| jamielennox | gyee: yea, determining an endpoint URL | 23:52 |
| *** dolphm is now known as dolphm_503 | 23:52 | |
| jamielennox | so i've had it as a parameter to the client | 23:52 |
| gyee | jamielennox, go with LDAP search filter style | 23:52 |
| jamielennox | oh? | 23:53 |
| gyee | (&(regionName=abc)(facing=public)) | 23:53 |
| jamielennox | lol, hell no this is python | 23:53 |
| jamielennox | i'm fine with passing region_name=XXX, endpoint_type='public' as kwargs | 23:53 |
| jamielennox | that's not a problem | 23:54 |
| gyee | I was half kidding, but we need a way to pinpoint the endpoint we need | 23:54 |
| gyee | and that's filtering my friend | 23:54 |
| *** marcoemorais has quit IRC | 23:54 | |
| jamielennox | gyee: sure but whilst the only things you can filter on are limited we don't need to worry about that too far | 23:54 |
| gyee | jamielennox, what is an endpoint? | 23:54 |
| gyee | url + metadata | 23:54 |
| *** henrynash has joined #openstack-keystone | 23:55 | |
| gyee | and what's the best way to do lookup? filtering | 23:55 |
| jamielennox | gyee: so i'm cleaning up this one before resubmitting https://review.openstack.org/#/c/60752/ | 23:55 |
| jamielennox | you 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 far | 23:56 |
| jamielennox | eh? | 23:56 |
| jamielennox | here: https://review.openstack.org/#/c/60752/8/keystoneclient/session.py | 23:56 |
| *** marcoemorais has joined #openstack-keystone | 23:56 | |
| gyee | endpoint_type and region_name is not going to be good enough | 23:58 |
| gyee | for now maybe yes, but you want to make it more flexible | 23:58 |
| gyee | service catalog is essentially a tree | 23:59 |
| gyee | you want to have a generic lookup mechanism | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!