| morganfainberg | it's the weekend or i'd write something a bit more in depth in response to the ML, and I'm happy to follow up tomorrow w/ you and the ML if that helps :) | 00:00 |
|---|---|---|
| *** kragniz_ is now known as kragniz | 00:00 | |
| morganfainberg | zigo, i'm not trying rto say we wont go back to auth_fragments, just as of today i would recommend using the non-fragemented version | 00:00 |
| *** markvoelker has joined #openstack-keystone | 00:02 | |
| zigo | morganfainberg: I'm just asking for a friendly warning when this actually happens, nothing more! :) | 00:04 |
| zigo | Anyway, time for me to sleep. | 00:05 |
| morganfainberg | zigo, so - my friendly warning is "it's deprecated" short of putting a comment in the code saying "warn zigo when you remove this" [which is a bit silly right?], what about issuing a deprecation message isn't the warning you're looking for? | 00:05 |
| morganfainberg | zigo, it wont be soon fwiw. | 00:05 |
| zigo | ok, fair enough. | 00:06 |
| morganfainberg | zigo, and we're likely going to have a planned removal of deprecation stuff in client/middleware down the line that should be explicit | 00:06 |
| morganfainberg | zigo, so i'm not saying "tomorrow", i just don't have enough information to set forth a timeline | 00:06 |
| zigo | Ok. | 00:06 |
| morganfainberg | zigo, but unless we reverse course (and i'm willing to talk about that non-weekend time:) ] lets assume it's going away sometime in the future | 00:07 |
| morganfainberg | :) | 00:07 |
| morganfainberg | zigo, sleep well man! catch ya later on | 00:07 |
| *** markvoelker has quit IRC | 00:08 | |
| *** dims_ has quit IRC | 00:12 | |
| *** dimsum__ has joined #openstack-keystone | 00:49 | |
| *** markvoelker has joined #openstack-keystone | 00:52 | |
| *** dimsum__ has quit IRC | 00:54 | |
| *** ncoghlan has joined #openstack-keystone | 00:54 | |
| *** markvoelker has quit IRC | 00:57 | |
| *** bknudson has quit IRC | 01:07 | |
| *** avozza is now known as zz_avozza | 01:44 | |
| *** markvoelker has joined #openstack-keystone | 01:54 | |
| *** markvoelker has quit IRC | 01:58 | |
| *** jacorob has quit IRC | 02:01 | |
| *** jacorob has joined #openstack-keystone | 02:03 | |
| *** jamielennox is now known as jamielennox|away | 02:19 | |
| openstackgerrit | wanghong proposed openstack/keystone: remove assignments when deleting a domain https://review.openstack.org/127433 | 02:25 |
| *** jamielennox|away is now known as jamielennox | 02:27 | |
| *** erkules_ has joined #openstack-keystone | 02:31 | |
| *** erkules has quit IRC | 02:33 | |
| openstackgerrit | Ian Wienand proposed openstack/oslo.policy: Do not log on missing or empty policy_dirs https://review.openstack.org/154742 | 02:43 |
| openstackgerrit | Ian Wienand proposed openstack/oslo.policy: Do not log on missing or empty policy_dirs https://review.openstack.org/154742 | 02:47 |
| *** sluo_wfh has quit IRC | 02:49 | |
| *** sluo_wfh has joined #openstack-keystone | 02:50 | |
| *** markvoelker has joined #openstack-keystone | 02:55 | |
| *** sluo_wfh has quit IRC | 02:55 | |
| *** sluo_wfh has joined #openstack-keystone | 02:56 | |
| *** markvoelker has quit IRC | 03:01 | |
| *** richm has quit IRC | 03:11 | |
| *** markvoelker has joined #openstack-keystone | 03:57 | |
| *** markvoelker has quit IRC | 04:02 | |
| *** jaosorior has quit IRC | 04:11 | |
| *** stevemar has joined #openstack-keystone | 04:17 | |
| *** ChanServ sets mode: +v stevemar | 04:17 | |
| *** BAKfr has quit IRC | 04:32 | |
| *** BAKfr has joined #openstack-keystone | 04:32 | |
| *** BAKfr has quit IRC | 04:37 | |
| *** stevemar has quit IRC | 04:47 | |
| *** BAKfr has joined #openstack-keystone | 04:48 | |
| *** markvoelker has joined #openstack-keystone | 04:58 | |
| *** markvoelker has quit IRC | 05:03 | |
| *** stevemar has joined #openstack-keystone | 05:25 | |
| *** ChanServ sets mode: +v stevemar | 05:25 | |
| *** nikunj2512 has joined #openstack-keystone | 05:32 | |
| nikunj2512 | Hi,... Did _memeber_ role is removed from keystone? | 05:32 |
| *** markvoelker has joined #openstack-keystone | 05:59 | |
| jamielennox | nikunj2512: no, it's still there - or as much as it ever was | 06:03 |
| *** markvoelker has quit IRC | 06:04 | |
| *** ajayaa has joined #openstack-keystone | 06:08 | |
| *** stevemar has quit IRC | 06:20 | |
| *** atmark has joined #openstack-keystone | 06:59 | |
| *** markvoelker has joined #openstack-keystone | 07:01 | |
| *** mflobo has joined #openstack-keystone | 07:04 | |
| *** markvoelker has quit IRC | 07:06 | |
| *** MasterPiece has joined #openstack-keystone | 07:18 | |
| *** ajayaa has quit IRC | 07:30 | |
| *** afazekas_ has joined #openstack-keystone | 07:35 | |
| *** junhongl has quit IRC | 07:40 | |
| *** ajayaa has joined #openstack-keystone | 07:43 | |
| *** chlong has quit IRC | 07:51 | |
| *** nellysmitt has joined #openstack-keystone | 07:53 | |
| *** zz_avozza is now known as avozza | 07:53 | |
| *** amerine has quit IRC | 08:01 | |
| *** markvoelker has joined #openstack-keystone | 08:02 | |
| *** amerine has joined #openstack-keystone | 08:02 | |
| *** markvoelker has quit IRC | 08:07 | |
| *** jistr has joined #openstack-keystone | 08:08 | |
| *** mzbik has joined #openstack-keystone | 08:12 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Implements whitelist and blacklist mapping rules https://review.openstack.org/142573 | 08:31 |
| *** ncoghlan has quit IRC | 08:47 | |
| *** topol has quit IRC | 08:49 | |
| *** openstackgerrit has quit IRC | 08:57 | |
| *** openstackgerrit has joined #openstack-keystone | 08:57 | |
| *** karimb has joined #openstack-keystone | 08:59 | |
| *** jistr has quit IRC | 08:59 | |
| *** markvoelker has joined #openstack-keystone | 09:03 | |
| *** markvoelker has quit IRC | 09:08 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Fix nits from patch #110858 https://review.openstack.org/156158 | 09:09 |
| *** lsmola has joined #openstack-keystone | 09:20 | |
| *** amerine has quit IRC | 09:31 | |
| *** amakarov_away is now known as amakarov | 09:43 | |
| *** obutenko_ has quit IRC | 10:03 | |
| *** sluo_wfh has quit IRC | 10:04 | |
| *** markvoelker has joined #openstack-keystone | 10:04 | |
| *** markvoelker has quit IRC | 10:09 | |
| *** rushiagr_away is now known as rushiagr | 10:23 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Chain a trust with a role specified by name https://review.openstack.org/148642 | 10:38 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Add a domain to federated users https://review.openstack.org/110858 | 10:40 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Make user an object in mapping engine https://review.openstack.org/154934 | 10:40 |
| *** rushiagr is now known as rushiagr_away | 10:40 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Group role revocation invalidates all user tokens https://review.openstack.org/141854 | 10:44 |
| *** aix has joined #openstack-keystone | 10:44 | |
| *** markvoelker has joined #openstack-keystone | 11:05 | |
| *** markvoelker has quit IRC | 11:11 | |
| *** arunkant has quit IRC | 11:18 | |
| *** arunkant has joined #openstack-keystone | 11:23 | |
| *** aix has quit IRC | 11:27 | |
| ajayaa | Hi jamielennox, When is the v2 api being removed? | 11:58 |
| breton | it's not even really deprecated yet, isn't it? | 12:05 |
| *** henrynash has joined #openstack-keystone | 12:07 | |
| *** ChanServ sets mode: +v henrynash | 12:07 | |
| *** henrynash has quit IRC | 12:07 | |
| *** markvoelker has joined #openstack-keystone | 12:08 | |
| ajayaa | breton, I don't know man. | 12:10 |
| *** dimsum__ has joined #openstack-keystone | 12:11 | |
| ajayaa | But I can see the deprecated decorator on keystone v2 controller. | 12:11 |
| *** markvoelker has quit IRC | 12:12 | |
| breton | ajayaa: afaik it does nothing yet | 12:14 |
| ajayaa | agree. Just asking for a guestimate on when v2 is going to be removed. | 12:14 |
| breton | N-cycle I think, if we stick to 2-cycle deprecation. But I'd like to hear an answer too. | 12:16 |
| openstackgerrit | Abhishek Kekane proposed openstack/keystone: Eventlet green threads not released back to pool https://review.openstack.org/130824 | 12:31 |
| *** aix has joined #openstack-keystone | 12:32 | |
| *** henrynash has joined #openstack-keystone | 12:36 | |
| *** ChanServ sets mode: +v henrynash | 12:36 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Fix nits from patch #110858 https://review.openstack.org/156158 | 12:51 |
| marekd | henrynash: ^^ addressed your comments | 12:52 |
| henrynash | marekd: ok…looking | 12:53 |
| henrynash | marked: looks good, thx | 12:54 |
| marekd | henrynash: thank You! | 12:55 |
| *** jaosorior has joined #openstack-keystone | 12:59 | |
| *** hogepodge has quit IRC | 13:03 | |
| *** hogepodge has joined #openstack-keystone | 13:04 | |
| *** dimsum__ is now known as dims | 13:05 | |
| *** dims is now known as Guest70266 | 13:05 | |
| *** markvoelker has joined #openstack-keystone | 13:09 | |
| henrynash | samueldmq: ping | 13:12 |
| *** markvoelker has quit IRC | 13:14 | |
| *** henrynash has quit IRC | 13:19 | |
| *** EmilienM is now known as EmilienM|afk | 13:20 | |
| marekd | dstanek: expert with json-schema? | 13:21 |
| dstanek | marekd: i know a bit about it; definitely no expert | 13:28 |
| dstanek | what's up? | 13:29 |
| marekd | dstanek: I think you and stevemar built some schemas for mapping rules structure. Now I wanted to extend it so the user object is somehow formalized and asked if you know how to quickly make a schema with a logic "user object has either string "id" or (string "name" and object "domain" which has either "name" or "id" inside). | 13:30 |
| *** gordc has joined #openstack-keystone | 13:32 | |
| dstanek | marekd: that will get pretty complicated | 13:32 |
| dstanek | marekd: i think you'll have to define a user object using 'oneOf' to select from your list of definitions - 1 definition will have the id string and the other will have name and domain object | 13:34 |
| *** rushiagr_away is now known as rushiagr | 13:34 | |
| marekd | dstanek: ah, maybe. | 13:34 |
| *** joesavak has joined #openstack-keystone | 13:34 | |
| dstanek | marekd: i can mess with it in a little bit if you get stuck | 13:34 |
| marekd | makes sense. | 13:34 |
| marekd | dstanek: i will bug i I am indeed stuck. | 13:34 |
| marekd | thanks | 13:34 |
| dstanek | marekd: have you seen http://json-schema.org/example2.html ? that's similar to what i was thinking. not exactly, but has the building blocks | 13:35 |
| *** wanghong has quit IRC | 13:36 | |
| *** henrynash has joined #openstack-keystone | 13:42 | |
| *** ChanServ sets mode: +v henrynash | 13:42 | |
| openstackgerrit | Boris Bobrov proposed openstack/keystone: Fix invalid super() usage in memcache pool https://review.openstack.org/154095 | 13:43 |
| *** wanghong has joined #openstack-keystone | 13:44 | |
| *** zzzeek has joined #openstack-keystone | 13:47 | |
| *** Guest70266 is now known as dims__ | 13:48 | |
| *** henrynash has quit IRC | 13:51 | |
| *** nikunj2512 has quit IRC | 13:55 | |
| *** radez_g0n3 is now known as radez | 13:55 | |
| openstackgerrit | Boris Bobrov proposed openstack/keystone: Fix invalid super() usage in memcache pool https://review.openstack.org/154095 | 13:55 |
| breton | dstanek: sorry to waste your +2, but the comments were not the same everywhere | 13:56 |
| *** Nakato has quit IRC | 13:59 | |
| *** Nakato has joined #openstack-keystone | 13:59 | |
| *** markvoelker has joined #openstack-keystone | 14:10 | |
| *** MasterPiece has quit IRC | 14:12 | |
| *** markvoelker has quit IRC | 14:15 | |
| dstanek | breton: haha, no problem | 14:16 |
| *** mzbik has quit IRC | 14:21 | |
| *** afazekas_ has quit IRC | 14:23 | |
| *** markvoelker has joined #openstack-keystone | 14:28 | |
| *** markvoelker has quit IRC | 14:34 | |
| *** afazekas has joined #openstack-keystone | 14:40 | |
| *** ayoung has joined #openstack-keystone | 14:58 | |
| *** ChanServ sets mode: +v ayoung | 14:58 | |
| ayoung | lbragstad, I had a realization last night. The signed portion of the token does not need to have even the scope in it, so long as the scope gets passed back to Keystone to validate. We only need two token formats: regular and federation, with the federation one having the groups lists in it, and the group lists can be unbounded. | 15:00 |
| marekd | ayoung: what do you mean 'unbounded' ? | 15:01 |
| ayoung | the token should only have the absolute minimal amount of data in the signed portion. I think that is userid, issuedat, expiresat, auditid. | 15:01 |
| ayoung | marekd, no maximum number of groups | 15:02 |
| marekd | ayoung: aha. | 15:02 |
| ayoung | marekd, basicall,y the AE token is a proxy for authentication only. | 15:02 |
| ayoung | IE...they really are unscoped tokens. the scoping data can come from a separate channel, namely, the service looking to make a policy decision | 15:03 |
| marekd | ayoung: because all the informatin is 'recreated' every time token is validated? | 15:03 |
| ayoung | groups are necessarily part of the unscoped token | 15:03 |
| ayoung | yes | 15:03 |
| ayoung | and...if we allow for PKI, we get the best of both worlds: | 15:03 |
| openstackgerrit | Alistair Coles proposed openstack/keystonemiddleware: Delay denial when service token is invalid https://review.openstack.org/153247 | 15:04 |
| ayoung | If a service already has the authorization data cached, all the token is giving is a "freshness" check which allows the service to validate the data itself | 15:04 |
| openstackgerrit | Alistair Coles proposed openstack/keystonemiddleware: Delay denial when service token is invalid https://review.openstack.org/153247 | 15:05 |
| ayoung | marekd, it really is no different than the standard corporate setup with Kerberos and LDAP. Kerberos is used merely to give authentication, and the the service does an LDAP lookup to get additional authorization attributes. THat is why Kerberos doesn't need revocation, cuz if you revoke a users rights, it gets removed from LDAP | 15:05 |
| *** carlosmarin has joined #openstack-keystone | 15:16 | |
| *** EmilienM|afk is now known as EmilienM | 15:16 | |
| *** timcline has joined #openstack-keystone | 15:21 | |
| *** timcline has quit IRC | 15:22 | |
| *** marg7175 has joined #openstack-keystone | 15:22 | |
| *** timcline has joined #openstack-keystone | 15:22 | |
| marekd | ayoung: so, from the user perspecitive, the AE fed-tokens will be allowed to grow infititely? | 15:22 |
| *** marg7175 has quit IRC | 15:23 | |
| ayoung | marekd, only in the group field, but yeah. I don't see any ral problem with that. | 15:23 |
| *** marg7175 has joined #openstack-keystone | 15:23 | |
| ayoung | I mean, we can size limit them if it really gets to be a problem, but a problem would be on the neighbor hood of 8k, and we are talking uuid size group here | 15:24 |
| *** ajayaa has quit IRC | 15:25 | |
| ayoung | marekd to the actual token, the part to be validated would be {char[64], int64, int64, char[64],}signature | 15:27 |
| ayoung | and then for fed it would be | 15:27 |
| ayoung | {char[64], int64, int64, char[64], int32 [char[64], .... ] }signature | 15:28 |
| ayoung | for a trust token, it would be | 15:29 |
| ayoung | {char[64], int64, int64, char[64], int32 [char[64], .... ] }signature, `trustid`=char[64] | 15:29 |
| ayoung | and for regular scoped tokens | 15:29 |
| ayoung | {char[64], int64, int64, char[64], int32 [char[64], .... ] }signature, `projectid`=char[64] | 15:29 |
| *** markvoelker has joined #openstack-keystone | 15:31 | |
| *** markvoelker has quit IRC | 15:35 | |
| marekd | ayoung: so, basically these are versioned tokens, and we accept the fact the they may grow. | 15:39 |
| *** thedodd has joined #openstack-keystone | 15:50 | |
| ayoung | marekd, I think so. You OK with that? | 15:50 |
| marekd | ayoung: essentially yes. | 15:51 |
| ayoung | I think the real issue i symmetric versus asym | 15:51 |
| *** nellysmitt has quit IRC | 15:51 | |
| ayoung | I have a few concerns about the symmetric approach | 15:51 |
| *** markvoelker has joined #openstack-keystone | 15:53 | |
| *** abhirc has joined #openstack-keystone | 15:54 | |
| ayoung | dolphm, Since AE tokens are essentially a proxy for authentication, let's move the scoping information outside the signed data. It means we don't have to have multiple token formats to keep the essential part under 255 Bytes. | 15:55 |
| *** nkinder has joined #openstack-keystone | 15:55 | |
| *** jistr has joined #openstack-keystone | 15:58 | |
| *** markvoelker has quit IRC | 15:58 | |
| *** david-lyle_afk is now known as david-lyle | 16:01 | |
| *** thedodd has quit IRC | 16:04 | |
| morganfainberg | ayoung: your comments on AE are now more in line with the -1 typical cycle. Please downgrade your -2 to a -1. I assume we can address the outstanding comments in normal review. My -2 will remain until spfe is granted (or will remain if spfe is not granted) | 16:07 |
| marekd | what;s the k3 deadline? | 16:10 |
| morganfainberg | marekd: sooner than I'd like it to be. | 16:11 |
| marekd | :( | 16:11 |
| marekd | 2015-03-19 ? | 16:12 |
| morganfainberg | In like 2wks | 16:12 |
| morganfainberg | Because we need code ready to gate before the deadline. | 16:12 |
| *** thedodd has joined #openstack-keystone | 16:15 | |
| morganfainberg | ayoung, except scope is an essential part of the token | 16:15 |
| ayoung | morganfainberg, couple things still need to be cleared up. I think that if the token has a signer field in it, we can avoid the keyczar thing as well | 16:15 |
| ayoung | morganfainberg, nah, scope is an essential part of token validation...it can be reconsituted upong validation | 16:16 |
| ayoung | so the keystone server can say "yes, authentication data is OK, and for that scope....yep, here are the roles and the service catalog to go with it." | 16:16 |
| ayoung | morganfainberg, It acatull stemmed from my comment "the only tokens worth keeping are unscoped" | 16:17 |
| morganfainberg | ayoung, can we back way up on the change of architecture | 16:18 |
| morganfainberg | we're not making that shift this cycle. | 16:18 |
| ayoung | If tokens are always validated against Keystone server, we only need the unscoped token. Everything else should be context | 16:18 |
| ayoung | hear me out | 16:18 |
| ayoung | so, we redefine a scoped token to ber | 16:18 |
| ayoung | be | 16:18 |
| morganfainberg | please do not couple this design change across a cycle that has literally 2 weeks left of work left in it for features | 16:18 |
| ayoung | unscoped token + context | 16:18 |
| *** hogepodge has quit IRC | 16:18 | |
| ayoung | it keeps us from having to design a new format for each type of scoped token | 16:18 |
| morganfainberg | your idea is not bad. it is NOT happening in kilo | 16:18 |
| ayoung | it elides the issue with supporting trusts, oauth, etch | 16:19 |
| morganfainberg | it is 100% worth looking at in L | 16:19 |
| ayoung | all that stuff is "additional payload" | 16:19 |
| morganfainberg | we do not have time to redesign tokens in kilo at this level | 16:19 |
| ayoung | just move it outside the signing section, but keep it in the token | 16:19 |
| morganfainberg | so someone could mangle the token (user) and eliminate the trust data out of it? | 16:20 |
| *** hogepodge has joined #openstack-keystone | 16:23 | |
| *** zigo has quit IRC | 16:26 | |
| *** ajayaa has joined #openstack-keystone | 16:30 | |
| *** zigo has joined #openstack-keystone | 16:31 | |
| *** jistr has quit IRC | 16:32 | |
| ayoung | morganfainberg, nah, trusts are not really sensitive data. We treat them that way out of paranoia, but really, anyone should be able to llok at a trust. It needs the authentication paired with it to treat as an assertion | 16:46 |
| ayoung | so there is no difference betweeen uscoped token + trust or a scoped token. | 16:46 |
| *** jimbaker has joined #openstack-keystone | 16:46 | |
| ayoung | They both have the same degree of trustworthiness...If, say, nova passed a token to glance, and that token was unscoped, but also said "here is the trust ID" then glance can go back to Keystone and say "execute this trust for the user and pass me back the roles etc" | 16:47 |
| ayoung | same is reAlly true for the project data. Adding it to the token is just convenient, not necessary | 16:47 |
| openstackgerrit | Merged openstack/oslo.policy: Do not log on missing or empty policy_dirs https://review.openstack.org/154742 | 16:47 |
| morganfainberg | ayoung, the only concern is if that data is changed, do we care? | 16:47 |
| morganfainberg | or is keystone able to say "meh that's ok" or "you can't do that" | 16:48 |
| morganfainberg | i am not sure if we should allow that data to be changed. we could always move it out of the signed data later (or in if we need to) | 16:48 |
| ayoung | morganfainberg, changed by whom? Nova gets the data back from Keystone, and caches it, then passes the token on to glance. for uuid tokens, that means glance has to go and fetch the data from keystone itseklf anyway | 16:48 |
| morganfainberg | ayoung, the end user. | 16:48 |
| ayoung | we are not tlakning a huge document like PKI tokens | 16:48 |
| morganfainberg | or the service that took the token and is acting on your behalf | 16:49 |
| ayoung | morganfainberg, OK...try this thought experiment | 16:49 |
| ayoung | a user has a role on project "demo" | 16:49 |
| ayoung | they go to keystone anr request a token for project demo | 16:49 |
| ayoung | it comes back signeddata+demo | 16:49 |
| ayoung | they edit it, and change demo to admin | 16:49 |
| ayoung | then send it to nova. | 16:49 |
| ayoung | Now nova validates the token | 16:49 |
| ayoung | they send signeddata+admin to Keystone | 16:50 |
| morganfainberg | right. | 16:50 |
| ayoung | What is keystone going to do? | 16:50 |
| ayoung | Use has no roles on project admin | 16:50 |
| morganfainberg | well if it's allowed keystone validates the token | 16:50 |
| morganfainberg | if the user doesn't have roles it rejects | 16:50 |
| ayoung | excatly | 16:50 |
| morganfainberg | it decouples scope | 16:50 |
| ayoung | yes | 16:50 |
| morganfainberg | so do you trust nova not to rescope your token for you? or try? | 16:50 |
| ayoung | morganfainberg, ah..., you mean when Nova sends the token to glance... | 16:51 |
| morganfainberg | or <some service that you are communicating to> | 16:51 |
| morganfainberg | yep | 16:51 |
| ayoung | hmm, good point, the whole "unscoped to sscoped only" thing. | 16:51 |
| morganfainberg | or a MITM attack [more extreme] | 16:51 |
| morganfainberg | yeah, i think i missed saying it in as many words ;) | 16:51 |
| morganfainberg | thanks for working through the thought experiment | 16:52 |
| ayoung | so (damn caps LOCK) | 16:52 |
| ayoung | so this approach would be no worse (but no better) than how we operate today. It would allow for rescoping... | 16:52 |
| ayoung | My thought is this | 16:53 |
| *** markvoelker has joined #openstack-keystone | 16:54 | |
| ayoung | you know how gyee wants tokenless operations? This would let tokenless operations work against anything. You could authenticate with X509 or Kerberos, and then the token would really be nothing more than the scope id. Nova would accept the request, and then say to Keystone, what does userX have on project Y. And uyse that moving forward. But, as You point out, that approach suffers from the same scope creep issue that | 16:54 |
| ayoung | tokens do now | 16:54 |
| ayoung | so...we are back to having specific formats for oauth, trusts, scoped (project and domain) , a Federation unscoped? | 16:55 |
| morganfainberg | haha, caps lock, i want to rip that key off my keyboard | 16:55 |
| ayoung | morganfainberg, I have done it on other keyboards | 16:55 |
| morganfainberg | yeah | 16:56 |
| ayoung | Which means we need a token format field. | 16:57 |
| morganfainberg | well, sortof | 16:57 |
| morganfainberg | but close enough. | 16:58 |
| morganfainberg | i think in L we look at moving this way | 16:58 |
| *** tqtran_afk has joined #openstack-keystone | 16:58 | |
| morganfainberg | especially if we clearly say any data encoded in the enw tokens is considered private, if we need to make internal adjustments | 16:58 |
| morganfainberg | we can | 16:58 |
| ayoung | morganfainberg, I think that, if we do this right, though, we can get to the point I was driving for with PKI tokens. If we can make the key type configuratble (asym versus sym) then a remote site can hold on to the authZ data and validate in process. Tjhat is not a make-or-break, mind you, just where I would like things to head | 16:59 |
| morganfainberg | and it doesn't prevent us from moving the way you're describing. | 16:59 |
| *** markvoelker has quit IRC | 16:59 | |
| morganfainberg | ayoung, yeah i see that as something that this can lead towards | 16:59 |
| morganfainberg | ayoung, i just don't see it as possible to make that big of a shift in K | 16:59 |
| morganfainberg | we have ~2wks left? | 16:59 |
| ayoung | morganfainberg, putting federation and groups aside for a moment, how would we address trust tokens in the current design? | 16:59 |
| morganfainberg | 2.5wks? | 16:59 |
| ayoung | While I don't want to break OAuth, I *can't* break trusts or the Heat team will get all molten on my kiester | 17:00 |
| morganfainberg | ayoung, i think we go with the same thing we do today, encode the data in the token. [a today thing], down the road we can look at alternatives for ensuring that data is there | 17:00 |
| ayoung | morganfainberg, how do we distinguish between a trust token and a non trust token? | 17:01 |
| morganfainberg | we shouldn't break OAuth or Trusts... [and federation is special] | 17:01 |
| morganfainberg | in the AE (to be renamed?) world, i'd use a null field | 17:01 |
| morganfainberg | again for now. | 17:01 |
| ayoung | payload = [auth_type, user_id, project_id, created_at, expires_at, audit_id] | 17:01 |
| morganfainberg | so [expirs, blah, blah, NULL(orTrust), | 17:01 |
| ayoung | make that line: | 17:01 |
| morganfainberg | lbragstad, ^^ cc | 17:02 |
| ayoung | payload = [format, auth_type, user_id, project_id, created_at, expires_at, audit_id] and I think we can then say | 17:02 |
| ayoung | payload = [format1, auth_type, user_id, trust_id, created_at, expires_at, audit_id] and I think we can then say | 17:02 |
| morganfainberg | or we could just fixed field it with a 1byte null. | 17:02 |
| morganfainberg | w/o needing the format id. | 17:02 |
| ayoung | you mean put a type field before project id? | 17:02 |
| morganfainberg | yep. | 17:02 |
| morganfainberg | well, more like just the trust_id | 17:03 |
| ayoung | nah, do it for the whole token, its more flexible | 17:03 |
| morganfainberg | unless you're saying trust_id and oauth_id are the same thing? | 17:03 |
| ayoung | cuz that would not work for the federation multi-groups thing | 17:03 |
| ayoung | they can't be treated the same today, much as I would like them to be | 17:03 |
| morganfainberg | well we have a very narrow set of things we need in the token id (encoded in the payload) | 17:03 |
| morganfainberg | the payload is only relevant inside keystone - | 17:04 |
| ayoung | If it is a difference of one byte, lets put it up front and make it the token format identifier | 17:04 |
| morganfainberg | so we could do [auth_type, user_id, trust_id(ORNULL), oauth(ORNULL), FEDERATION_LIST(orNULL), created, expires, audit] | 17:04 |
| ayoung | easer to check token[0] == FOMATE_CONSTANT | 17:04 |
| *** thedodd has quit IRC | 17:05 | |
| ayoung | actaully, we should put the scope at the end | 17:05 |
| morganfainberg | sure. | 17:05 |
| *** thedodd has joined #openstack-keystone | 17:05 | |
| morganfainberg | as an implementation detail, this is a good case for named tuples | 17:05 |
| ayoung | payload = [format, auth_type, user_id, created_at, expires_at, audit_id, scope] | 17:05 |
| morganfainberg | payload.<attr> | 17:05 |
| ayoung | and then we could move the scoped format to the end...that makes sense | 17:06 |
| ayoung | payload = [auth_type, user_id, created_at, expires_at, audit_id, scope_type, scope] | 17:06 |
| morganfainberg | i'd like to keep the number of formats to manage minimal, but i think that covers the bulk of it | 17:07 |
| ayoung | 0=Unscoped, 1=Project Scoped, 2=Domain Scoped, 3=Trusts Scoped,4=groups scoped (Federation Unscoped) | 17:07 |
| morganfainberg | can't federation be also project scoped? | 17:07 |
| ayoung | nah, that is a standard token | 17:07 |
| ayoung | federation unscoped is where we have the group list. THose get dropped in federation scoped (right marekd ?) | 17:08 |
| morganfainberg | lets be sure on that | 17:08 |
| morganfainberg | but if that is the case, the only thing missing is OAuth. | 17:08 |
| ayoung | morganfainberg, I'm willing to resubmit the spec with those changes. Is that ok? | 17:08 |
| morganfainberg | ayoung, lbragstad said he's working on it right now | 17:09 |
| lbragstad | ayoung: no, I'm working on it currently | 17:09 |
| morganfainberg | ayoung, so before you do coordinate with him. he's looking at the other comments at the same time | 17:09 |
| lbragstad | should have a revision up within the hour | 17:09 |
| ayoung | lbragstad, OK, can you incorporate what we just put up there? scope gets pushed to the end of the token and has a scope_type field in it? | 17:09 |
| ayoung | I would love to see a (signed by) field, too, but that can, in theory, be passed outside the signed data as well, so that can be a Lovelace feature | 17:10 |
| lbragstad | ayoung: reading back | 17:10 |
| morganfainberg | ayoung, yeah i think in Liberty we'll be adjusting how the fields work and improving on the payload so we can be more flexible. this provider definitely does not lock us into too much (which is why it's a good way to solve the big immidiate issues with tokens) | 17:12 |
| ayoung | morganfainberg, has lbragstad, has submitted AE code yet, or just spec? | 17:14 |
| ayoung | https://review.openstack.org/#/c/145317/ | 17:14 |
| lbragstad | ayoung: code has been up for a while https://review.openstack.org/#/c/145317/ | 17:14 |
| ayoung | OK...looking there | 17:14 |
| morganfainberg | ayoung, part of the reason the SPFE is possible is they have [even with the changes needed] most of the work done in the POC code. | 17:15 |
| morganfainberg | ayoung, w/o the POC code, the SPFE wouldn't have been even considered. | 17:15 |
| lbragstad | ok, why put scope_type at the end? | 17:15 |
| lbragstad | with scope? | 17:15 |
| morganfainberg | lbragstad, the thought is trust scoped, federated unscoped, project scoped, domain scoped | 17:16 |
| lbragstad | If anything, I think it should be at the front of the token, that way the KLWT provider can determine what scope type it is, and then pass it to the right formatter | 17:16 |
| lbragstad | right formatter being the one that knows how to handle each scope type | 17:16 |
| morganfainberg | lbragstad, order shouldn't matter too much. | 17:17 |
| lbragstad | it would matter in the provider case | 17:17 |
| *** amerine has joined #openstack-keystone | 17:17 | |
| lbragstad | because the provider shouldn't be verifying all the tokens, | 17:17 |
| morganfainberg | lbragstad, if it's [0], [:] or [:-1], or NAMEDTUPLE().scope_type | 17:17 |
| marekd | ayoung: ayoung https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-a-scoped-os-federation-token nope | 17:17 |
| lbragstad | it should just determine the format than pass it to the right formatter | 17:17 |
| morganfainberg | lbragstad, i'd look at using a named tuple vs. a list here: so you could do payload.scope_type | 17:18 |
| ayoung | lbragstad, actually, that was my initial thought, too. Jsut that the only thing that varies is the scope, the rest of the token data would be unchanged. I don't case so much where it is as that it exists, though | 17:18 |
| morganfainberg | lbragstad, again, order isn't super important as long as we know where to find it. | 17:18 |
| *** tqtran_afk is now known as tqtran | 17:18 | |
| ayoung | morganfainberg, ^^ what marekd just siad there is that only federation unscoped have groups in them | 17:18 |
| morganfainberg | ayoung, awesome. | 17:19 |
| morganfainberg | that makes that waaaay easier | 17:19 |
| marekd | ayoung: no, scoped also has group list. | 17:19 |
| morganfainberg | marekd, thanks! | 17:19 |
| morganfainberg | marekd, ahhh | 17:19 |
| * morganfainberg reads | 17:19 | |
| ayoung | morganfainberg, actually, it would be greoovy if all unscoped tokens had that | 17:19 |
| morganfainberg | ayoung, ^^ | 17:19 |
| ayoung | it would mean assignments would never have to go back to the identity backend | 17:19 |
| marekd | ayoung: morganfainberg lbragstad: https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-a-scoped-os-federation-token | 17:20 |
| lbragstad | so my idea was to have the format (or scope in this case at the front of the token), so each "layer" of the KLWT provider pops of what it needs and then pass the right | 17:20 |
| lbragstad | s/right/rest/ | 17:20 |
| morganfainberg | lbragstad, i don't really care what index the scope_type ends up as. ;) | 17:20 |
| lbragstad | ok | 17:20 |
| ayoung | morganfainberg, that would really aid in the whole "split identity from assignment" effort...def something to comnsider for Loveless. | 17:20 |
| lbragstad | I'll probably keep it in the front then | 17:20 |
| ayoung | Lizardlove | 17:20 |
| ayoung | lbragstad, works for me | 17:21 |
| morganfainberg | lbragstad, my only comment was regarding the namedtuple, since you can reference it as an attr if you want | 17:21 |
| lbragstad | ok | 17:21 |
| morganfainberg | vs. needing the index, but you'd still need to know the index for decoding to named tuple | 17:21 |
| marekd | morganfainberg: ayoung i am thinking if we really need group list in the token. | 17:21 |
| morganfainberg | so.. again, doesn't really matter | 17:21 |
| ayoung | lbragstad, not a deal breaker, but please indicate that either sym or asym crypt can be used to sign the token. I'm a little concerned with the keys distribution issues for the sym case and multiple keystones. Asym much easier. Not a deal breaker, just a good idea | 17:22 |
| ayoung | marekd, yes, we need group lists in the token | 17:22 |
| morganfainberg | ayoung, lets put that on the docket for Liberty to discuss. | 17:22 |
| ayoung | marekd, they should be in unscoped tokens | 17:22 |
| ayoung | morganfainberg, ++ | 17:22 |
| ayoung | morganfainberg, heh, otherwise, we might just have justified the existence of Kite | 17:23 |
| *** _cjones_ has joined #openstack-keystone | 17:23 | |
| morganfainberg | ayoung, hah | 17:23 |
| marekd | ayoung: i meant, that i am wondering if we really need group list in SCOPED token. | 17:23 |
| ayoung | marekd, no, we don't | 17:23 |
| ayoung | marekd, we could put it there, but it would muddy the water | 17:23 |
| morganfainberg | marekd, trying to think if we do.. | 17:23 |
| marekd | ayoung: they already are in scoped token. | 17:24 |
| morganfainberg | i think we do until we can codify no scoped -> scoped token | 17:24 |
| morganfainberg | as the only way forward | 17:24 |
| ayoung | morganfainberg, it would be a different abstraction | 17:24 |
| *** _cjones_ has quit IRC | 17:24 | |
| morganfainberg | ayoung, today i think we need that info for scoped -> scoped | 17:24 |
| *** _cjones_ has joined #openstack-keystone | 17:24 | |
| ayoung | if we have groups specified separate from roles-in-projects it needs to be something managed by Keystone | 17:24 |
| marekd | morganfainberg: cause today we need to be able to do fed-scoped-> fed-scoped ? | 17:24 |
| morganfainberg | marekd, yeah. | 17:24 |
| ayoung | it might be passed throgu hfrom the assertion, but keystone needs to be able to layer additional auth attributes on...way beyond scope here | 17:25 |
| *** timcline has quit IRC | 17:25 | |
| *** tellesnobrega has quit IRC | 17:25 | |
| *** mkoderer has quit IRC | 17:25 | |
| *** mtreinish has quit IRC | 17:25 | |
| *** kibutzz has quit IRC | 17:25 | |
| *** tsufiev has quit IRC | 17:25 | |
| *** ptoohill has quit IRC | 17:25 | |
| *** notmyname has quit IRC | 17:25 | |
| *** rharwood has quit IRC | 17:25 | |
| *** trey has quit IRC | 17:25 | |
| marekd | morganfainberg: ah, se this was for backwards compatibility. | 17:25 |
| ayoung | why fed-scoped to fed-scoped? | 17:25 |
| morganfainberg | ayoung, because we support scoped -> scoped today | 17:25 |
| morganfainberg | it's a compat issue not a "we should do this" | 17:25 |
| ayoung | ah...yeah, lets ignore that | 17:25 |
| ayoung | :) | 17:25 |
| morganfainberg | as we move towards unscoped -> scoped only, then eliminiating that data is more doable | 17:25 |
| morganfainberg | and we should head that way | 17:26 |
| * marekd wonders if fed-scoped -> fed-scoped would even work today... | 17:26 | |
| marekd | morganfainberg: ++ | 17:26 |
| ayoung | morganfainberg, we can't do that today, thogh, can we? We don't have the groups in the scoped tokens, so treat it as a won't-fix-bug | 17:26 |
| *** amerine has quit IRC | 17:26 | |
| marekd | ayoung: federation case or classic? | 17:26 |
| ayoung | federation | 17:26 |
| marekd | ayoung: yes, we do have groups in both unscoped and scoped federation token. | 17:27 |
| ayoung | marekd, we have a future plan to fix | 17:27 |
| ayoung | argh | 17:27 |
| morganfainberg | marekd, we should make sure fed scoped -> fed scoped works | 17:27 |
| morganfainberg | i think someone (lots of people) will be broken without it <today> | 17:27 |
| marekd | morganfainberg: urgs. | 17:27 |
| ayoung | ok...we'll then in a fed AE token, the scope section will have to be projectid groups[] with the project ID being potentially blank...or we have two federation formats | 17:28 |
| morganfainberg | ayoung, also going to rename AE to KLWT | 17:28 |
| morganfainberg | ayoung, i think | 17:28 |
| morganfainberg | keystone lightweight tokens | 17:28 |
| ayoung | KSLT | 17:28 |
| morganfainberg | KSLT? | 17:28 |
| marekd | SuperLightweightTokens? | 17:28 |
| ayoung | Keystone Light Tokens | 17:28 |
| morganfainberg | ha | 17:28 |
| morganfainberg | :) | 17:29 |
| ayoung | morganfainberg, I am concerned that putting a new crypto requirement on Keystone is a more burdensome undertaking than we realize for deployers. I'd like to make PKI the default on the implemenation, with symmetric an option, and maybe the default in Lizardface | 17:30 |
| *** amerine has joined #openstack-keystone | 17:30 | |
| morganfainberg | I'd rather avoid crypto all together. I think you underestimate the burdon of PKI setup | 17:30 |
| *** notmyname has joined #openstack-keystone | 17:31 | |
| morganfainberg | many deployers refused to use PKI because it's a headache to setup. | 17:31 |
| ayoung | morganfainberg, heh, no I do not. Its just that we've forced that issue already | 17:31 |
| morganfainberg | except we haven't really | 17:31 |
| ayoung | and, for them, AE might have the smae issue with symmetric | 17:31 |
| *** timcline has joined #openstack-keystone | 17:31 | |
| *** tellesnobrega has joined #openstack-keystone | 17:31 | |
| *** mkoderer has joined #openstack-keystone | 17:31 | |
| *** mtreinish has joined #openstack-keystone | 17:31 | |
| *** kibutzz has joined #openstack-keystone | 17:31 | |
| *** tsufiev has joined #openstack-keystone | 17:31 | |
| *** ptoohill has joined #openstack-keystone | 17:31 | |
| *** rharwood has joined #openstack-keystone | 17:31 | |
| *** trey has joined #openstack-keystone | 17:31 | |
| amakarov | lbragstad mentioned keyczar in his spec - was it rejected? | 17:32 |
| notmyname | not sure if I missed anything in the netsplit | 17:32 |
| notmyname | if a spec has landed but someone has a questions, how does one make questions or ask for clarification? | 17:32 |
| ayoung | amakarov, it has to be an optional | 17:32 |
| ayoung | keyczar is a Java key management solution | 17:32 |
| ayoung | I've got our crypto guys looking at it | 17:33 |
| ayoung | they just got back from a weeklong Brno conference, so they are a little spent at the moment... | 17:33 |
| morganfainberg | notmyname, ML, ask in IRC, propose a fix to the spec via gerrit covering changes needed to clarify | 17:33 |
| lbragstad | klwt is optional all together | 17:33 |
| notmyname | morganfainberg: ok, thanks. that's great info | 17:33 |
| morganfainberg | :) | 17:33 |
| morganfainberg | notmyname, basically where you'd expect to find information on this stuff | 17:33 |
| morganfainberg | notmyname, and people knowledgable | 17:34 |
| notmyname | right. Iv'e had the question come up a couple of times in swift. "the spec is 'landed', but I have questions. what do I do now" | 17:34 |
| ayoung | lbragstad, ok..I guess it is a non-issue to start, but I suspect that we'll have people looking to use it right out the gate. What is the library that keyczar uses to do its crypto? We don't have a bouncycastle based solution do we? | 17:35 |
| *** vhoward has quit IRC | 17:35 | |
| morganfainberg | notmyname, yeah i think that they're already in the right place asking that | 17:35 |
| amakarov | ayoung, I looked at keyczar and didn't see java port - it looked like a separate python implementation to me... I'll try again. | 17:36 |
| ayoung | amakarov, ? | 17:36 |
| morganfainberg | amakarov, it has java impl | 17:36 |
| morganfainberg | it also has a python impl | 17:36 |
| notmyname | morganfainberg: ya, I just proposed https://review.openstack.org/156291 to answer it for our specs repo | 17:37 |
| morganfainberg | i'm looking at them. now | 17:37 |
| morganfainberg | i think the python impl is isolated / python only, and doesn't require java | 17:37 |
| ayoung | I thought it was a java server. It was my understanding the Python code was just client code...but I could well be wrong. Question still stnads, then? What does keyczar use to do crypto | 17:37 |
| lbragstad | https://code.google.com/p/keyczar/wiki/KeyczarPhilosophy?tm=6 | 17:37 |
| morganfainberg | ayoung, yeah looks like python is standalone as well | 17:37 |
| morganfainberg | pycrypto and pyasn1 it looks like | 17:38 |
| morganfainberg | ayoung, https://code.google.com/p/keyczar/wiki/PythonDependencies | 17:38 |
| ayoung | morganfainberg, then we should look at the python-cryptography | 17:38 |
| ayoung | asn1? interesting | 17:39 |
| lbragstad | https://code.google.com/p/keyczar/source/browse/#git%2Fpython%2Fsrc%2Fkeyczar | 17:39 |
| morganfainberg | https://code.google.com/p/keyczar/source/browse/python/src/keyczar/keys.py#33 | 17:39 |
| lbragstad | looks like there are implementations in cpp, java, and python | 17:39 |
| morganfainberg | pycrypto and if it has M2Crypto it'll use it | 17:39 |
| morganfainberg | hand hmac / hashlib | 17:40 |
| morganfainberg | ugh | 17:40 |
| morganfainberg | SHA1 | 17:40 |
| *** nellysmitt has joined #openstack-keystone | 17:40 | |
| morganfainberg | people are going to complain :( | 17:40 |
| lbragstad | uses pycrypto https://code.google.com/p/keyczar/source/browse/python/src/keyczar/keys.py | 17:40 |
| openstackgerrit | Merged openstack/keystone: fix a small issue in test_v3_auth.py https://review.openstack.org/156040 | 17:40 |
| ayoung | needs to be an optional dependency until we can iron that side out | 17:41 |
| morganfainberg | ayoung, the lib looks sane and is isolated for python only | 17:41 |
| morganfainberg | it just has java and c++ support so you can use the same repo of keys for different apps | 17:41 |
| ayoung | It's called NSS and OpenSSL....they should not be implementing a repo | 17:42 |
| breton | are we ok with it being not actively developed? | 17:42 |
| breton | https://code.google.com/p/keyczar/source/list | 17:42 |
| *** karimb has quit IRC | 17:42 | |
| morganfainberg | i'm thinking it's not a good choice | 17:42 |
| ayoung | Jan 1, 2015 | 17:43 |
| ayoung | He's in Tahoe right now | 17:43 |
| breton | ayoung: yes, but there are commits from 2013 on the first page | 17:43 |
| morganfainberg | breton, does not mean it's not being looked at. | 17:43 |
| morganfainberg | if there are no reported bugs / features to add... i mean | 17:44 |
| morganfainberg | does it need to change? | 17:44 |
| ayoung | I think the right solution lies in us discussing with the Barbican folks driving python-cryptography | 17:44 |
| *** abhirc has quit IRC | 17:44 | |
| *** atiwari has joined #openstack-keystone | 17:45 | |
| morganfainberg | this leads me to believe that the HMAC digests to start are really the right place to focus. | 17:45 |
| lbragstad | ayoung: yes, I'd agree, but I don't know if that support is available right now. | 17:45 |
| ayoung | There are a handful of issues here, locally maitainer the sym key. key distribtuion, | 17:45 |
| ayoung | morganfainberg, can you do HMAC without a private key? | 17:45 |
| ayoung | or without a key at all? | 17:45 |
| morganfainberg | don't we have code for this in openstack already | 17:45 |
| morganfainberg | it's not *great* but i think it's there | 17:46 |
| ayoung | http://en.wikipedia.org/wiki/Hash-based_message_authentication_code | 17:46 |
| morganfainberg | by not great i mean, it's just not feature rich, it's already passed the basic "is this sane" muster | 17:46 |
| ayoung | morganfainberg, HMAC needs a Key. These issues remain whenther we use asym or sym, and whether we encrypt or just sign | 17:46 |
| morganfainberg | right, i think we already have simple HMAC key support in OpenStack | 17:47 |
| morganfainberg | somewhere | 17:47 |
| lbragstad | ayoung: I don't think determining that is a real big issue | 17:47 |
| lbragstad | the current code up for review determines what your key repository is meant to do and initializes a reader object according to the purpose | 17:47 |
| ayoung | lbragstad, Keystone today does not have to deal with symmetric crypto. We can't just say "use Keyczar" without causing a serious ruckas | 17:47 |
| breton | morganfainberg: there are bugs from 2013 that were not addressed at all | 17:48 |
| morganfainberg | breton, like i said it may not be the right choice. | 17:48 |
| breton | https://code.google.com/p/keyczar/issues/detail?id=148 | 17:48 |
| morganfainberg | breton, i'm not for or against keyczar at the moment. | 17:48 |
| *** timcline has quit IRC | 17:48 | |
| ayoung | I would say that we make the HMAC/Signing thing configurable. Provide a PKI solution for people using PKI tokens today and it is still a step forard, with no additional burden. Then, in parallel, we hunt down a symmetric solution | 17:48 |
| lbragstad | ayoung: it's opt in anyway | 17:48 |
| breton | morganfainberg: neither am I, I'm just joining the discussion | 17:49 |
| *** timcline has joined #openstack-keystone | 17:49 | |
| lbragstad | if people don't want to use keyczar, then they can wait until we cut the l release | 17:49 |
| morganfainberg | breton, yeah | 17:49 |
| lbragstad | when we possibly have something else in place | 17:49 |
| ayoung | lbragstad, let me be clear...I am not saying "do this in order for me to remove the -2 on the spec" I only care there about the trusts being support out the gate | 17:49 |
| morganfainberg | lbragstad, there is concern about keyczar, if we see some of these issues will it land in global reqs? | 17:50 |
| ayoung | keyczar can be an optional dependency | 17:50 |
| *** amerine has quit IRC | 17:50 | |
| morganfainberg | lbragstad, if it's not in global reqs we can't rely on it (even "optionally") | 17:50 |
| lbragstad | morganfainberg: ayoung It's already been purposed | 17:50 |
| lbragstad | https://review.openstack.org/#/c/154590/ | 17:50 |
| ayoung | I wonder what that would do on a Centos7 install? My guess is that pycrypto is already supported | 17:50 |
| lbragstad | ayoung: trusts were a target to hit with this from the beginning | 17:51 |
| ayoung | ++ | 17:51 |
| morganfainberg | lbragstad, i advise a backup plan in case pykeyczar can't land in global reqs. | 17:51 |
| morganfainberg | lbragstad, thats all. | 17:51 |
| ayoung | lbragstad, ping me when you get the updated spec up, and I plan on removing the -2 at that point | 17:51 |
| * ayoung asks everyone stop bothering lbragstad so he can write and /me promises to do so, too | 17:51 | |
| morganfainberg | lbragstad, anyway that is a separate issue. will let you get spec done /me has a meeting to jump on | 17:52 |
| marekd | what was used that tests are running on all available CPUs? multipocessing? | 17:52 |
| lbragstad | morganfainberg: let's wait and see what people say on the global-req review | 17:52 |
| morganfainberg | marekd, testrepository (aka testr) + subunit | 17:52 |
| morganfainberg | not sure the core implementation of testr atm | 17:53 |
| marekd | aha. | 17:53 |
| *** hogepodge has quit IRC | 17:53 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 17:53 |
| *** timcline has quit IRC | 17:53 | |
| *** stevemar has joined #openstack-keystone | 17:53 | |
| *** ChanServ sets mode: +v stevemar | 17:53 | |
| *** hogepodge has joined #openstack-keystone | 17:54 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Authenticate local users via federated workflow. https://review.openstack.org/156308 | 17:55 |
| *** markvoelker has joined #openstack-keystone | 17:56 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 17:56 |
| morganfainberg | lbragstad, not sure if you want to rename the file from ae-tokens (and BP, but those can be left fwiw, wont block on that) | 17:57 |
| amakarov | ayoung, can we allow re-authenticate using trust-scoped token? Just a stub returning the very same token? https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication | 17:57 |
| amakarov | It appears many clients need it | 17:57 |
| ayoung | amakarov, hmmm...sounds like a client bug | 17:58 |
| *** raildo has joined #openstack-keystone | 17:58 | |
| amakarov | ayoung, that is the question | 17:58 |
| ayoung | float it past jamielennox (he's asleep right now) | 17:58 |
| amakarov | ayoung, ok, thanks, I'll email him | 17:58 |
| *** markvoelker has quit IRC | 18:01 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 18:01 |
| *** radez is now known as radez_g0n3 | 18:04 | |
| ayoung | lbragstad, downgraded to a -1 | 18:05 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Make user an object in mapping engine https://review.openstack.org/154934 | 18:05 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Authenticate local users via federated workflow. https://review.openstack.org/156308 | 18:06 |
| ayoung | will likely upgrade that once I am done reading it. morganfainberg I assume your -2 stays there as a "not yet ready for a SFE" | 18:06 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Authenticate local users via federated workflow. https://review.openstack.org/156308 | 18:06 |
| *** EmilienM is now known as EmilienM|afk | 18:07 | |
| *** rushiagr is now known as rushiagr_away | 18:11 | |
| *** afazekas has quit IRC | 18:13 | |
| morganfainberg | ayoung, yes my -2 is that | 18:14 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Fix nits from patch #110858 https://review.openstack.org/156158 | 18:17 |
| *** amakarov is now known as amakarov_away | 18:19 | |
| morganfainberg | ayoung, until we confirm the SPFE (either today or tomorrow), my -2 stays | 18:21 |
| ayoung | morganfainberg, so this is why, in the future, I'm proposing everything for backlog | 18:21 |
| morganfainberg | ayoung, ++ and i totally support that | 18:22 |
| morganfainberg | ayoung, i also hope to open spec reviews for Liberty just post m3 | 18:22 |
| morganfainberg | so we have lots of time to get them proposed / ready / moved from backlog over | 18:22 |
| ayoung | going from backlog to release should not happen until it is approved in backlog. No one likes looking at something with a big ole -2 on it | 18:22 |
| ayoung | ++ | 18:22 |
| *** timcline has joined #openstack-keystone | 18:22 | |
| morganfainberg | ayoung, the procedural -2 thing i don't like, but you know it serves a purpose | 18:23 |
| ayoung | yep | 18:23 |
| ayoung | no arguing | 18:23 |
| *** amerine has joined #openstack-keystone | 18:25 | |
| *** timcline has quit IRC | 18:27 | |
| ayoung | lbragstad, made some comments to the spec. Minor stuff, and I am, ready to get behind this | 18:32 |
| ayoung | lbragstad, shout if you have any questions | 18:32 |
| morganfainberg | ayoung, hah. some of your comments were the same as mine | 18:33 |
| lbragstad | ayoung: ok, thanks for the review. Working on refactoring the current code so it's not AE specific, I should be able to look in a bit | 18:33 |
| morganfainberg | lbragstad, also commented, most were similar nits (Can -> will). removal of a dependency, and a little clarification on federated data. | 18:34 |
| ayoung | lbragstad, so...AE changes the division of labor between the persistance andthe token provider...I think that: | 18:35 |
| ayoung | 12. We creat an AE persistance driver | 18:35 |
| ayoung | it will be responsible for repopulating the token data based on the AE data. | 18:35 |
| ayoung | then, validate is pretty much a no-op...any valid reconstituted token is valid | 18:35 |
| morganfainberg | ayoung, oh interesting way to handle that, overload the persistence driver to grab all the data instead of the provider doing it. | 18:36 |
| morganfainberg | ayoung, i was thinking the AE token driver would just not talk to persistence. | 18:36 |
| morganfainberg | ayoung, so it didn't matter what persistence driver you picked. | 18:36 |
| ayoung | morganfainberg, yeah, cuz non of the other drivers need to reconstitute | 18:36 |
| morganfainberg | AE token provider* | 18:36 |
| morganfainberg | since we've narrowed persistence calls down to ~2 places in the provider code (i think) | 18:37 |
| ayoung | the token_ref that you get back from SQL, DOgpie etc has all the data it needs in it. | 18:37 |
| ayoung | With revocation events, the workflow collapses to the same thing: | 18:37 |
| ayoung | get the token from persistance (or reconstitute) then compare with revocation events | 18:38 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Add ``service_providers`` in Service Catalog https://review.openstack.org/152659 | 18:38 |
| marekd | stevemar: ^^ answered your question/concern and rebased the patch | 18:38 |
| *** MasterPiece has joined #openstack-keystone | 18:38 | |
| morganfainberg | ayoung, well persistence driver doesn't reconstitute the token atm. it really just does the store token_id index -> token data | 18:38 |
| marekd | (strage, that gerrit cannot do it automatically, while local git does) | 18:38 |
| morganfainberg | ayoung, or "grab values" from store | 18:38 |
| ayoung | morganfainberg, yeah, but that is what the rest of the code means buy token_ref | 18:39 |
| ayoung | the AE code would be the only one that would have an token ref that is not constituted | 18:39 |
| morganfainberg | ayoung, well sortof, we store the data in the store, but on issue the provider ref is still used | 18:40 |
| morganfainberg | we don't do a .create, .get | 18:40 |
| morganfainberg | ayoung, i think we'd need to push more logic down to persistence from provider to make that happen in issuance | 18:41 |
| morganfainberg | ayoung, or we lift all the non "storage" logic out of persistence (probably the better idea). i think we're still a little mixed up where things go | 18:42 |
| morganfainberg | ayoung, persistence probably should really only be "store data" and "retrive" nothing else. | 18:45 |
| morganfainberg | ayoung, so a provider that doesn't need persistence wont use it. | 18:46 |
| ayoung | If you think about it the AE token stores its data in the assignment, identity, and service catalogbackends | 18:51 |
| morganfainberg | right, today providers do the cross-system talking, so either we need to push some logic down or perhaps remove some token_persistence logic | 18:52 |
| morganfainberg | i'm thinking less work to keep provider as the thing that talks across subsystems like assignment, identty, etc | 18:53 |
| morganfainberg | ayoung, i don't want people to need to configure both the AE provider and the AE persistence [if that make sense], meaning logic would need to be shifted to make ae persistence only | 18:54 |
| morganfainberg | not opposed to it, just something we should be aware of. | 18:54 |
| *** rdo has joined #openstack-keystone | 18:55 | |
| ayoung | If you use PKI or AE tokens, you do not need to persist. With PKI token, you would break the ability to validate based on the Hash, that is all | 18:55 |
| morganfainberg | which is still all provider logic. | 18:56 |
| ayoung | In fact, we could reduce the PKI hash to an AE token body | 18:56 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 18:56 |
| ayoung | with PKI, however, the body is reconstituted from the data in the signed document | 18:56 |
| lbragstad | morganfainberg: ayoung will address comments on those, but wanted to fix the reference to the blueprint. I fix comments in another patch | 18:56 |
| ayoung | ++ | 18:56 |
| morganfainberg | lbragstad, ++ | 18:56 |
| *** markvoelker has joined #openstack-keystone | 18:57 | |
| ayoung | I think what I am stumbling towards is that AE tokens can shortcut the storage process...but lets assume that any form of token can do that...so configuring persistance is separate from format | 18:57 |
| morganfainberg | ayoung, the way i see it is the provider determines if it needs to call persistence or not | 18:58 |
| ayoung | but...with AE and assuming no persistence, we have a new requirement: reconstitute. None of the other forms require that. | 18:58 |
| morganfainberg | ayoung, so with AE it just never calls self._token_provider_api.<method> | 18:58 |
| ayoung | morganfainberg, yep | 18:58 |
| ayoung | I like that | 18:58 |
| morganfainberg | same with pki | 18:58 |
| morganfainberg | pki w/ no persistent store that is :P | 18:59 |
| ayoung | We really should make these different token formats all work alongside each other, instead of assumign it is one global config option. THe global config should just say the preferred format | 18:59 |
| morganfainberg | ayoung, i think thats an L-cycle target, the provider cleanup w/ stevedore is headed that way | 19:00 |
| ayoung | isss POST /auth/token?formate=AE | 19:00 |
| ayoung | formate | 19:00 |
| openstackgerrit | gordon chung proposed openstack/pycadf: cleanup documentation https://review.openstack.org/156333 | 19:00 |
| morganfainberg | formaté | 19:00 |
| ayoung | muscle memory is funny | 19:00 |
| morganfainberg | fö®mætē ? :P | 19:01 |
| *** timcline has joined #openstack-keystone | 19:01 | |
| *** markvoelker has quit IRC | 19:02 | |
| amerine | I just hit an odd issue that I'm failing to solve. | 19:07 |
| amerine | I added a custom config section to keystone.conf | 19:07 |
| amerine | [foo_bar] | 19:07 |
| amerine | When I go to get CONF.foo_bar in my extension.. it cannot find it. | 19:08 |
| amerine | "2015-02-16 11:08:15.497 5168 CRITICAL keystone [-] NoSuchOptError: no such option: foo_bar" | 19:08 |
| morganfainberg | amerine, oslo.config requires options to be registered with the CONF object | 19:08 |
| morganfainberg | amerine, if you don't register the option it wont be available to you | 19:09 |
| amerine | morganfainberg: Ok, I guess that's a step I'm missing. | 19:09 |
| amerine | morganfainberg: How do I register an extensions config options with oslo.config? | 19:09 |
| morganfainberg | amerine, so if you look here: https://github.com/openstack/keystone/blob/master/keystone/common/config.py#L1001 | 19:09 |
| morganfainberg | you'll see the for-loop that registers the file options for keysotne from with that same file | 19:10 |
| *** erkules_ is now known as erkules | 19:11 | |
| *** aix has quit IRC | 19:11 | |
| amerine | morganfainberg: Cool. So perhaps the extensions Manager should register options in CONF? | 19:12 |
| *** timcline_ has joined #openstack-keystone | 19:12 | |
| morganfainberg | amerine, it could do that | 19:12 |
| *** radez_g0n3 is now known as radez | 19:12 | |
| amerine | morganfainberg: Is there are more correct pattern than that? | 19:12 |
| morganfainberg | amerine, well in keystone main configs we don't register options until the .configure method (that for loop i pointed you at) is called | 19:13 |
| morganfainberg | this prevents people from getting options read in before keystone is ready | 19:13 |
| morganfainberg | but - it's hard to say the best option for your extension | 19:13 |
| morganfainberg | since it's not being proposed against upstream | 19:13 |
| amerine | *nods* | 19:14 |
| amerine | We've done a few extensions to change behavior for our keystone systems, this is the first that I've wanted some dynamic-ish configurable behavior. | 19:14 |
| *** timcline has quit IRC | 19:14 | |
| amerine | I'll see if I can collect my thoughts about how mainline could expose better config bindings for extensions. | 19:15 |
| amerine | This is basically wrong http://docs.openstack.org/developer/keystone/extension_development.html#modifying-the-keystone-conf-sample-file without more work | 19:15 |
| *** jsavak has joined #openstack-keystone | 19:15 | |
| morganfainberg | yeah that whole set of documents needs to be update | 19:16 |
| morganfainberg | we have a lot of doc fixes to do this cycle... | 19:16 |
| morganfainberg | will likely happen post M3 | 19:16 |
| morganfainberg | s/M/K | 19:16 |
| *** joesavak has quit IRC | 19:16 | |
| amerine | word. I just assumed I missed some extension hook or something non-obvious. | 19:17 |
| amerine | morganfainberg: Thanks again for the help. | 19:17 |
| *** joesavak has joined #openstack-keystone | 19:17 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 19:19 |
| *** jsavak has quit IRC | 19:20 | |
| *** amerine has quit IRC | 19:22 | |
| *** lhcheng has joined #openstack-keystone | 19:22 | |
| *** amerine has joined #openstack-keystone | 19:23 | |
| *** ajayaa has quit IRC | 19:23 | |
| *** dims__ has quit IRC | 19:25 | |
| *** jhop has joined #openstack-keystone | 19:27 | |
| *** jhop has quit IRC | 19:27 | |
| morganfainberg | lbragstad, in the spec where is the scope info located? | 19:27 |
| morganfainberg | i see scope_type, but not clear on where the scope info is | 19:28 |
| morganfainberg | lbragstad, otherwise i think you're very very close to having all the comments addressed, [then we just have the SPFE convo for tomorrow at the meeting] | 19:29 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 19:29 |
| lbragstad | morganfainberg: addressed ^ | 19:29 |
| morganfainberg | lbragstad, aha | 19:29 |
| morganfainberg | i see it now | 19:29 |
| morganfainberg | lbragstad, looks goot to me. | 19:30 |
| lbragstad | morganfainberg: cool, thanks for reviewing | 19:30 |
| morganfainberg | lbragstad, please make sure there is a topic on the meeting agenda for the SPFE | 19:30 |
| *** samueldmq has joined #openstack-keystone | 19:30 | |
| lbragstad | stevemar: do they sell Keystone Light in Canada? | 19:30 |
| stevemar | lbragstad, nopeee | 19:31 |
| morganfainberg | rodrigods, ^ please make sure there is a topic on the meeting for the SPFE you're requesting | 19:31 |
| stevemar | lbragstad, oh wait, they do, i recognize the logo now http://www.thebeerstore.ca/beers/keystone-light | 19:32 |
| stevemar | it's not very popular | 19:32 |
| lbragstad | stevemar: yeah, I imagine not, I was going to say I'd buy a cold Keystone Light for each person who reviewed the KLWT spec and patch, but on second thought that'd probably deter people from reviewing it | 19:33 |
| morganfainberg | lbragstad, i think i need a -3 if you're doing that. *bleghch* keystone lite is baaaaad beer | 19:34 |
| lbragstad | morganfainberg: lol yeah, it is | 19:34 |
| morganfainberg | lbragstad, minor issue: http://logs.openstack.org/50/130050/31/check/gate-keystone-specs-python27/74a663f/console.html#_2015-02-16_19_34_07_490 line 94 | 19:35 |
| morganfainberg | too long | 19:35 |
| morganfainberg | you need to fix it ;) | 19:35 |
| *** vhoward has joined #openstack-keystone | 19:38 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/130050 | 19:38 |
| *** Ephur has joined #openstack-keystone | 19:39 | |
| *** lhcheng has quit IRC | 19:41 | |
| *** thedodd has quit IRC | 19:44 | |
| *** MasterPiece has quit IRC | 19:49 | |
| *** abhirc has joined #openstack-keystone | 19:51 | |
| *** hrybacki has joined #openstack-keystone | 19:51 | |
| *** hrybacki has left #openstack-keystone | 19:52 | |
| *** thedodd has joined #openstack-keystone | 19:56 | |
| morganfainberg | lbragstad, stevemar, ayoung, dstanek, dolphm, i'm asking for 5 fishbowl sessions and 8 working sessions at the summit - this will give us 5 slots during the summit with nothing booked (on the wed/thurs) and I'm asking for 1 full day for the friday meetup thing | 19:56 |
| morganfainberg | fishbowl = sessions we had in paris | 19:57 |
| morganfainberg | strike that, 10 working sessions | 19:57 |
| dstanek | i like calling them fishbowl - very accurate | 19:58 |
| *** markvoelker has joined #openstack-keystone | 19:58 | |
| morganfainberg | so we'll have 2 less main sessions and a ton more hacking on stuff type sessions | 19:58 |
| morganfainberg | (what we did at the tables / dev lounge) | 19:58 |
| ayoung | 10 working sessions, five targetted, 5 open? | 20:00 |
| morganfainberg | changed it to 4-5 fishbowl (Targeted), 8-10 working | 20:00 |
| morganfainberg | and then it'll be 3-6 with nothing scheduled | 20:01 |
| morganfainberg | likely we will settle on the low end of 4, and 8 is my guess | 20:01 |
| ayoung | sounds good. | 20:01 |
| morganfainberg | but, will bring it up tmorrow in the meeting | 20:01 |
| ayoung | lbragstad, I see why you did that, but... | 20:02 |
| *** markvoelker has quit IRC | 20:03 | |
| ayoung | the scope info is the variable sized data, and should got at the end of the token...for parsing purposes that is the right approach | 20:03 |
| lbragstad | parsing wise it can be at the beginning of the toke too, that's how we do it with the token format | 20:04 |
| *** EmilienM|afk is now known as EmilienM | 20:04 | |
| *** abhirc has quit IRC | 20:05 | |
| ayoung | lbragstad, how about this: instad of calling it scope_type, call it token_format, and then just annotate that the token_format determines the strucutre of the data in the scope section. It gives us the wiggle room to modify other fields in the future if we deem necessary, but keeps the static portion of the token in a fixes size section of the token's signed data | 20:06 |
| lbragstad | ok | 20:06 |
| lbragstad | so | 20:06 |
| *** jsavak has joined #openstack-keystone | 20:06 | |
| lbragstad | KLWT00 - > scoped token | 20:06 |
| lbragstad | KLWT01 -> trust tokens | 20:06 |
| lbragstad | or whatever | 20:06 |
| * morganfainberg tries to wedge the ascii bell character in as a token format identifier | 20:07 | |
| dstanek | morganfainberg: will those hacking sessions be in dedicated space? | 20:07 |
| morganfainberg | (mostly to screw with people) | 20:07 |
| morganfainberg | dstanek, yeah it'll be our space | 20:07 |
| morganfainberg | dstanek, http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html | 20:07 |
| morganfainberg | instead of project pods | 20:08 |
| morganfainberg | we'd have a room (20-40ppl sized) for hacking on stuff | 20:08 |
| *** joesavak has quit IRC | 20:09 | |
| morganfainberg | my hope is we'll have enough stuff to cover the time but not so much that we don't get to visit other projects' sessions | 20:09 |
| morganfainberg | which is why the 4 fishbowl and ~8 working feels a bout right, leaving a good chunk of time to wander around to other projects | 20:10 |
| morganfainberg | or 5/8 split | 20:10 |
| ayoung | lbragstad, yes, exactly...I think that is what we want | 20:12 |
| ayoung | note I really don't have a hard and fast need for the scope at the end, just it feels more correct to have the variable data there | 20:13 |
| *** _cjones_ has quit IRC | 20:15 | |
| *** dims__ has joined #openstack-keystone | 20:25 | |
| *** dims__ has quit IRC | 20:30 | |
| *** joesavak has joined #openstack-keystone | 20:52 | |
| *** jsavak has quit IRC | 20:54 | |
| *** _cjones_ has joined #openstack-keystone | 20:56 | |
| *** markvoelker has joined #openstack-keystone | 20:59 | |
| *** devlaps has joined #openstack-keystone | 21:01 | |
| *** timcline_ has quit IRC | 21:02 | |
| *** timcline has joined #openstack-keystone | 21:03 | |
| *** markvoelker has quit IRC | 21:04 | |
| *** _cjones_ has quit IRC | 21:22 | |
| *** _cjones_ has joined #openstack-keystone | 21:23 | |
| ayoung | jamielennox, I need some input on the unified access info review. Got some time to talk about it? | 21:24 |
| *** amerine has quit IRC | 21:24 | |
| ayoung | stevemar, morganfainberg, BTW, totally agree on the split for https://review.openstack.org/#/c/138519/ as suggested. THanks to both of you for slogging through. I didn't know what this was going to look like until I got close to done with it | 21:26 |
| ayoung | the whole service catalog integration was very illuminating. I need to talk over some details with jamielennox to figure out where different pieces are going to land in the final. | 21:27 |
| *** chuckcarmack has joined #openstack-keystone | 21:31 | |
| jamielennox | ayoung: sure - what's up | 21:31 |
| ayoung | jamielennox, OK..so the data in the token is JSON. It gets converted to dict format | 21:32 |
| ayoung | how much of that are we expected to expose to the end user, versus them working with the auth_context things | 21:32 |
| jamielennox | ayoung: so the problem is that really anything can be exposed - and probably someone is using whatever the current state is | 21:33 |
| jamielennox | the approach i've been taking is to force people up a layer | 21:33 |
| ayoung | I think I managed to keep the format consistent with V3 | 21:33 |
| jamielennox | so don't touch the service catalog at all and use .get_endpoint(...) | 21:33 |
| *** dims__ has joined #openstack-keystone | 21:33 | |
| ayoung | the service catalog stuff work, I think, though I copied the classes | 21:33 |
| jamielennox | that way i'm the only one that has to deal with the crappy interface | 21:33 |
| ayoung | I was wondering if I needed to keep the JSON specific versions | 21:33 |
| * ayoung 's mouse cursor has dissappears | 21:34 | |
| *** dims_ has joined #openstack-keystone | 21:34 | |
| ayoung | Ah...there it is... | 21:34 |
| jamielennox | ayoung: i've been of the opinion that if we used to have it we have to keep it | 21:34 |
| jamielennox | it's amazing some of the internals from keystoneclient people rely on | 21:34 |
| ayoung | yeah...I think that my approach will only work for V3 and later, but we are looking at deprecating V2.0. It is an argument against a drop in replacement | 21:35 |
| jamielennox | because we also make the AccessInfo object available to people via keystonemiddleware | 21:35 |
| jamielennox | so that whole interface is now poluting other peoples code as well | 21:35 |
| ayoung | I would think we would see major explosions in the gate if I broke something | 21:36 |
| ayoung | but check passed.... | 21:36 |
| *** lhcheng has joined #openstack-keystone | 21:37 | |
| ayoung | jamielennox, for the most part, what you get from parsing and then using the python objects is not much different than you get parsing the JSON directly, so I would expect those kind of things to work | 21:38 |
| *** dims__ has quit IRC | 21:38 | |
| jamielennox | so for better or worse the problem with the gate is that it's running the latest code | 21:38 |
| jamielennox | there are a whole bunch of things in ksc that i've wanted to fix, and have fixed in dependent clients | 21:39 |
| jamielennox | however using the old dependent and the new ksc would break | 21:39 |
| ayoung | jamielennox, I was wondering if we had a case where someone used token data to directly constitute a service catalog object. If so, I don't think that we can remove the old classes | 21:39 |
| jamielennox | ayoung: i've never seen it | 21:39 |
| jamielennox | i think cinder used to use our catalog directly, but i've fixed that up | 21:40 |
| ayoung | Ideally, I would make a first pass that just adjusted the tests, and showed that they worked with the existing access-info | 21:40 |
| ayoung | I had to drop a couple places that checked which subclass of AccessInfo (V2, V3) was created, as there is a unified one now | 21:40 |
| jamielennox | ayoung: i think the goal would be to not adjust the tests, show that the new stuff still works with the way it used to be accessed | 21:41 |
| ayoung | https://review.openstack.org/#/c/138519/11/keystoneclient/service_catalog.py,cm is mostly cut and paste code, but I could drop a lot of it if I can drop the old | 21:41 |
| ayoung | jamielennox, well that is the goal, but some of the tests are too specific, l;ike I pointed out. Which subclass is the most obvious one | 21:41 |
| ayoung | let me see what else I touched. I might be able to reverse some of those hacks no | 21:42 |
| ayoung | now | 21:42 |
| ayoung | I had to make changes like this: | 21:43 |
| ayoung | https://review.openstack.org/#/c/138519/11/keystoneclient/tests/unit/v3/test_tokens.py,cm | 21:43 |
| ayoung | these time tests are spooky https://review.openstack.org/#/c/138519/11/keystoneclient/tests/unit/v3/test_access.py,cm | 21:43 |
| dims_ | howdy all, we have a candidate looking to work on keystone for GSoC 2015, all through summer. Anyone interested in being a mentor? | 21:44 |
| *** jsavak has joined #openstack-keystone | 21:44 | |
| ayoung | I'm guessing the formats in the wrapper are wrong. THat test should go through unmodified | 21:44 |
| ayoung | also, the whole "assertNotIn" logic is kindof strange. | 21:45 |
| ayoung | jamielennox, also, I think we can finally drop the tests for diablo tokens, as we no longer have to support those, or are we still on the hook? | 21:46 |
| jamielennox | dims_: i think most of the US based folks have gone by this time | 21:47 |
| *** joesavak has quit IRC | 21:47 | |
| jamielennox | dims_: we have a meeting tomorrow UTC 1800 i think - that would be your best time to ask | 21:48 |
| dims_ | jamielennox: thanks will ask again tomorrow | 21:48 |
| dims_ | thanks | 21:48 |
| ayoung | dims_, depends. Do I get to set her/his design agenda? | 21:48 |
| jamielennox | run! | 21:48 |
| jamielennox | :) | 21:48 |
| dims_ | ayoung: yep | 21:49 |
| jamielennox | dims_: if you want to do that pop it on the agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting | 21:49 |
| ayoung | oooh | 21:49 |
| dims_ | jamielennox: thanks will do | 21:49 |
| jamielennox | about to have a power outage | 21:53 |
| jamielennox | back soon | 21:53 |
| *** chuckcarmack has left #openstack-keystone | 21:54 | |
| mfisch | are the LDAP connection pools pretty well baked? | 21:54 |
| mfisch | ready for prod anyway? | 21:54 |
| stevemar | gordc, thanks for releasing pycadf | 21:55 |
| samueldmq | for anyone interested in gsoc, fell free to join #openstack-gsoc :) | 21:55 |
| samueldmq | I am a candidate to mentor a project for keystone | 21:56 |
| gordc | stevemar: i forgot it was family day. | 21:56 |
| stevemar | gordc, do you get it in qc? | 21:57 |
| gordc | another holiday missed :( | 21:57 |
| gordc | we get jack... | 21:57 |
| lbragstad | ayoung: can you ever have an unscoped trust token? | 21:58 |
| ayoung | lbragstad, nope | 21:58 |
| ayoung | a trust token is explicitly scoped. | 21:58 |
| stevemar | gordc, womp womp... | 21:58 |
| lbragstad | so by the time the calls gets into the provider, it should *always* have a project_id | 21:58 |
| ayoung | we check on a trust creation that it has at least one role assigned to it | 21:59 |
| lbragstad | ok | 21:59 |
| ayoung | yes | 21:59 |
| lbragstad | ayoung: thanks | 21:59 |
| gordc | stevemar: indeed | 21:59 |
| ayoung | lbragstad, you working on a clever way to represent tokens, dividing scoped from unscoped? | 21:59 |
| stevemar | gordc, woke up at noon, haven't checked my email til now, it's been glorious | 21:59 |
| lbragstad | ayoung: no, not yet. Trying to keep it simple | 21:59 |
| gordc | stevemar: you have already worked too hard. | 22:00 |
| ayoung | lbragstad, I think we could, in theory, merge unscoped and federation unscoped into a single format | 22:00 |
| ayoung | a standard unscoped would have no groups | 22:00 |
| ayoung | but it might be worthwhile from a processing perspective to keep those as two separate types | 22:00 |
| *** markvoelker has joined #openstack-keystone | 22:01 | |
| *** aix has joined #openstack-keystone | 22:02 | |
| *** raildo has quit IRC | 22:03 | |
| *** jamielennox is now known as jamielennox|away | 22:03 | |
| *** jsavak has quit IRC | 22:05 | |
| *** markvoelker has quit IRC | 22:05 | |
| *** jamielennox|away is now known as jamielennox | 22:14 | |
| *** samueldmq has quit IRC | 22:14 | |
| morganfainberg | stevemar, ping | 22:18 |
| *** abhirc has joined #openstack-keystone | 22:22 | |
| stevemar | morganfainberg, pong | 22:23 |
| openstackgerrit | Steve Martinelli proposed openstack/oslo.policy: Use single quotes consistently https://review.openstack.org/156404 | 22:27 |
| openstackgerrit | Steve Martinelli proposed openstack/oslo.policy: Fix minor spelling issues in oslo.policy https://review.openstack.org/156405 | 22:27 |
| *** nellysmitt has quit IRC | 22:37 | |
| *** nellysmitt has joined #openstack-keystone | 22:38 | |
| *** nellysmitt has quit IRC | 22:42 | |
| morganfainberg | jamielennox, crud forgot to release -kerberos | 22:43 |
| morganfainberg | jamielennox, will do tomorrow ok? | 22:44 |
| morganfainberg | or tonight | 22:44 |
| jamielennox | morganfainberg: sure | 22:46 |
| *** afazekas has joined #openstack-keystone | 22:47 | |
| *** dims_ has quit IRC | 22:51 | |
| *** dims__ has joined #openstack-keystone | 22:51 | |
| *** ayoung has quit IRC | 22:52 | |
| *** darrenc is now known as darrenc_afk | 22:55 | |
| lbragstad | random trust question time! in this example https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst#consuming-a-trust what does e80b74 represent? | 22:55 |
| lbragstad | a token ID? | 22:55 |
| lbragstad | given that i want to consume the trust | 22:55 |
| *** afazekas has quit IRC | 23:01 | |
| *** markvoelker has joined #openstack-keystone | 23:02 | |
| *** markvoelker has quit IRC | 23:07 | |
| jamielennox | lbragstad: token for rescoping | 23:08 |
| jamielennox | lbragstad: it would be the same as providing an exisitng token to be rescoped to a project | 23:08 |
| *** chlong has joined #openstack-keystone | 23:09 | |
| *** timcline has quit IRC | 23:10 | |
| lbragstad | so, you pass the trust id as the token? | 23:11 |
| lbragstad | jamielennox: so like http://pasteraw.com/hf6kybsq02p2asjcvnceov97i7qjp2v ? | 23:12 |
| lbragstad | or would token['id'] be the unscoped token? | 23:12 |
| jamielennox | lbragstad: the unscoped token | 23:12 |
| lbragstad | ahh... | 23:12 |
| lbragstad | got it | 23:12 |
| lbragstad | jamielennox: thanks! | 23:12 |
| jamielennox | lbragstad: np | 23:13 |
| *** darrenc_afk is now known as darrenc | 23:17 | |
| *** afazekas has joined #openstack-keystone | 23:30 | |
| *** dims_ has joined #openstack-keystone | 23:30 | |
| *** dims__ has quit IRC | 23:32 | |
| *** gordc has quit IRC | 23:32 | |
| *** henrynash has joined #openstack-keystone | 23:34 | |
| *** ChanServ sets mode: +v henrynash | 23:34 | |
| henrynash | dstanek: you around? | 23:46 |
| *** dims__ has joined #openstack-keystone | 23:47 | |
| *** dims_ has quit IRC | 23:47 | |
| dstanek | henrynash: yes | 23:49 |
| henrynash | dstanek: so I’m experimenting with how we might break up all our “backend” tests… | 23:49 |
| *** thedodd has quit IRC | 23:49 | |
| henrynash | dstanek: and was imagining we might have something like backend/role/core, backend/role/sql | 23:50 |
| *** richm has joined #openstack-keystone | 23:50 | |
| henrynash | dstanek: and then backend/assignment/core + sql + ldap etc. | 23:50 |
| henrynash | although not quite sure if we can make tox/testr run one of those tests on demand | 23:51 |
| henrynash | dstanek: I don’t think I can say tox — backend/role/sql for instance | 23:51 |
| henrynash | dstanek: thoughts? | 23:52 |
| henrynash | (this is all within unit, of course) | 23:52 |
| henrynash | dstanek: ahhh…but I think tox — backend.role.test_sql would work… | 23:54 |
| *** dims__ has quit IRC | 23:56 | |
| *** dims_ has joined #openstack-keystone | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!