| ayoung | no | 00:00 |
|---|---|---|
| ayoung | OS_USER_ID=cloudadmin | 00:00 |
| telemonster | ohh | 00:00 |
| ayoung | you set the USERNAME to the cn field, remember? | 00:00 |
| telemonster | gotcha fixing | 00:01 |
| ayoung | coo | 00:01 |
| telemonster | keystone token-get | 00:02 |
| telemonster | Expecting a username provided via either --os-username or env[OS_USERNAME] | 00:02 |
| *** lhcheng_ has quit IRC | 00:04 | |
| telemonster | I think it uses the first one on the backend to resolve the common name then reuses the common name over and over for queries | 00:04 |
| ayoung | telemonster, do you need to use CN? | 00:05 |
| ayoung | for now, just set both user_id and username to use sAMAccountName | 00:05 |
| telemonster | put_filter: "(&(sAMAccountName=OpenStack Admin)(objectClass=person))" | 00:05 |
| telemonster | I see that coming up now, with those two reversed | 00:05 |
| telemonster | I don't know that I care that much about the cn | 00:06 |
| *** david-lyle is now known as david-lyle_afk | 00:06 | |
| telemonster | I can change both to sAMA or forgo one? | 00:06 |
| ayoung | you can change both to sAMAccountName | 00:06 |
| *** stevemar has joined #openstack-keystone | 00:07 | |
| *** ChanServ sets mode: +v stevemar | 00:07 | |
| telemonster | doing that now, I know that causes existing config to not allow login but maybe with other settings | 00:07 |
| telemonster | 1 sec | 00:07 |
| ayoung | when you login, you'll need to log in with the sAMAccountName value, not the CN value, which might mess up your users. But lets get things working before we break them again | 00:08 |
| telemonster | our users log in wiht the sAMAccount name | 00:08 |
| telemonster | all the time | 00:08 |
| telemonster | did you want me to use OS_USERNAME or OS_USER_ID ? | 00:08 |
| *** jorge_munoz has left #openstack-keystone | 00:09 | |
| ayoung | telemonster, set OS_USERNAME=cloudadmin | 00:09 |
| ayoung | that is the value in sAMAccountName, right? | 00:10 |
| telemonster | yes | 00:10 |
| telemonster | and it fails | 00:10 |
| telemonster | the only case it works is with the id cn and user sAMA IIRC | 00:10 |
| ayoung | hold on | 00:11 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Allow loading other auth methods in auth_token https://review.openstack.org/129552 | 00:11 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Split identity server into v2 and v3 https://review.openstack.org/130534 | 00:11 |
| telemonster | 1 sec | 00:11 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Additional discovery changes https://review.openstack.org/130533 | 00:11 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Use real discovery object in auth_token middleware. https://review.openstack.org/130532 | 00:11 |
| jamielennox | bknudson: i can't do one of the comments in that set ^. If you have a look at them as a whole they are a staged refactoring. I could probably compress them all into one patch and it would be ok it's just a lot of changes to grok that way | 00:12 |
| ayoung | telemonster, ok, so make sure the OS_TENANTNAME and the rest are all unset. | 00:12 |
| ayoung | Make sure that we are limiting things to doing an unscoped token | 00:12 |
| telemonster | let me back out and retry | 00:13 |
| telemonster | export OS_USERNAME=cloudadmin | 00:14 |
| telemonster | export OS_AUTH_URL=http://10.100.29.101:35357/v2.0/ | 00:14 |
| telemonster | and the pass | 00:14 |
| telemonster | keystone token-get | 00:14 |
| telemonster | The request you have made requires authentication. (HTTP 401) | 00:14 |
| telemonster | If I revert the id/name things it will work. I think the ldap thing uses the sAMAccountName first to resolve the cn, then does a number of queries using the cn | 00:15 |
| telemonster | hmmm on console I see this: | 00:16 |
| telemonster | put_filter: "(&(sAMAccountName=OpenStack Admin)(objectClass=person))" | 00:16 |
| telemonster | It's not in the first request but it's wrong | 00:16 |
| *** r-daneel has quit IRC | 00:17 | |
| ayoung | what is in your ldap config file for the user_id_attribute and user_name_attribute? They should both say sAMAccountName. If they do, the my guess is that OpenStack Admin is getting sent by mistake across the wire. Nothing should be looking at the CN field | 00:18 |
| ayoung | you suire you don | 00:18 |
| ayoung | you sure you don't have the cn field set further down the config, and it is over writing the sAMAccountName value? | 00:19 |
| telemonster | the cn field is in there a number of times | 00:19 |
| telemonster | 1 sec | 00:19 |
| telemonster | user = "CN=AD Bind,OU=Service Accounts,OU=User Accounts,DC=int,DC=aopslab,DC=com" | 00:20 |
| telemonster | user_objectclass = person | 00:20 |
| telemonster | user_id_attribute = sAMAccountName | 00:20 |
| telemonster | user_name_attribute = sAMAccountName | 00:20 |
| telemonster | user_enabled_attribute = userAccountControl | 00:20 |
| telemonster | user_enabled_mask = 2 | 00:20 |
| telemonster | user_enabled_default = 512 | 00:20 |
| telemonster | thats it, no other cn references... because they're all remarked out | 00:21 |
| telemonster | we had a group section for narrowing things down but in the process of elimination it's remarked out | 00:21 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Use newer requests-mock syntax https://review.openstack.org/135468 | 00:22 |
| *** ncoghlan has joined #openstack-keystone | 00:23 | |
| *** RichardRaseley has quit IRC | 00:24 | |
| telemonster | are both id and name needed? | 00:25 |
| ayoung | yeah, both are used, but that should be OK | 00:26 |
| ayoung | the user line seems strange | 00:26 |
| ayoung | user = "CN=AD Bind,OU=Service Accounts,OU=User Accounts,DC=int,DC=aopslab,DC=com" | 00:27 |
| ayoung | that is the admin user... | 00:27 |
| telemonster | no | 00:27 |
| ayoung | and that is done by DN....ok | 00:27 |
| telemonster | thats just a bind account for the lookups | 00:27 |
| ayoung | the right that is what I meant | 00:27 |
| ayoung | telemonster, can you do a simple bind using sAMAccountName for a user? | 00:28 |
| telemonster | if taht is wrong its ldap permission denied | 00:28 |
| *** marcoemorais has quit IRC | 00:28 | |
| *** marcoemorais has joined #openstack-keystone | 00:28 | |
| telemonster | I dont think so, the bind account is prob different | 00:28 |
| telemonster | AD is different in that it doesn't allow random binds | 00:28 |
| *** marcoemorais has quit IRC | 00:28 | |
| *** marcoemorais has joined #openstack-keystone | 00:29 | |
| ayoung | telemonster, that might be the issue. I'm not an AD expert | 00:29 |
| ayoung | and my AD expert is missing | 00:29 |
| telemonster | Nope, that part is good. If I dork that up it will fail to even try a user/pass | 00:30 |
| *** stevemar has quit IRC | 00:30 | |
| telemonster | the sAMA part, with both set to sAMA (the short name) in the logs from console I can see the LDAP part is reverting to trying to use the sAMA as teh cn and that I don't think will work | 00:31 |
| telemonster | thats why I get invalid password when both are set to sAMAccount and try to login via web or key request via cli | 00:31 |
| morganfainberg | lbragstad, i see you've convinced ayoung AE isn't bad! | 00:31 |
| morganfainberg | :) | 00:32 |
| morganfainberg | ayoung, AD? | 00:33 |
| telemonster | Active Directory | 00:33 |
| morganfainberg | no i was wondering what was going on w/ it | 00:33 |
| morganfainberg | telemonster, i'm reading the backscroll | 00:34 |
| openstackgerrit | Merged openstack/keystone-specs: Token Provider Cleanup Spec https://review.openstack.org/134314 | 00:34 |
| openstackgerrit | Merged openstack/keystone-specs: Update headers slightly for API specification(s) https://review.openstack.org/133816 | 00:34 |
| morganfainberg | telemonster, a lot of ADs will use the email name for binding ... i don't remember what that mode is called... Principal bind? | 00:35 |
| morganfainberg | i know i had to support that around a bunch of custom AD code a long while ago (custom openstack/keystone development) | 00:35 |
| morganfainberg | the point was i had to bind with the principal name not the CN/DN | 00:36 |
| telemonster | Ah. Not sure, we have a bind account or two. The bind part is working, and I've had it passing the user/pass no problems but then there are issues with the project permissions | 00:36 |
| morganfainberg | ah | 00:36 |
| morganfainberg | so identity is backed by AD? | 00:36 |
| telemonster | It comes back with a no project permissions error from web ui | 00:36 |
| morganfainberg | and assignment is in SQL? | 00:36 |
| telemonster | the user/pass/group comes from AD, then the projects and tenants and stuff are in SQL | 00:36 |
| morganfainberg | right | 00:37 |
| morganfainberg | ok | 00:37 |
| telemonster | only using AD for basic auth | 00:37 |
| morganfainberg | *phew* | 00:37 |
| morganfainberg | i was going to get scared ;) | 00:37 |
| telemonster | WE're not a microsoft shop by any means, but for whatever reason auth against AD. | 00:37 |
| morganfainberg | eh, i know a bunch of places like that | 00:37 |
| morganfainberg | AD has a lot of nice featured tbh | 00:37 |
| morganfainberg | i think 3 of my 5 past eployers were like that | 00:38 |
| telemonster | It needs an inspector ability to watch queries against AD live :-) Trying to troubleshoot it isn't much fun | 00:38 |
| telemonster | The microsoft way seems to be DLL replacements that allow snooping client side. | 00:38 |
| morganfainberg | oh god | 00:39 |
| morganfainberg | ouch | 00:39 |
| morganfainberg | my brain hurts now | 00:39 |
| morganfainberg | have you given a grant specifically to the user in question or only the user's group? | 00:40 |
| morganfainberg | because - I wonder if the group is being resolved incorrectly | 00:40 |
| *** raildo_ has joined #openstack-keystone | 00:40 | |
| morganfainberg | AD *can* do groups different than normal LDAP | 00:41 |
| gyee | you can use ldapsearch to hit AD | 00:41 |
| telemonster | ldap search came back fine, and this config was running in production on possibly an older havana install for about a year | 00:41 |
| morganfainberg | telemonster, gyee also is *really* good at LDAP stuff (gyee see what i did there :P ) | 00:41 |
| morganfainberg | and in icehouse it broke? | 00:41 |
| morganfainberg | i'm getting the feeling this is related to some of the attribute fetch fixes that were backported | 00:42 |
| gyee | member versus memberOf? | 00:42 |
| morganfainberg | gyee, possibly | 00:42 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Remove string from URL in list_revoke_events() https://review.openstack.org/130408 | 00:42 |
| morganfainberg | we had a big rewrite of LDAP stuff | 00:42 |
| telemonster | morgan - yes, on the RDO version of icehouse the user/pass part didnt work. i grabbed from git the latest core.py from ldap and threw it over it and all of a sudden it would pass the user/pass auth part and fail somewhere else | 00:43 |
| telemonster | coworkers reverted to havana to hopefully get past it (the goal is to get production back running) and we've hit the same issue | 00:43 |
| *** oomichi has joined #openstack-keystone | 00:43 | |
| morganfainberg | wait, so suddenly havana has the same issue? | 00:43 |
| rodrigods | dstanek, ^ addressed your comment there | 00:43 |
| ayoung | telemonster, keystone does a simple bind to authenticate the user | 00:44 |
| morganfainberg | i am going to call shenanigans then. either the config has changed or *something* related to the AD server and directory has changed. | 00:44 |
| telemonster | this version of havana that my coworkers installed does not work with the prior existing config. However, it may have been set up slightly differently or the values in the tables might have been changed | 00:44 |
| telemonster | Im trying to get the basic admin role abilityt o log into it authing via ldap | 00:44 |
| gyee | you pulling groups from AD too? | 00:44 |
| ayoung | telemonster, the first thing I would try to resolve is what do you need to do to get a simple bind working for the cloudadmin user | 00:44 |
| telemonster | it might be the fields in the DB table for admin or some other role issue, not sure | 00:44 |
| raildo_ | morganfainberg, do you have some minutes to review this patch? :) https://review.openstack.org/#/c/134095/ (that is not related to HM hahaha) | 00:45 |
| telemonster | the bind part works | 00:45 |
| ayoung | telemonster, for clouduser? | 00:45 |
| morganfainberg | raildo_, yes i do. | 00:45 |
| raildo_ | morganfainberg, thanks | 00:45 |
| telemonster | I can get that sAMAccountName with the proper vlaue and the CN for proper value, it just fails on belonging to a tenant | 00:45 |
| dstanek | rodrigods: cool, I'll take a look after dinner | 00:45 |
| morganfainberg | raildo_, let me finish this convo w/ telemonster then i'll look | 00:45 |
| raildo_ | morganfainberg, np | 00:45 |
| morganfainberg | raildo_ it's in a window waiting to be looked at before i click anywhere else | 00:45 |
| ayoung | telemonster, um...what are you using for your assignment backend? | 00:45 |
| morganfainberg | ayoung, SQL i asked | 00:46 |
| morganfainberg | ok so based on this my guess is that somehow the grant is not matching the data returned from AD-LDAP | 00:46 |
| telemonster | yup | 00:47 |
| morganfainberg | mismatch of DN vs CN vs SOMETHINGELSE? | 00:47 |
| ayoung | what was the table for that in Havana again? | 00:47 |
| morganfainberg | ayoung, uh... user_project_something? | 00:47 |
| ayoung | Heh...we all clueless | 00:47 |
| morganfainberg | sec. | 00:47 |
| ayoung | if it ain't icehouse or later.... | 00:47 |
| telemonster | | user_domain_metadata | | 00:47 |
| telemonster | | user_group_membership | | 00:47 |
| telemonster | | user_project_metadata | | 00:47 |
| ayoung | user_project_metadata | 00:48 |
| morganfainberg | see i was closE! | 00:48 |
| morganfainberg | metadata! | 00:48 |
| morganfainberg | haha | 00:48 |
| * morganfainberg hides in the corner before being mocked more about not knowing. | 00:48 | |
| ayoung | select * from user_project_metadata where userid = 'cloudadmin'; | 00:48 |
| *** alex_xu has joined #openstack-keystone | 00:48 | |
| gyee | telemonster, select * from user_project_metadata where actor_id = 'clouseradmin' | 00:48 |
| ayoung | or user_id | 00:48 |
| ayoung | gyee, actor_id? | 00:48 |
| morganfainberg | gyee, thats Juno | 00:48 |
| morganfainberg | isn't it | 00:48 |
| gyee | Juno? I thought they are running Havana | 00:48 |
| telemonster | there is no actor_id | 00:48 |
| ayoung | I think that was the name we picked for the unified assignment table, but it was user_id in Havana | 00:48 |
| morganfainberg | "actor_id" i think that is a juno thing | 00:49 |
| telemonster | This is havana | 00:49 |
| *** chrisshattuck has quit IRC | 00:49 | |
| ayoung | No. THIS IS SPARTA! | 00:49 |
| ayoung | sorry | 00:49 |
| gyee | haha | 00:49 |
| ayoung | so, yeah,. user_id | 00:49 |
| gyee | telemonster, desc user_project_metadata | 00:49 |
| morganfainberg | user_id = sql.Column(sql.String(64), primary_key=True) | 00:49 |
| morganfainberg | gyee, https://github.com/openstack/keystone/blob/havana-eol/keystone/assignment/backends/sql.py#L732-L737 | 00:49 |
| ayoung | telemonster, select * from user_project_metadata where userid = 'cloudadmin'; | 00:50 |
| ayoung | if that does not return anything, then try it with | 00:50 |
| telemonster | | Field | Type | Null | Key | Default | Extra | | 00:50 |
| telemonster | +------------+-------------+------+-----+---------+-------+ | 00:50 |
| telemonster | | user_id | varchar(64) | NO | PRI | NULL | | | 00:50 |
| telemonster | | project_id | varchar(64) | NO | PRI | NULL | | | 00:50 |
| telemonster | | data | text | YES | | NULL | | | 00:50 |
| morganfainberg | ayoung, i'd go select * from user_project_metadata where userid like '%cloudadmin%'; | 00:50 |
| gyee | ah | 00:50 |
| ayoung | telemonster, select * from user_project_metadata where userid = 'OpenStack Admin'; | 00:50 |
| telemonster | the userid in that table is a long hex line, and that hex line matches a field in the user table | 00:50 |
| gyee | user_id | 00:50 |
| ayoung | morganfainberg, nah, we know the sAMAccountName from AD | 00:50 |
| morganfainberg | ayoung, ahh | 00:50 |
| ayoung | telemonster, ACHA! | 00:50 |
| morganfainberg | mixed up SQL and LDAP identity! | 00:51 |
| gyee | ouch! | 00:51 |
| ayoung | telemonster, select count(*) from user; | 00:51 |
| ayoung | if it is anything more than 10 they lied to you about using LDAP | 00:51 |
| telemonster | 9 | 00:51 |
| ayoung | OK, so that is a service user | 00:51 |
| morganfainberg | OpenStack Admin is SQL service? | 00:52 |
| morganfainberg | ok | 00:52 |
| ayoung | telemonster, select count(*) from user_project_metadata; | 00:52 |
| ayoung | should return like hundreds, at least one per user of your cloud | 00:52 |
| telemonster | 9 | 00:52 |
| morganfainberg | aha | 00:52 |
| morganfainberg | no grants given to the LDAP users | 00:52 |
| ayoung | your database was not restored | 00:52 |
| ayoung | telemonster, do you have sql backups somewhere? | 00:53 |
| telemonster | no :-( | 00:53 |
| telemonster | we know we're recreating all the accounts | 00:53 |
| telemonster | I just need to be able to log in as admin via ldap auth | 00:53 |
| morganfainberg | telemonster, so you need to grant the role to the LDAP admin. | 00:53 |
| gyee | just redo the role assignment | 00:53 |
| telemonster | okay, how do I do this? | 00:53 |
| morganfainberg | it's missing the role assignments for *any* ldap user | 00:53 |
| ayoung | you can do that via SQL or via the CLI using the SERVICE _TOKEN | 00:53 |
| ayoung | I'd go sql at this point | 00:54 |
| telemonster | which table are the roles in | 00:54 |
| morganfainberg | ayoung, i'd say use SERVICE_TOKEN | 00:54 |
| morganfainberg | ayoung, but thats me. | 00:54 |
| morganfainberg | only cause i worry about screwing up the SQL personally | 00:54 |
| ayoung | telemonster, OK...lets do it morganfainberg 's way | 00:54 |
| telemonster | okay | 00:54 |
| telemonster | 1 sec | 00:54 |
| ayoung | start by looking at your keystone.conf file | 00:54 |
| telemonster | I have a table called role, the role table has a hex line | 00:54 |
| ayoung | there is an field called admin_token | 00:54 |
| morganfainberg | telemonster, we'll do this via the api | 00:54 |
| morganfainberg | less likely to miss a bit of it | 00:54 |
| ayoung | if you use that, you can do basica operations on the keystone server without having any roles | 00:54 |
| telemonster | that role line for the admin role | 00:55 |
| telemonster | has been assigned to the cloudadmin user that exists in ldap | 00:55 |
| telemonster | my coworker undid the ldap part and reverted to sql auth inorder to add it | 00:55 |
| ayoung | telemonster, OK...restart the keystone server and try to get a token, then | 00:55 |
| telemonster | I can do that with it like this: | 00:56 |
| telemonster | user_id_attribute = cn | 00:56 |
| telemonster | user_name_attribute = sAMAccountName | 00:56 |
| morganfainberg | raildo_, ok looking at that patch now. ayoung seems to have this under control (not that he didn't earlier) | 00:56 |
| raildo_ | morganfainberg, haha ok | 00:56 |
| ayoung | morganfainberg, thanks for stepping in. Where else can you get first line support from the PTL? | 00:57 |
| telemonster | keystone --os-username cloudadmin token-get | 00:57 |
| telemonster | +----------+----------------------------------+ | 00:57 |
| telemonster | | Property | Value | | 00:57 |
| telemonster | +----------+----------------------------------+ | 00:57 |
| telemonster | | expires | 2014-11-20T00:56:59Z | | 00:57 |
| telemonster | | id | 2715675a540d4f70ada7cf52749b5fa1 | | 00:57 |
| telemonster | | user_id | OpenStack Admin | | 00:57 |
| telemonster | +----------+----------------------------------+ | 00:57 |
| morganfainberg | ayoung, LOL | 00:57 |
| morganfainberg | ayoung, i needed a break from meeting hell day | 00:57 |
| ayoung | that looks unscoped. Now you need to try it with OS_TENANTNAME set. | 00:58 |
| ayoung | OK so in the database you have: | 00:58 |
| telemonster | keystone --os-username cloudadmin --os-tenant-name admin token-get | 00:58 |
| *** htruta_ has joined #openstack-keystone | 00:58 | |
| telemonster | The request you have made requires authentication. (HTTP 401) | 00:58 |
| ayoung | telemonster, select * from user_project_metadata where userid = 'OpenStack Admin'; | 00:58 |
| ayoung | that returns something now? | 00:59 |
| rodrigods | morganfainberg, how is the federation env deployment going? | 01:00 |
| telemonster | mysql> select id,name,extra,default_project_id from user; | 01:00 |
| telemonster | +----------------------------------+------------+-------------------------------------+----------------------------------+ | 01:00 |
| telemonster | | id | name | extra | default_project_id | | 01:00 |
| telemonster | | ac367c8d070a4f77ab72bb037bb8e4c1 | cloudadmin | {"email": "cloudadmin@aopslab.com"} | f88b07200f33441fa8a40354b63b4385 | | 01:00 |
| telemonster | ignore that email :-) | 01:00 |
| morganfainberg | rodrigods, haven't started, literally finished meetings 15 mins ago | 01:00 |
| rodrigods | morganfainberg, omg | 01:00 |
| telemonster | select * from user_project_metadata; | 01:00 |
| telemonster | +----------------------------------+----------------------------------+-----------------------------------------------------------------------------------------------------+ | 01:00 |
| telemonster | | user_id | project_id | data | | 01:00 |
| telemonster | +----------------------------------+----------------------------------+-----------------------------------------------------------------------------------------------------+ | 01:00 |
| morganfainberg | rodrigods, tuesdays my meetings start at 9am and today finished at 4, 20 minute break for lunch at 2:30 | 01:00 |
| telemonster | | ac367c8d070a4f77ab72bb037bb8e4c1 | f88b07200f33441fa8a40354b63b4385 | {"roles": [{"id": "3048097427ba4e3f85931ad888862721"}]} | | 01:00 |
| telemonster | then the role ... | 01:01 |
| morganfainberg | rodrigods, and all of those are upstream/openstack (no internal meetings included) | 01:01 |
| telemonster | mysql> select * from role; | 01:01 |
| telemonster | +----------------------------------+-----------------+---------------------------------------------------------------------------+ | 01:01 |
| telemonster | | id | name | extra | | 01:01 |
| telemonster | +----------------------------------+-----------------+---------------------------------------------------------------------------+ | 01:01 |
| telemonster | | 3048097427ba4e3f85931ad888862721 | admin | {} | | 01:01 |
| rodrigods | morganfainberg, omg^3 | 01:01 |
| rodrigods | telemonster, would be nice to paste those information in paste.openstack.org | 01:02 |
| rodrigods | telemonster, easier to read | 01:02 |
| telemonster | ooo your own pastebin! | 01:02 |
| telemonster | yea let me utilize that | 01:02 |
| rodrigods | morganfainberg, know about 1 person that succeeded implementing k2k following my blog post, let me know if you use it as reference anytime hehe | 01:03 |
| raildo_ | morganfainberg, how much time per day do you sleep? 1, 2 hours? haha | 01:03 |
| morganfainberg | raildo_, why do you ask? I tend to go to sleep around 10pm these days, up at 6-6:30. | 01:03 |
| morganfainberg | raildo_ so .. 7-8hrs? | 01:03 |
| raildo_ | just curiosity haha | 01:04 |
| morganfainberg | i also try and move slow for breakfast / lunch where possible | 01:04 |
| ayoung | telemonster, ok so | 01:04 |
| morganfainberg | raildo_, ok i see something we need to solve in that patch before it can go in. | 01:04 |
| telemonster | here is the paste | 01:04 |
| telemonster | http://paste.openstack.org/show/134562/ | 01:04 |
| morganfainberg | raildo_, getting the details before I comment | 01:05 |
| raildo_ | morganfainberg, I arrive at work, you're online, I come back home, you're online hahaa | 01:05 |
| raildo_ | morganfainberg, ok | 01:05 |
| morganfainberg | raildo_, i work from home. | 01:05 |
| telemonster | ayoung - are there other tables that should have pointers as well? | 01:05 |
| rodrigods | raildo_, that's not true, morganfainberg appears after our lunch =) | 01:05 |
| morganfainberg | raildo_, and have my phone connected to IRC (i usuaully ignore it when i'm not at my desk) | 01:05 |
| ayoung | insert into user_project_metadata values ('Cloud Admin', 'f88b07200f33441fa8a40354b63b4385', ' {"roles": [{"id": "3048097427ba4e3f85931ad888862721"}]}'); | 01:05 |
| morganfainberg | raildo_ i also have ZNC online so i don't ever leave the channel really. | 01:05 |
| ayoung | make that | 01:05 |
| ayoung | insert into user_project_metadata values ('OpenStack Admin', 'f88b07200f33441fa8a40354b63b4385', ' {"roles": [{"id": "3048097427ba4e3f85931ad888862721"}]}'); | 01:06 |
| raildo_ | rodrigods, yeah, but some times i see him online :) | 01:06 |
| morganfainberg | oh wow, we need to do a SQL collapse. | 01:06 |
| rodrigods | raildo_ you will always see me online -> bip | 01:06 |
| ayoung | telemonster, you see what I am getting at? | 01:06 |
| morganfainberg | oh boy. | 01:06 |
| ayoung | morganfainberg, I want to move them to icehouse, but first get them up and running | 01:06 |
| telemonster | hah I think I get it | 01:06 |
| morganfainberg | ayoung, ++ | 01:06 |
| ayoung | or even Juno.... | 01:06 |
| morganfainberg | juno would be better, but... | 01:07 |
| morganfainberg | i'd go baby steps | 01:07 |
| morganfainberg | ;) | 01:07 |
| telemonster | ayoung | 01:07 |
| telemonster | dude | 01:07 |
| telemonster | THANK YOU SO MUCH!!! | 01:07 |
| ayoung | I can get them to set up a Keystone server using the Juno code, LDAP, and a backup of their sql data | 01:07 |
| telemonster | It worked | 01:07 |
| morganfainberg | ayoung, ++ yessss | 01:07 |
| telemonster | let me check something | 01:07 |
| ayoung | telemonster, OK, I'm going home now. I miss my family | 01:07 |
| * ayoung pops smoke | 01:08 | |
| * ayoung moves out | 01:08 | |
| * ayoung draws fire | 01:08 | |
| telemonster | ayoung - thanks much, so much | 01:08 |
| telemonster | I'll try to come up with some document and put it out public? | 01:08 |
| telemonster | so others have a path? | 01:08 |
| ayoung | telemonster, I'll check back in once I'm home and say hello to my family | 01:08 |
| telemonster | okay sounds good, do that!! Thanks again | 01:08 |
| telemonster | (to everyone !!) | 01:08 |
| ayoung | glad to help. | 01:09 |
| *** ayoung has quit IRC | 01:09 | |
| *** nkinder has joined #openstack-keystone | 01:09 | |
| raildo_ | morganfainberg,so.. what we have to solve about the patch? | 01:11 |
| morganfainberg | raildo_, ok commented | 01:12 |
| morganfainberg | raildo_, but in short, you're missing the SQL migration | 01:12 |
| morganfainberg | you're adding it to the the table construct, but not to the DB backend | 01:12 |
| raildo_ | morganfainberg, i'll read the comment | 01:12 |
| morganfainberg | db schema | 01:12 |
| raildo_ | morganfainberg, ok, i'll do that | 01:12 |
| morganfainberg | so you'll need a SQL Alchemy migration and then you can likely use the @handle conflicts decorator | 01:13 |
| morganfainberg | rather than needing custom "try/except" code | 01:13 |
| morganfainberg | :) | 01:13 |
| raildo_ | morganfainberg, great, thanks :) | 01:13 |
| morganfainberg | then duplicates can never occur because the DB schema prevents it | 01:13 |
| morganfainberg | the migrate will need to resolve duplicates somehow though | 01:13 |
| raildo_ | i understand... I'll implement it now :) | 01:15 |
| *** _cjones_ has quit IRC | 01:34 | |
| *** jorge_munoz has joined #openstack-keystone | 01:39 | |
| *** gyee has quit IRC | 01:40 | |
| *** jorge_munoz has quit IRC | 01:42 | |
| *** jorge_munoz has joined #openstack-keystone | 01:42 | |
| *** jorge_munoz has quit IRC | 01:44 | |
| lbragstad | morganfainberg: whoop whoop!! | 01:47 |
| *** joesavak has quit IRC | 01:53 | |
| *** patrickeast has left #openstack-keystone | 02:05 | |
| *** ayoung has joined #openstack-keystone | 02:05 | |
| *** ChanServ sets mode: +v ayoung | 02:05 | |
| *** amcrn has quit IRC | 02:08 | |
| *** ncoghlan is now known as ncoghlan_afk | 02:12 | |
| *** NM has joined #openstack-keystone | 02:24 | |
| *** raildo_ has quit IRC | 02:30 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Add new "RoleAssignment" exception https://review.openstack.org/133628 | 02:30 |
| *** ncoghlan_afk is now known as ncoghlan | 02:31 | |
| *** ncoghlan is now known as ncoghlan_afk | 02:36 | |
| *** erkules_ has joined #openstack-keystone | 02:36 | |
| *** erkules has quit IRC | 02:38 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Add new "RoleAssignment" exception https://review.openstack.org/133628 | 02:41 |
| *** soulxu_ has joined #openstack-keystone | 02:43 | |
| *** marcoemorais has quit IRC | 02:43 | |
| *** alex_xu has quit IRC | 02:46 | |
| *** ncoghlan_afk is now known as ncoghlan | 02:46 | |
| jamielennox | anyone know how oslo.policy interprets "admin_api": "is_admin:True" | 02:47 |
| jamielennox | i assume is_admin is the role == admin ? | 02:47 |
| *** marg7175 has quit IRC | 02:50 | |
| *** soulxu__ has joined #openstack-keystone | 02:52 | |
| *** stevemar has joined #openstack-keystone | 02:52 | |
| *** ChanServ sets mode: +v stevemar | 02:52 | |
| *** soulxu_ has quit IRC | 02:55 | |
| *** soulxu_ has joined #openstack-keystone | 02:58 | |
| *** soulxu__ has quit IRC | 03:02 | |
| *** jdennis has quit IRC | 03:04 | |
| *** soulxu__ has joined #openstack-keystone | 03:04 | |
| *** links has joined #openstack-keystone | 03:04 | |
| *** dims_ has quit IRC | 03:05 | |
| *** dims has joined #openstack-keystone | 03:06 | |
| *** soulxu_ has quit IRC | 03:07 | |
| openstackgerrit | Steve Martinelli proposed openstack/python-keystoneclient: OAuth headers are missing https://review.openstack.org/134364 | 03:08 |
| openstackgerrit | Takashi NATSUME proposed openstack/keystone: Enable cloud_admin to list projects in all domains https://review.openstack.org/134111 | 03:10 |
| *** soulxu_ has joined #openstack-keystone | 03:12 | |
| *** soulxu__ has quit IRC | 03:16 | |
| *** harlowja is now known as harlowja_away | 03:16 | |
| *** soulxu__ has joined #openstack-keystone | 03:18 | |
| *** soulxu_ has quit IRC | 03:22 | |
| *** jdennis has joined #openstack-keystone | 03:22 | |
| ayoung | jamielennox, I don't think there is any magic there | 03:22 |
| jamielennox | yea, i think i figured it out | 03:23 |
| ayoung | what policy file are you looking at? | 03:23 |
| ayoung | keystone? it is if the Service token is set | 03:23 |
| *** htruta_ has quit IRC | 03:23 | |
| jamielennox | ayoung: it's just doing a look for 'is_admin': True in the passed context | 03:23 |
| jamielennox | been a while since i've done policy stuff | 03:23 |
| ayoung | right, which is set by the service token or if the admin role is set...middleware something or other | 03:23 |
| jamielennox | yep | 03:24 |
| jamielennox | mmmm, is that provided by oslo.middleware? | 03:24 |
| jamielennox | oh, good there is no common context.py yet | 03:26 |
| *** soulxu_ has joined #openstack-keystone | 03:27 | |
| *** zzzeek has quit IRC | 03:30 | |
| *** soulxu__ has quit IRC | 03:31 | |
| *** NM has quit IRC | 03:31 | |
| jamielennox | ayoung: no, it does exist - it's being worked on: https://github.com/openstack/oslo.context/blob/master/oslo/context/context.py | 03:32 |
| jamielennox | should we try to remove some of this | 03:32 |
| jamielennox | kill the is_admin concept or own it in keystonemiddlewaer? | 03:32 |
| ayoung | is that another "make the token into a python object" implementation? | 03:38 |
| *** chrisshattuck has joined #openstack-keystone | 03:39 | |
| ayoung | I kindof loath all of the implementations I've seen so far. | 03:39 |
| ayoung | especially the one I wrote | 03:39 |
| jamielennox | ayoung: kind of, it extracts a bunch of stuff from the token and other and i think you are supposed to feed it to the policy engine | 03:44 |
| jamielennox | ayoung: i would therefore think it should belong in an upcoming oslo.policy | 03:45 |
| *** soulxu__ has joined #openstack-keystone | 03:45 | |
| jamielennox | though it's a helper and not a requirement | 03:45 |
| ayoung | pycpre | 03:45 |
| ayoung | pronounce pick-pree | 03:45 |
| jamielennox | lol | 03:46 |
| jamielennox | no | 03:46 |
| jamielennox | oslo_policy is fine | 03:46 |
| ayoung | nah, we can't use the name oslo we've been told. | 03:46 |
| ayoung | but whatever | 03:46 |
| jamielennox | the weird thing is that the policy helper doesn't know how to load the info from auth_token headers - the app still has to handle that itself | 03:47 |
| ayoung | yeah, all of this needs to be unified in the library | 03:47 |
| jamielennox | we can probably just put that context into keystonemiddleware with some smarts about how to load it from the expected headers | 03:47 |
| ayoung | we should start by cleanin up the keystone code in common/controller.py | 03:47 |
| jamielennox | ayoung: resurrcet the pecan? | 03:47 |
| ayoung | nah | 03:47 |
| morganfainberg | it can't be oslo_policy if it's under ourprogam | 03:48 |
| ayoung | I think that it should be a straight Python object....marshall to it from JSON | 03:48 |
| jamielennox | morganfainberg: if we make the core group keystone-core what difference does it make | 03:48 |
| *** soulxu_ has quit IRC | 03:48 | |
| morganfainberg | jamielennox, it would need to be oslo-core if it was under oslo | 03:48 |
| *** jorge_munoz has joined #openstack-keystone | 03:49 | |
| ayoung | what's in a name | 03:49 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 03:49 | |
| morganfainberg | and if we want it graduated this cycle it's coming to us | 03:49 |
| ayoung | python-policyengine | 03:49 |
| jamielennox | morganfainberg: did you know about oslo.context? | 03:49 |
| jamielennox | ayoung: any name like that is way to generic | 03:49 |
| jamielennox | i don't think i'd use this policy engine out of openstack | 03:49 |
| ayoung | morganfainberg, OK, since the three of us are here, let's have this whole context thing out | 03:49 |
| ayoung | jamielennox, you wrote one in client that passes through to the JSON. I wrote a crappy one for revocaking events | 03:50 |
| ayoung | morganfainberg, you want us to use...which one again? | 03:50 |
| *** jorge_munoz has quit IRC | 03:50 | |
| jamielennox | i wrote an auth_plugin - which is very similar | 03:50 |
| jamielennox | if we could convert token -> context it would be the same thing | 03:51 |
| *** soulxu_ has joined #openstack-keystone | 03:51 | |
| ayoung | TODO(morganfainberg): Collapse this logic with AuthContextMiddleware | 03:51 |
| ayoung | that is from https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L64 | 03:51 |
| ayoung | the revocation events uses | 03:52 |
| ayoung | https://github.com/openstack/keystone/blob/master/keystone/contrib/revoke/model.py#L252 | 03:52 |
| ayoung | then we have https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L37 the helper in the token | 03:53 |
| *** soulxu__ has quit IRC | 03:54 | |
| ayoung | we have the model code... | 03:54 |
| ayoung | https://github.com/openstack/keystone/blob/master/keystone/common/models.py#L32 | 03:54 |
| ayoung | that is minimalistic | 03:54 |
| morganfainberg | yeah | 03:55 |
| morganfainberg | ok | 03:55 |
| ayoung | which is the best one we have so far? | 03:55 |
| morganfainberg | ayoung, sorry what are we trying to solve | 03:58 |
| morganfainberg | i'm brain fried | 03:58 |
| ayoung | morganfainberg, we have about a gazillion different objects to represent the unpacked state of the token | 03:58 |
| jamielennox | nova has there own as well | 03:58 |
| *** jorge_munoz has joined #openstack-keystone | 03:58 | |
| jamielennox | so do most others | 03:58 |
| ayoung | trying to get rid of a few. | 03:58 |
| morganfainberg | the one inside keystone i wrote will be mucked with a bit more to be a base state that we can convert to the JSON | 03:58 |
| morganfainberg | e.g. format | 03:58 |
| jamielennox | cinder: https://github.com/openstack/cinder/blob/master/cinder/context.py | 03:59 |
| ayoung | morganfainberg, which one is that? | 03:59 |
| morganfainberg | ayoung, the model in keystone | 03:59 |
| ayoung | link? | 03:59 |
| morganfainberg | the idea is that one is what we pass to the formatter | 03:59 |
| jamielennox | glance: https://github.com/openstack/glance/blob/master/glance/context.py | 03:59 |
| ayoung | or what file? | 03:59 |
| morganfainberg | uh... | 03:59 |
| ayoung | from keystone.models import token_model | 03:59 |
| morganfainberg | that one | 03:59 |
| morganfainberg | yeah | 03:59 |
| ayoung | that is in AuthCOntextMiddleware | 03:59 |
| jamielennox | i was looking at what happens if we rename the admin role, turns out it's mostly file because the services all cheat | 03:59 |
| morganfainberg | that one is going to change to be more "internal keystone" [the direction it was headed already] | 04:00 |
| ayoung | https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py | 04:00 |
| *** soulxu_ has quit IRC | 04:00 | |
| morganfainberg | that will move away from being a bad copy of AccessInfo andto the base state of "token data" which then can be formatted | 04:00 |
| ayoung | you you are using the JSON as the state of the object and exposing the properites as getters | 04:00 |
| *** jorge_munoz has quit IRC | 04:00 | |
| ayoung | jamielennox, you ok with that approach? | 04:00 |
| morganfainberg | that one wont be a dict w/ gettrs and such when i'm done with policy cleanup | 04:01 |
| morganfainberg | it's getting turned on it's head | 04:01 |
| jamielennox | ayoung which appraoch? | 04:01 |
| *** soulxu_ has joined #openstack-keystone | 04:01 | |
| ayoung | jamielennox, nevermind, morganfainberg 's going a different direction anyway | 04:01 |
| morganfainberg | that was the intermidiary step so we could have only 1 way to reference tokend ata inside of keystone | 04:01 |
| morganfainberg | outside of keystone | 04:01 |
| jamielennox | morganfainberg: we need a cross project approach - and i don't think it can be your token model | 04:02 |
| morganfainberg | i'm ok with using the AccessInfo type thing | 04:02 |
| morganfainberg | jamielennox, no it can't | 04:02 |
| ayoung | morganfainberg, OK. I would suggest that the end state be a pure python object | 04:02 |
| ayoung | a POPO if you will, to bastardize a term from Java | 04:02 |
| morganfainberg | ayoung, that is the plan, it's how the interface on the token providers will actually work | 04:02 |
| morganfainberg | that way only time we *ever* format the token data to that icky json blob is on validate...or if the provider needs it (aka pki) | 04:03 |
| jamielennox | so to get around hardcoding the "admin" role projects do: https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json#L2 | 04:03 |
| morganfainberg | ayoung, now outside of keystone - i don't have a good answer. | 04:03 |
| jamielennox | then fetch that value from the policy https://github.com/openstack/cinder/blob/master/cinder/policy.py#L84 | 04:03 |
| ayoung | morganfainberg, OK. We start with a simple token object model and take it from there. Next it moves over to keystoneclient | 04:04 |
| ayoung | or, if you want to make keystonecommon, I'm cool with that | 04:04 |
| jamielennox | then check if either 'admin' or that value is set: https://github.com/openstack/cinder/blob/master/cinder/context.py#L73 | 04:04 |
| morganfainberg | i'm thinking we want it in a common lib | 04:04 |
| jamielennox | then rely on is_admin that way | 04:04 |
| ayoung | OK, lets go with that for now | 04:04 |
| morganfainberg | so we can have places use it w/o needing all of keystoneclient. | 04:04 |
| ayoung | sure | 04:04 |
| jamielennox | so you can completely change the name of the admin role - but it's symbolic and everything still works on the admin concept | 04:05 |
| ayoung | that needs to die | 04:05 |
| ayoung | is_admin is_broken | 04:05 |
| jamielennox | but at least is_admin doesn't have to be 'admin' :) shoot me | 04:05 |
| morganfainberg | ugh | 04:05 |
| ayoung | jamielennox, I'll have to send a drone to shoot you, you are currently out of my max-effective range | 04:06 |
| jamielennox | these lines are particularly fun: https://github.com/openstack/cinder/blob/master/cinder/context.py#L74-L75 | 04:06 |
| ayoung | admin admin duck | 04:07 |
| jamielennox | so if you've renamed the admin role for whatever reason or you've hard set is_admin=True then it will actually append the 'admin' string | 04:07 |
| jamielennox | because..... | 04:07 |
| morganfainberg | fantastic | 04:07 |
| jamielennox | nope got nothing | 04:07 |
| morganfainberg | i uh.. | 04:07 |
| morganfainberg | wut. | 04:07 |
| ayoung | ok...so does you guys at least understand my current focus on policy and where I want to go with it? | 04:07 |
| ayoung | and are basically aligned? | 04:08 |
| morganfainberg | ayoung, for the most part i have an idea. | 04:08 |
| jamielennox | ayoung: mostly, and enough | 04:08 |
| morganfainberg | i don't think you're wildly off base or anything | 04:08 |
| ayoung | is storing in the database an OK option? | 04:08 |
| morganfainberg | ayoung, oh absolutely | 04:08 |
| morganfainberg | in *a* backend. | 04:08 |
| morganfainberg | which might just be SQL | 04:08 |
| morganfainberg | but same concept | 04:08 |
| jamielennox | i actually think if we do the server side role aliasing etc, then dynamicly fetching the policy isn't that important | 04:08 |
| ayoung | yeah....the schema for the current rules thing might be hideous | 04:09 |
| morganfainberg | jamielennox, we still need it centralized for $OTHER_REASONS$ | 04:09 |
| morganfainberg | aka horizon knowing what you can do, etc | 04:09 |
| jamielennox | sure | 04:09 |
| ayoung | more important is the clean up of things like that cinder code | 04:09 |
| morganfainberg | its just not as important for the policy enforcement part | 04:09 |
| morganfainberg | ayoung, ++ | 04:09 |
| ayoung | and the ability to break apart admin into its fundamental parts | 04:09 |
| jamielennox | i just mean at one stage we were talking about making the definition really dynamic, like different policy files for each domain/project | 04:09 |
| jamielennox | i like the server side roles approach way better | 04:10 |
| ayoung | jamielennox, so, yeah, that stays on Keystone server | 04:10 |
| ayoung | make them aliases for the things that will show up in policy | 04:10 |
| morganfainberg | jamielennox, lets not jump to project/domain policy | 04:10 |
| morganfainberg | lets worry about that after we have everything in place that we could do it | 04:10 |
| ayoung | OK...need to head to bed... | 04:10 |
| morganfainberg | it may not be needed | 04:10 |
| jamielennox | well we don't need it | 04:10 |
| morganfainberg | exactly | 04:10 |
| jamielennox | is what i meant, i prefer the server doing role/capability resolving than making it a policy decision | 04:11 |
| ayoung | morganfainberg, its what Henrynash is working towards...I'd have prioritized it after everything else | 04:11 |
| ayoung | I think making it a policy decision is the cleaner approach | 04:11 |
| ayoung | otherwise, tokens get huge, but policy stays static and broken | 04:12 |
| ayoung | maybe first thing is getting a unified policy file | 04:12 |
| ayoung | even if we don't dynamically generate it | 04:12 |
| jamielennox | policy just becomes a way of naming capabilities, tokens include the global capabilities available | 04:12 |
| *** jorge_munoz has joined #openstack-keystone | 04:12 | |
| jamielennox | policy engine enforces those capabilities | 04:13 |
| ayoung | PEP | 04:13 |
| jamielennox | it's just unfortunate we're going to end up with so many definitions of 'role' | 04:13 |
| ayoung | profiteroles | 04:13 |
| ayoung | ok...gotta crash | 04:13 |
| ayoung | gnight | 04:13 |
| jamielennox | night | 04:13 |
| *** ayoung is now known as ayoung-ZZZzzzZzz | 04:13 | |
| *** jorge_munoz has quit IRC | 04:15 | |
| *** soulxu__ has joined #openstack-keystone | 04:21 | |
| *** jdennis has quit IRC | 04:22 | |
| *** soulxu_ has quit IRC | 04:24 | |
| *** soulxu_ has joined #openstack-keystone | 04:31 | |
| *** soulxu__ has quit IRC | 04:33 | |
| *** marg7175 has joined #openstack-keystone | 04:34 | |
| *** marg7175 has joined #openstack-keystone | 04:35 | |
| *** soulxu__ has joined #openstack-keystone | 04:36 | |
| *** soulxu_ has quit IRC | 04:39 | |
| *** tellesnobrega has quit IRC | 04:44 | |
| *** soulxu_ has joined #openstack-keystone | 04:50 | |
| *** marg7175 has quit IRC | 04:52 | |
| *** soulxu__ has quit IRC | 04:53 | |
| *** soulxu__ has joined #openstack-keystone | 04:56 | |
| *** soulxu_ has quit IRC | 04:59 | |
| *** jorge_munoz has joined #openstack-keystone | 05:00 | |
| *** jorge_munoz has quit IRC | 05:04 | |
| *** soulxu_ has joined #openstack-keystone | 05:09 | |
| *** chrisshattuck has quit IRC | 05:11 | |
| *** soulxu__ has quit IRC | 05:12 | |
| *** ncoghlan is now known as ncoghlan_afk | 05:27 | |
| *** boris-42 has joined #openstack-keystone | 05:39 | |
| *** soulxu__ has joined #openstack-keystone | 05:42 | |
| *** soulxu_ has quit IRC | 05:45 | |
| *** k4n0 has joined #openstack-keystone | 05:52 | |
| *** soulxu_ has joined #openstack-keystone | 05:53 | |
| *** soulxu__ has quit IRC | 05:56 | |
| *** soulxu__ has joined #openstack-keystone | 06:00 | |
| *** links has quit IRC | 06:02 | |
| *** stevemar has quit IRC | 06:02 | |
| *** soulxu_ has quit IRC | 06:03 | |
| *** ncoghlan_afk is now known as ncoghlan | 06:04 | |
| *** david-ly_ has joined #openstack-keystone | 06:11 | |
| *** david-lyle_afk has quit IRC | 06:12 | |
| *** soulxu_ has joined #openstack-keystone | 06:12 | |
| *** soulxu__ has quit IRC | 06:15 | |
| *** ukalifon1 has joined #openstack-keystone | 06:31 | |
| *** k4n0 has quit IRC | 06:39 | |
| *** ukalifon1 has quit IRC | 06:50 | |
| *** marg7175 has joined #openstack-keystone | 06:53 | |
| *** k4n0 has joined #openstack-keystone | 06:54 | |
| *** marg7175 has quit IRC | 06:57 | |
| *** david-ly_ has quit IRC | 07:18 | |
| *** kevinbenton has quit IRC | 07:22 | |
| *** k4n0 has quit IRC | 07:31 | |
| *** soulxu_ is now known as alex_xu | 07:36 | |
| *** ukalifon1 has joined #openstack-keystone | 07:43 | |
| *** k4n0 has joined #openstack-keystone | 07:44 | |
| *** amerine has joined #openstack-keystone | 07:47 | |
| *** boris-42 has quit IRC | 07:47 | |
| *** samuelms_ has joined #openstack-keystone | 07:51 | |
| *** nellysmitt has joined #openstack-keystone | 07:53 | |
| *** samuelms_ has quit IRC | 08:03 | |
| *** marekd|away is now known as marekd | 08:12 | |
| *** alex_xu has quit IRC | 08:13 | |
| *** links has joined #openstack-keystone | 08:21 | |
| *** ajayaa has joined #openstack-keystone | 08:37 | |
| *** david-lyle_afk has joined #openstack-keystone | 08:49 | |
| *** NM has joined #openstack-keystone | 08:50 | |
| *** samuelms_ has joined #openstack-keystone | 08:51 | |
| *** marg7175 has joined #openstack-keystone | 08:53 | |
| *** amerine has quit IRC | 08:53 | |
| *** amerine has joined #openstack-keystone | 08:54 | |
| *** NM has quit IRC | 08:54 | |
| *** marg7175 has quit IRC | 08:57 | |
| *** henrynash has joined #openstack-keystone | 09:15 | |
| *** ChanServ sets mode: +v henrynash | 09:15 | |
| marekd | henrynash: can you take a look at the patch https://review.openstack.org/#/c/133130/11 ? | 09:15 |
| henrynash | marekd: sure | 09:15 |
| marekd | henrynash: thanks | 09:15 |
| samuelms_ | hi marekd, henrynash :) | 09:16 |
| samuelms_ | morning | 09:16 |
| *** oomichi has quit IRC | 09:16 | |
| marekd | samuelms_: hey | 09:16 |
| henrynash | samuelms: hi | 09:16 |
| marekd | samuelms_: isn't like a night at your homeplace? | 09:16 |
| samuelms_ | marekd, it's 6:16 here .. :-) | 09:17 |
| samuelms_ | marekd, normally we start working at 8 am .. but my head is confused with role-groups vs hierarchical roles :/ | 09:17 |
| *** erkules_ is now known as erkules | 09:18 | |
| marekd | samuelms_: lol | 09:18 |
| samuelms_ | henrynash, I was thinking about role-groups vs hierarchical roles .. | 09:18 |
| marekd | samuelms_: what are role-groups | 09:18 |
| henrynash | samuelms: ok | 09:18 |
| marekd | where can i read about it | 09:18 |
| samuelms_ | henrynash, do you have a couple of minutes to discuss? | 09:18 |
| samuelms_ | marekd, hierarchical roles https://review.openstack.org/#/c/125704/ | 09:19 |
| henrynash | samuelms: let me just finish reviewing marekd’s patch | 09:19 |
| samuelms_ | marekd, group of rles https://review.openstack.org/#/c/133855/ | 09:19 |
| samuelms_ | henrynash, sure | 09:19 |
| marekd | samuelms_: and that's all or some introductionary reading is required? | 09:21 |
| *** ityaptin has quit IRC | 09:21 | |
| samuelms_ | marekd, I think that's enough | 09:23 |
| marekd | samuelms_: and more info about hierarchical multitenancy? | 09:24 |
| marekd | like i know almost nothing about it and for some reasons i need to know more. | 09:24 |
| samuelms_ | marekd, hmm | 09:24 |
| samuelms_ | marekd, so you'd like to understand from the basics .. | 09:25 |
| samuelms_ | marekd, we have some specs .. let me find the links .. | 09:25 |
| samuelms_ | marekd, the first one is https://github.com/openstack/keystone-specs/blob/0097cc91efe2cc189bc2a135a8eccfc12edb407e/specs/juno/hierarchical_multitenancy.rst | 09:26 |
| samuelms_ | marekd, in which we have a part merged .. and a part under review | 09:26 |
| *** esp has quit IRC | 09:26 | |
| samuelms_ | marekd, the part that is still under review starts at https://review.openstack.org/#/c/117786/ | 09:27 |
| samuelms_ | marekd, I also have the feeling that I should know more about federated stuff .. :-) | 09:28 |
| samuelms_ | marekd, will try to setup an environment soon | 09:28 |
| marekd | samuelms_: icehouse or k2k ? | 09:29 |
| samuelms_ | marekd, when you say icehouse, you mean just federation (not k2k)? | 09:30 |
| samuelms_ | marekd, both .. I'd like to at least taste everything is going up on Keystone ( : | 09:32 |
| marekd | samuelms_: so start with icehouse | 09:33 |
| samuelms_ | marekd, ok .. will do | 09:33 |
| marekd | samuelms_: yes, icehouse is just keystone acting as a SP | 09:33 |
| *** ncoghlan has quit IRC | 09:39 | |
| *** jamielennox is now known as jamielennox|away | 09:41 | |
| henrynash | samuelms: hi | 09:47 |
| *** ajayaa has quit IRC | 09:50 | |
| samuelms_ | henrynash, hi | 09:50 |
| samuelms_ | henrynash, so I was thinking that, basically, role-groups and hierarchical roles have the same goal | 09:51 |
| samuelms_ | henrynash, they share some semantic .. | 09:51 |
| samuelms_ | henrynash, take role-groups and we can implement hierarchical-roles by using them .. right? | 09:51 |
| henrynash | samuelms: well, I think you can implement hieracrchical role-groups…not hierarchical roles | 09:53 |
| samuelms_ | henrynash, but they can do the same, right? | 09:53 |
| marekd | henrynash: thanks for the review, will fix soon. | 09:54 |
| henrynash | samuelms: well, the same effect, yes | 09:54 |
| samuelms_ | henrynash, this can be confusing if the user wants some hierarchy on his roles/role-groups .. | 09:54 |
| samuelms_ | henrynash, which path should he follow in what cases? that's confusing for him.. | 09:55 |
| henrynash | samuelms_: so part of my argument here is that many, many peopel won’t use hierachies at all…but they do want role groups | 09:55 |
| samuelms_ | henrynash, right | 09:55 |
| samuelms_ | henrynash, roles are groups of capabilities, right? | 09:56 |
| henrynash | samuelms: …and for those that do…we want things to “work the same” in terms of objects that are domain scoped….so users, groups, role-groups should all be domain-specific and be handled in some common way in terms of what happens when you layer a hierarcy down | 09:56 |
| henrynash | samuelms_: yeah, really…we just happen to call those capailities ‘roles’ | 09:57 |
| samuelms_ | henrynash, have you ever thought about representing 'what capabilities a role has?' instead of 'what roles can use this capability (current policies are like this)? | 09:58 |
| samuelms_ | henrynash, I've used a software that used the first approach (redmine) | 09:58 |
| samuelms_ | henrynash, I looked much more intuitive for the end-user | 09:58 |
| henrynash | sameulms_: agreed…and infact we could work toward this….take the following example | 10:00 |
| *** esp has joined #openstack-keystone | 10:00 | |
| henrynash | sameulms_: we introduce this new role-group thing….let’s actually call them “domain-roles” | 10:00 |
| henrynash | sameulms_: service policy files start to fill out thirpooicy file with more and more one role for one API | 10:01 |
| samuelms_ | henrynash, ok .. I proposed to call 'role groups' 'domain role groups' :p (left a comment on the patch, but lets continue with your example) | 10:02 |
| henrynash | samuelms_: nearly all assignments become doman-role assignments | 10:02 |
| henrynash | samuelms_: listing a domain-role now effectively lists teh capabilities of that domain role | 10:02 |
| henrynash | samuelms_: inheritance down a samll tree (e.g. cloud domain at the top, with customer domains udnerneath), allows common domain-roles to be inherited, rather than domains/projects have to define them all from scratch | 10:04 |
| henrynash | samuelms_: I guess that’s what I’m pitching as a way this all eveolves | 10:04 |
| samuelms_ | henrynash, hmm interesting | 10:06 |
| samuelms_ | henrynash, when you said 'listing a domain-role now effectively lists teh capabilities of that domain role' | 10:07 |
| samuelms_ | henrynash, you're using the second approach I've point out, right? | 10:07 |
| henrynash | samuelms_: no, I think this is more liek teh first, no? | 10:09 |
| samuelms_ | henrynash, sure! | 10:09 |
| samuelms_ | henrynash, confused myself .. exactly the first one (like redmine as I said) :) | 10:09 |
| henrynash | :-) | 10:10 |
| samuelms_ | henrynash, so if I understood ... the fact that everything will move to domain-role help us to define that new way of representing capabilities on the policy | 10:11 |
| samuelms_ | henrynash, so that we can start representing 'what capabilities a role has?' for domain-roles .. | 10:11 |
| samuelms_ | henrynash, right? | 10:11 |
| henrynash | samuelms_: for people that wnat to work that way, yes. If at that ponint we renamed “roles’ to “capabilities’ and ‘domain-roles’ ro ‘roles’ we would have exacty that | 10:12 |
| samuelms_ | henrynash, :D | 10:12 |
| samuelms_ | henrynash, I can't see how would be the transition .. like defining a separated policy for domain-roles -> capabilities? | 10:14 |
| henrynash | samuelms_: not sure I follow | 10:16 |
| samuelms_ | henrynash, the policy would be a set of domain-roles -> capabilities, right? | 10:17 |
| samuelms_ | henrynash, like 'instance_admin': 'create_instance', 'delete_instace', etc | 10:17 |
| henrynash | samuelms_: so I’m not sure how far you are jumping here…I don;t that that’s policy…that’s just how, in your domain, you are grouping that set of capabilities…which is different to how some other domain wants to do it | 10:19 |
| henrynash | samuelms_: so I remain unconvinced (yet convincable!) that we need to change policy | 10:19 |
| henrynash | samulems_: at least not for this reason…there may be others outside of this | 10:20 |
| samuelms_ | henrynash, ok .. let's step back .. | 10:21 |
| samuelms_ | henrynash, you said listing a domain-role now effectively lists teh capabilities of that domain role | 10:21 |
| samuelms_ | henrynash, what would be that capabilities? would be the API calls? | 10:21 |
| henrynash | samuelms_: if someone has chosen to craete fine grained roles and assign one to each API, yes | 10:22 |
| henrynash | samuelms_: but that’s there option, I don’t want to force people to have to do that | 10:22 |
| *** aix has joined #openstack-keystone | 10:23 | |
| samuelms_ | henrynash, hm.. so roles are capabilities .. | 10:24 |
| samuelms_ | henrynash, wait, let me write something in an etherpad | 10:24 |
| henrynash | samuelms_: for peopele who have craeted them that way, yes | 10:24 |
| samuelms_ | henrynash, https://etherpad.openstack.org/p/role-capabilities-policy | 10:25 |
| *** ajayaa has joined #openstack-keystone | 10:26 | |
| *** lhcheng has joined #openstack-keystone | 10:33 | |
| *** tellesnobrega has joined #openstack-keystone | 10:38 | |
| samuelms_ | henrynash, ok I think we converged to the idea I was thinking about | 10:38 |
| henrynash | agreed! | 10:39 |
| samuelms_ | henrynash, we can talk more about this later, when everyone is up :D | 10:39 |
| henrynash | ok, speak later | 10:39 |
| *** henrynash has quit IRC | 10:39 | |
| *** boris-42 has joined #openstack-keystone | 10:40 | |
| *** lhcheng_ has joined #openstack-keystone | 10:50 | |
| *** lhcheng has quit IRC | 10:53 | |
| *** tellesnobrega has quit IRC | 10:56 | |
| *** xianghui_ is now known as xianghui | 10:58 | |
| *** samuelms_ has quit IRC | 10:58 | |
| *** henrynash has joined #openstack-keystone | 11:05 | |
| *** ChanServ sets mode: +v henrynash | 11:05 | |
| *** henrynash has quit IRC | 11:08 | |
| *** dims has quit IRC | 11:09 | |
| *** dims has joined #openstack-keystone | 11:09 | |
| *** henrynash has joined #openstack-keystone | 11:09 | |
| *** ChanServ sets mode: +v henrynash | 11:09 | |
| samuelms | henrynash, just one more thing I'd like to synchronize with you :) | 11:18 |
| samuelms | henrynash, have in mind that model we've discussed .. 'defining permissions on-the-fly' | 11:19 |
| samuelms | henrynash, how could a domain admin set that people with the domain-role 'member' should be allowed to get_project only of their project | 11:21 |
| *** diegows has joined #openstack-keystone | 11:21 | |
| samuelms | henrynash, basically, how could we set constraints like 'project_id:%(project_id)s' | 11:22 |
| samuelms | henrynash, on-the-fly | 11:22 |
| samuelms | henrynash, Answer: I think we could add constraints to domain-roles .. that limit capabilities per 'resource' (the user itself, a project, a domain, etc) | 11:24 |
| henrynash | samuelms: so to be dumb for second (I’m good a that)…why not just (only) check for the member role in the rule for get_project? | 11:34 |
| samuelms | henrynash, because you have to be member on the project you're requesting get_project | 11:37 |
| samuelms | henrynash, and then you must have the 'project_id:%(project_id)s' thing | 11:37 |
| samuelms | henrynash, and in other domain the admin may want to not put this constraint: if you're member on one project, you can do get_project on any project of my domain | 11:38 |
| henrynash | samuelms: well that just ensures you have project token for the right project… | 11:39 |
| samuelms | henrynash, so that we give flexibility to different domains .. it is like having one policy file per domain (now on-the-fly policy) :) | 11:39 |
| henrynash | samuelms: before we agree that we need this additional level of fleibility….I’m still unclear on the problem we are trying to solve | 11:40 |
| *** vsilva_ has joined #openstack-keystone | 11:40 | |
| *** tellesnobrega has joined #openstack-keystone | 11:40 | |
| samuelms | henrynash, yes .. what we agreed is clear .. | 11:40 |
| samuelms | henrynash, but now .. suppose the following use case: | 11:41 |
| samuelms | henrynash, domain_a where project members can get_project on any project | 11:41 |
| samuelms | henrynash, domain_b where project members can get_project *only* on the project he is member | 11:41 |
| samuelms | henrynash, how to fit both requirements if we have a single policy file? | 11:42 |
| samuelms | henrynash, we need to put 'project_id:%(project_id)s' for domain_a, but not for domain_b | 11:42 |
| samuelms | henrynash, makes sense? | 11:42 |
| henrynash | samuelms: I would give all the users domain-inherited role that let them do get_project | 11:42 |
| samuelms | henrynash, oh wait .. but this give all domain-admin capabilities | 11:43 |
| samuelms | henrynash, I don't want this .. just in the case of projects | 11:44 |
| *** ekarlso- has quit IRC | 11:44 | |
| henrynash | saumelms: no….it’ an inherited role…so only truns up on projects... | 11:45 |
| samuelms | henrynash, ok . I understand your point | 11:47 |
| samuelms | henrynash, but think about reseller use case | 11:47 |
| samuelms | henrynash, wait I'll get a better example | 11:48 |
| *** kashyap has joined #openstack-keystone | 11:48 | |
| *** ekarlso- has joined #openstack-keystone | 11:49 | |
| samuelms | henrynash, in our previous discussion, we defined a such amazing idea that allows domain admins to define what roles access what capability, right? | 11:51 |
| samuelms | henrynash, on-the-fly :) | 11:51 |
| henrynash | samuelms: indeed | 11:51 |
| henrynash | samuelms: (“amazing” might be pushing it….) | 11:52 |
| *** aix has quit IRC | 11:52 | |
| samuelms | henrynash, haha, yes .. just kidding :) | 11:52 |
| samuelms | henrynash, so, what I'm thinking now is: | 11:52 |
| samuelms | henrynash, beside roles, I'm saying that we should allow them to add others constraints for capabilities | 11:53 |
| henrynash | samulems: so I guess my argument is just that I’m not sure what additional problem this solves, that you can’t solve today... | 11:54 |
| samuelms | henrynash, like: users with this domain-role can only list_instances if they define instance_name query param (even if we can't do it now) | 11:54 |
| henrynash | samuelms: or whether you just think it is more intuaive to admins | 11:54 |
| samuelms | henrynash, my points with this is flexibility | 11:55 |
| samuelms | henrynash, imagine things like: users with this domain-role can only create instances with a project if available quotas > 40% | 11:55 |
| henrynash | samuelms: ah, ok…so you want to do this becsue our new “capabilities” are still not fine grained enough (or maybe lack context)? | 11:55 |
| samuelms | henrynash, EXACTLY | 11:56 |
| samuelms | henrynash, we that would be good to make them more fine grained, do you agree? | 11:57 |
| samuelms | henrynash, we could do amazing things with those constraints (querying resource states, for e.g. available quotas, etc) | 11:59 |
| henrynash | samuelms: ok, so now undestand the requriement - and to argue that this should be done with domain-roels would be that it needs to be in language that makes sense to the domain owner, not the could provider | 11:59 |
| samuelms | henrynash, exactly | 12:00 |
| henrynash | samules: of course, ayoung would argue that this is why he favors rebuilding policy to be dynamic - so you could have, say, a domain-specfifc policy “file” that effectively we DO let the domain admin modify (vi APIs) | 12:00 |
| samuelms | henrynash, and then with all this ^ we don't have to have one policy file per domain | 12:00 |
| henrynash | samuelms: agreed….it’s an alternative approach…. | 12:01 |
| samuelms | henrynash, ok .. makes sense .. | 12:01 |
| samuelms | henrynash, is there a convergence point between this approach and adam's one? | 12:02 |
| samuelms | henrynash, maybe .. | 12:02 |
| samuelms | henrynash, I need to document all this .. will do in an etherpad, ok? think will be better to present the whole idea to other people | 12:02 |
| henrynash | samuelms: so I think as a group as we project out where we will take this….it’s kind of two different conceptual models….one separates the raw service capabilities from the domain-level abstraction (that’s the one I just laid out), the other effectively combines this together as part of a new policy language. | 12:04 |
| *** nellysmitt has quit IRC | 12:05 | |
| samuelms | henrynash, cool | 12:06 |
| samuelms | henrynash, another point would be (in this new approach): if we have one role per capability, why do we still need to have policy files? | 12:07 |
| henrynash | samuelms: well I guess in the limit, if it were really that clean (and I suspect it won’t be), the the “policy file” is just the list of registered APIs…with an attribute of ‘open’, ‘closed’ or ‘needs role’…or something like that | 12:10 |
| henrynash | samuelms: and if we are really going to get carried away, you would just make this attributes of teh service entity in the keystone db :-) | 12:12 |
| *** vsilva_ has quit IRC | 12:12 | |
| samuelms | henrynash, :DDD | 12:14 |
| samuelms | henrynash, totally agree | 12:14 |
| samuelms | henrynash, so let's close this point and start the last one I thought :p | 12:14 |
| samuelms | henrynash, suppose now we're in the future and we've all this implemented | 12:14 |
| henrynash | samulems: so a ne service could register themslevs, their services and egt going…all via REST ! | 12:14 |
| samuelms | henrynash, exactly | 12:15 |
| henrynash | samuelms: ok, back to reality | 12:15 |
| samuelms | henrynash, haha .. wait | 12:15 |
| samuelms | henrynash, just the last point | 12:15 |
| samuelms | henrynash, suppose we're in a future where we've all this implemented, ok? | 12:15 |
| samuelms | henrynash, this morning adam will come with his idea of hierarchical roles .. | 12:15 |
| samuelms | henrynash, how do we implement that? | 12:15 |
| samuelms | henrynash, answer: domain-role (role groups) composition | 12:16 |
| samuelms | henrynash, as I told you earlier | 12:16 |
| henrynash | samuelms: yes, you can inherit domain-roles up and down the tree…and can include a domain-role from a parent in one of your domain-roles | 12:17 |
| samuelms | henrynash, exactly ! :D | 12:17 |
| samuelms | henrynash, now we can get back to the reality | 12:17 |
| samuelms | henrynash, where I'll write a etherpad clarifying this proposal and listing all the points :) | 12:18 |
| samuelms | henrynash, ok? | 12:18 |
| henrynash | samulems: have to be careful on naming…we need a way of refering, by name, to a domain-group that was created in a parent name space who’s “simple name” might clash with one of yours | 12:18 |
| samuelms | henrynash, ok | 12:18 |
| samuelms | henrynash, I'll request your review before exposing it to everybody | 12:18 |
| henrynash | samuelms: ok! | 12:18 |
| samuelms | henrynash, to avoid confusing people with naming :) | 12:19 |
| samuelms | henrynash, I think I will use the spec template .. | 12:19 |
| henrynash | ok | 12:19 |
| ekarlso- | https://review.openstack.org/#/c/130159/ - anyone know why that's failing ? | 12:21 |
| rodrigods | marekd, are you working in the dynamic checking patch? otherwise I can address the comments here and submit | 12:26 |
| *** alex_xu has joined #openstack-keystone | 12:34 | |
| *** tellesnobrega has quit IRC | 12:42 | |
| *** aix has joined #openstack-keystone | 12:42 | |
| *** jdennis has joined #openstack-keystone | 12:49 | |
| *** ekarlso- has quit IRC | 12:50 | |
| *** ekarlso- has joined #openstack-keystone | 12:50 | |
| *** afazekas has joined #openstack-keystone | 12:53 | |
| *** dims has quit IRC | 12:58 | |
| *** dims has joined #openstack-keystone | 12:58 | |
| *** kashyap has quit IRC | 13:00 | |
| *** henrynash has quit IRC | 13:00 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc https://review.openstack.org/134993 | 13:01 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Add new "RoleAssignment" exception https://review.openstack.org/133628 | 13:08 |
| *** dims has quit IRC | 13:08 | |
| *** ajayaa has quit IRC | 13:08 | |
| *** dims has joined #openstack-keystone | 13:08 | |
| *** topol has joined #openstack-keystone | 13:09 | |
| *** ChanServ sets mode: +v topol | 13:09 | |
| *** jaosorior has joined #openstack-keystone | 13:12 | |
| *** NM has joined #openstack-keystone | 13:15 | |
| *** richm has joined #openstack-keystone | 13:23 | |
| marekd | rodrigods: if you haven't started it yet i can do this. | 13:25 |
| marekd | rodrigods: was busy with sth else. | 13:25 |
| rodrigods | marekd, you can start, thanks =) | 13:28 |
| marekd | rodrigods: OK | 13:29 |
| openstackgerrit | David Chadwick proposed openstack/keystone-specs: Specification for IETF ABFAB federation https://review.openstack.org/108631 | 13:33 |
| *** ayoung-ZZZzzzZzz is now known as ayoung | 13:33 | |
| ayoung | rodrigods, samuelms so...what do you think of focusing your policy efforts on getting a single policy file that will work for all the base services? | 13:34 |
| *** nellysmitt has joined #openstack-keystone | 13:34 | |
| rodrigods | ayoung, isn't this a step for the future? | 13:35 |
| ayoung | nah | 13:35 |
| rodrigods | I mean, after we get some stuff in place first | 13:35 |
| ayoung | we can parallelize | 13:35 |
| ayoung | they can all use the same file, we just need a means to deploy it, which could be done by puppet | 13:36 |
| ayoung | https://etherpad.openstack.org/p/unified-policy | 13:36 |
| ayoung | I populated with the keystone cloud-sample to start | 13:36 |
| samuelms | ayoung, works for me | 13:36 |
| samuelms | ayoung, taking a look at the pad | 13:36 |
| ayoung | let me add in nova and glances. | 13:37 |
| ayoung | glance needs to be namespaced as I recall | 13:37 |
| rodrigods | ayoung, omg | 13:38 |
| ayoung | just added cinder at the bottom | 13:38 |
| samuelms | ayoung, what roles are you expecting to be used on that unified policy? | 13:38 |
| samuelms | ayoung, those reader, writer ones? | 13:38 |
| ayoung | samuelms, to start just member | 13:38 |
| samuelms | ayoung, ok | 13:39 |
| samuelms | ayoung, member and the default admin .. right | 13:39 |
| rodrigods | ayoung, samuelms, how well is the hierarchical roles vs group roles synchronized? | 13:39 |
| ayoung | I'm going to put in comments using # but those will need to be stripped out to be valid JSON | 13:39 |
| rodrigods | I mean, is it the same thing after all or not | 13:39 |
| ayoung | Member? Sort of.... | 13:40 |
| *** tellesnobrega has joined #openstack-keystone | 13:40 | |
| ayoung | its kindof cheating | 13:40 |
| *** tellesnobrega has quit IRC | 13:40 | |
| ayoung | right now, there are a bunch of Nova rules that accept any role for the project | 13:40 |
| ayoung | we make a rule that converts that to either member on the project or admin on the project to start | 13:41 |
| marekd | what do we have, in general, in service catalog - objects? entities? | 13:41 |
| marekd | entries? | 13:41 |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Remove middleware architecture doc https://review.openstack.org/127081 | 13:42 |
| ayoung | marekd, the entities in the service catalog are services, with endpoints scoped below them | 13:42 |
| marekd | ayoung: ok | 13:43 |
| marekd | ayoung: and, something like identity_provider in Keystone is what? | 13:43 |
| marekd | what's the good name to call such things? | 13:43 |
| marekd | objects? | 13:43 |
| samuelms | ayoung, omg .. that nova policy lol | 13:43 |
| marekd | entities? | 13:43 |
| rodrigods | ayoung, samuelms, it hurts my eyes every time I open that json file | 13:44 |
| rodrigods | 300+ rules | 13:44 |
| *** richm has quit IRC | 13:44 | |
| samuelms | ayoung, rodrigods do you have a link for the unified policy spec? (we have one, right?) | 13:45 |
| rodrigods | hmm | 13:45 |
| rodrigods | samuelms, just a sec | 13:45 |
| ayoung | samuelms, yeah, one sec | 13:45 |
| rodrigods | https://review.openstack.org/#/c/134656/ | 13:45 |
| rodrigods | ayoung, I won \o/ | 13:45 |
| samuelms | haha | 13:45 |
| samuelms | rodrigods, thanks | 13:45 |
| ayoung | yes. yes you did. | 13:45 |
| ayoung | I wonder if we can make a rule that will get ignored just to use for comments | 13:46 |
| rodrigods | ayoung, good workaround | 13:47 |
| ayoung | like "identity:aaa-header-aaa" :"" | 13:47 |
| ayoung | gonna do that | 13:47 |
| rodrigods | or "comment: ..." | 13:47 |
| ayoung | rodrigods, I want to be able to sort the file by ABC order | 13:48 |
| ayoung | with the exception of the common rules | 13:48 |
| ayoung | and I think each rule needs to be unique. | 13:48 |
| rodrigods | ayoung, why not by service? | 13:48 |
| ayoung | rodrigods, yes, by services | 13:48 |
| rodrigods | by services and ABC | 13:49 |
| ayoung | each rule should be prefixed by the service name, like "identity:create_endpoint" | 13:49 |
| rodrigods | hmm, true | 13:49 |
| samuelms | ayoung, great | 13:49 |
| rodrigods | so "identity:COMMENT" | 13:50 |
| rodrigods | ? | 13:50 |
| rodrigods | something to catch the eyes for the reader | 13:50 |
| rodrigods | of* | 13:50 |
| samuelms | rodrigods, the problem is that we cant repeat that | 13:50 |
| ayoung | rodrigods, samuelms before you make any changes to the pad, make sure there is a saved revision. | 13:50 |
| rodrigods | samuelms, so we add As or Bs or 1s or 2s | 13:50 |
| ayoung | I just did the initial one | 13:50 |
| ayoung | rodrigods, only for comments | 13:51 |
| samuelms | ayoung, neutron and glance are the only services that have no prefix on API operations | 13:51 |
| ayoung | yeah, but some of the others have multiple, and there might be conflicts | 13:52 |
| rodrigods | samuelms, do have the link from afaranha patches there? | 13:52 |
| samuelms | ayoung, so we should add image:: for glance and network:: for neutron? | 13:52 |
| samuelms | rodrigods, yes .. just a sec | 13:52 |
| ayoung | cinder has "backeup": for example | 13:52 |
| ayoung | and nova has a bunch that start with volume | 13:53 |
| ayoung | and network | 13:53 |
| *** jistr has joined #openstack-keystone | 13:53 | |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Service Provider for K2K https://review.openstack.org/135604 | 13:53 |
| *** jistr is now known as jistr|mtg | 13:53 | |
| rodrigods | ayoung, why not just add the service name? | 13:53 |
| samuelms | rodrigods, ++ | 13:54 |
| ayoung | rodrigods, heh, you used the word "just" | 13:54 |
| ayoung | do you really think *just* adding the service name would be simple? | 13:54 |
| rodrigods | marekd, omg, you're fast =) | 13:54 |
| rodrigods | marekd, could you add me as contributor? You know I'm interested on it =) | 13:55 |
| samuelms | ayoung, rodrigods err.. maybe after we can rename them after .. | 13:55 |
| marekd | rodrigods: yes, i can add you | 13:55 |
| samuelms | ayoung, rodrigods for now, lets just find a name for cinder and neutron | 13:55 |
| marekd | i will in the following patch, ok? | 13:55 |
| rodrigods | samuelms, ayoung, the name: cinder and neutron | 13:55 |
| marekd | this will probably fail | 13:55 |
| rodrigods | marekd, ++ | 13:55 |
| ayoung | sed 's!just!first!g' | 13:55 |
| ayoung | so cinder should be 'volume' and neutron should be 'network' | 13:56 |
| samuelms | ayoung, rodrigods ok then .. lets --just-- FIRTS do the work renaming them | 13:56 |
| ayoung | so I think maybe we first steal those back from nova | 13:56 |
| ayoung | we could make nova's network into compute_network | 13:57 |
| ayoung | and volume into compute_volume | 13:57 |
| samuelms | ayoung, ++ | 13:57 |
| ayoung | and I guess volume_extension becomes compute_volume_extension | 13:58 |
| ayoung | or...better | 13:58 |
| ayoung | we make nova's network into compute:network | 13:58 |
| ayoung | looks like that is what neutron is doing already | 13:59 |
| ayoung | create_network:provider:physical_network | 13:59 |
| samuelms | ayoung, and compute:volume ? | 13:59 |
| rodrigods | ayoung, samuelms ++ | 13:59 |
| rodrigods | was my next suggestion | 13:59 |
| ayoung | I wonder if we could convince neutron to conver create_network into network:create:.... | 14:00 |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Correct Session docstring https://review.openstack.org/127805 | 14:00 |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Correct documenting constructor parameters https://review.openstack.org/127812 | 14:00 |
| samuelms | ayoung, if they believe on unified-policy, why not? | 14:00 |
| rodrigods | ayoung, /join #openstack-neutron | 14:00 |
| ayoung | yes. IF | 14:00 |
| rodrigods | ayoung, thought we were about to ask the people over there ¬¬ | 14:01 |
| samuelms | ayoung, can I start adding the network: prefix for neutron api? | 14:01 |
| samuelms | done | 14:05 |
| rodrigods | ayoung, can you add a nice HM patch to your reviews list? | 14:07 |
| rodrigods | https://review.openstack.org/#/c/117786/ | 14:07 |
| *** chrisshattuck has joined #openstack-keystone | 14:08 | |
| ayoung | rodrigods, it now has a star | 14:08 |
| samuelms | ayoung, maybe an issue with the way we're doing this (the policy) is that we are now lefting breadscrumbs .. | 14:09 |
| samuelms | ayoung, what has changed from the original policy for each service | 14:09 |
| samuelms | rodrigods, ^ | 14:09 |
| *** ajayaa has joined #openstack-keystone | 14:10 | |
| *** joesavak has joined #openstack-keystone | 14:10 | |
| rodrigods | ayoung, ++ | 14:10 |
| ayoung | bknudson, https://review.openstack.org/#/c/126897/ could use a review. | 14:11 |
| ayoung | its been 3 weeks at +2 | 14:11 |
| bknudson | that's my fault? | 14:12 |
| openstackgerrit | Merged openstack/keystone-specs: IETF ABFAB federation protocol. https://review.openstack.org/134549 | 14:12 |
| *** chrisshattuck has quit IRC | 14:13 | |
| rodrigods | can I point to a oslo blueprint in a Keystone spec? | 14:13 |
| *** richm has joined #openstack-keystone | 14:14 | |
| *** richm has left #openstack-keystone | 14:14 | |
| *** richm has joined #openstack-keystone | 14:14 | |
| ekarlso- | anyone that can help me with https://review.openstack.org/#/c/130159/ client change ? It's been stuck in there for a while :( | 14:15 |
| samuelms | ayoung, for volume, we left volume_extension: ? | 14:16 |
| samuelms | ayoung, or the idea would be to have everything there starting with volume? | 14:16 |
| ayoung | samuelms, no matter what we do it is going to cause some churn | 14:17 |
| samuelms | ayoung, rodrigods I think we should put that in a git repo | 14:18 |
| ayoung | ++ | 14:18 |
| samuelms | ayoung, rodrigods so that we start from the basic structure | 14:18 |
| samuelms | and keep track of the changes | 14:18 |
| samuelms | :) | 14:18 |
| rodrigods | samuelms, ++ | 14:18 |
| rodrigods | omg, split assignments is going first than HM | 14:19 |
| rodrigods | rebase hell | 14:19 |
| marekd | rodrigods: ++ | 14:19 |
| marekd | rodrigods: you will be sure you really undestand the code :P | 14:19 |
| rodrigods | marekd, =P | 14:21 |
| samuelms | ayoung, are you going to create the repo on your github account? or can I do this? | 14:23 |
| ayoung | samuelms, go ahead. I'll let you guys drive this. | 14:24 |
| samuelms | ayoung, ok thanks | 14:24 |
| *** gordc has joined #openstack-keystone | 14:28 | |
| *** openstackgerrit has quit IRC | 14:33 | |
| *** openstackgerrit has joined #openstack-keystone | 14:33 | |
| ayoung | samuelms, I want a version of etherpad backed by git | 14:39 |
| *** alex_xu has quit IRC | 14:39 | |
| rodrigods | ayoung, can I point to a oslo blueprint in a Keystone spec? Also... The graduation template has a "Secutiry Contact" area, which I'm not sure if I can put myself there | 14:41 |
| *** nellysmitt has quit IRC | 14:41 | |
| *** amakarov_away is now known as amakarov | 14:41 | |
| *** r-daneel has joined #openstack-keystone | 14:42 | |
| samuelms | ayoung, ok .. I'll commit the first version as being only the policies pasted there .. | 14:42 |
| samuelms | ayoung, and the second as it is right now | 14:42 |
| samuelms | samuelms, haha .. misunderstood what you said :P it should be great to have an etherpad plugin to that | 14:45 |
| samuelms | ayoung, ^ | 14:45 |
| *** jdennis has quit IRC | 14:48 | |
| rodrigods | ayoung, thinking about using the keystone-spec anyway = | 14:48 |
| rodrigods | template* | 14:48 |
| ayoung | rodrigods, " can I point to a oslo blueprint in a Keystone spec? " not sure what | 14:49 |
| ayoung | that would imply | 14:49 |
| ayoung | I know there is some tie in between commits and blueprint updates | 14:49 |
| rodrigods | ayoung, yeah, will use the keystone-specs template | 14:49 |
| *** openstackgerrit has quit IRC | 14:49 | |
| ayoung | k | 14:49 |
| dims | rodrigods: out of oslo's hands :) | 14:49 |
| *** openstackgerrit has joined #openstack-keystone | 14:49 | |
| rodrigods | dims, thanks! | 14:49 |
| *** jacorob has joined #openstack-keystone | 14:50 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc https://review.openstack.org/134993 | 14:54 |
| *** stevemar has joined #openstack-keystone | 14:54 | |
| *** ChanServ sets mode: +v stevemar | 14:54 | |
| rodrigods | dstanek, ^ and also https://review.openstack.org/#/c/130408/ =) | 14:55 |
| rodrigods | dstanek, thanks for the reviews so far | 14:55 |
| *** jdennis has joined #openstack-keystone | 15:00 | |
| *** nellysmitt has joined #openstack-keystone | 15:00 | |
| ayoung | rodrigods, did I do that? | 15:01 |
| *** thedodd has joined #openstack-keystone | 15:03 | |
| openstackgerrit | Endre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version https://review.openstack.org/130159 | 15:15 |
| openstackgerrit | Endre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version https://review.openstack.org/130159 | 15:15 |
| ekarlso- | ^ morganfainberg | 15:16 |
| *** marg7175 has joined #openstack-keystone | 15:19 | |
| morganfainberg | ekarlso-, thanks | 15:19 |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Manager driver parameters support https://review.openstack.org/135622 | 15:21 |
| *** fmarco76 has joined #openstack-keystone | 15:21 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:23 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Manager driver parameters support https://review.openstack.org/135622 | 15:24 |
| *** saipandi has joined #openstack-keystone | 15:27 | |
| *** ukalifon1 has quit IRC | 15:31 | |
| dstanek | rodrigods: i'm ready to +2 the doc change once ayoung's comments are addressed | 15:31 |
| *** henrynash has joined #openstack-keystone | 15:32 | |
| *** ChanServ sets mode: +v henrynash | 15:32 | |
| lhcheng_ | hello! I'm working on a bug related to the service catalog generated between v2 and v3. For v2, the token is generated using https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L62 , can someone help me figure out the v3 version of this call? | 15:37 |
| lhcheng_ | or point me where to look :) | 15:37 |
| lhcheng_ | nevermind, found it through auth plugins | 15:44 |
| *** thedodd has quit IRC | 15:55 | |
| *** jacorob has quit IRC | 15:56 | |
| samuelms | dstanek, ayoung: rodrigods is at lunch time .. will be back soon | 15:56 |
| *** mflobo has quit IRC | 15:57 | |
| *** patrickeast has joined #openstack-keystone | 16:00 | |
| *** josecastroleon has quit IRC | 16:01 | |
| *** patrickeast has quit IRC | 16:02 | |
| *** patrickeast has joined #openstack-keystone | 16:03 | |
| * morganfainberg goes to get breakfast now. | 16:05 | |
| morganfainberg | ayoung, henrynash, dstanek, dolphm, lbragstad, gyee, topol, stevemar, jamielennox|away, bknudson, I asked ttx to turn on a feature to remove BPs from milestones if they are *not* prioritized. This mean if we're targeting a BP to a milestone make sure it has a priority | 16:06 |
| morganfainberg | the reason for this is to make sure people don't sneak BPs onto a milestone w/o us knowing | 16:06 |
| topol | morganfainberg, OK cool | 16:07 |
| bknudson | sneaky jerks | 16:07 |
| bknudson | what do we have targeted for k1? | 16:07 |
| morganfainberg | bknudson, uhm... | 16:08 |
| morganfainberg | bknudson, /me hasn't done that yet. | 16:08 |
| bknudson | I assume it's HMT | 16:08 |
| dolphm | morganfainberg: ++ | 16:08 |
| dolphm | bknudson: there's like 4 bp's | 16:08 |
| morganfainberg | and i need to go through the bugs. | 16:09 |
| bknudson | k2 is going to be a big hill to climb. | 16:09 |
| morganfainberg | bknudson, yes. | 16:09 |
| bknudson | dstanek is working on Enable tests on non-SQLite databases | 16:10 |
| bknudson | and Allow a subset of tests to fail | 16:10 |
| bknudson | and we removed all sorts of deprecated stuff... that should be done? | 16:10 |
| dstanek | bknudson: correcto | 16:11 |
| bknudson | morganfainberg: https://blueprints.launchpad.net/openstack/?searchtext=trusts-redelegation already has code, but no series | 16:13 |
| morganfainberg | bknudson, yeah | 16:13 |
| morganfainberg | thats the stuff i'm expecting to fix today | 16:13 |
| morganfainberg | or ask someone to poke at ;) | 16:14 |
| *** bdossant has joined #openstack-keystone | 16:17 | |
| *** vejdmn has joined #openstack-keystone | 16:20 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation https://review.openstack.org/131541 | 16:20 |
| *** agireud has joined #openstack-keystone | 16:21 | |
| henrynash | morganfainberg, ayoung, stevemar: gonna keep chipping away for this one! https://review.openstack.org/#/c/130954/21 | 16:21 |
| stevemar | ah the deprecation proxy, right henrynash | 16:23 |
| *** jacorob has joined #openstack-keystone | 16:25 | |
| *** afazekas has quit IRC | 16:29 | |
| *** afazekas has joined #openstack-keystone | 16:30 | |
| *** david-lyle_afk is now known as david-lyle | 16:34 | |
| ayoung | henrynash, soooooo...where do you plan on getting assignements from, once this goes in? | 16:34 |
| henrynash | ayoung: which? | 16:34 |
| ayoung | splitting off assignements from projects | 16:35 |
| ayoung | are you going to get projects exteranal from Keystone, or assignments? | 16:35 |
| henrynash | ayoung: not sure I follow | 16:35 |
| ayoung | what are you hoping to gain from splitting assignments and resources? | 16:35 |
| henrynash | ayoung: I’m sure you are asking a deep and meaningful question….I’m just struggling | 16:36 |
| ayoung | Do you expect either to consume something from outside of Keystone? | 16:36 |
| henrynash | ayoung: so two reasons: better and easier code (so easier to maintain)…and allowing alternative assignments models to be attempted which don;t have to re-implement roles/domains/rpojects | 16:37 |
| ayoung | henrynash, "allowing alternative assignments models" like what? | 16:37 |
| ayoung | do you have one already? Guessing that you do, just wondering what it is | 16:37 |
| henrynash | ayoung: like an ABAC engine…or the thing that University of Texas is building etc. | 16:38 |
| henrynash | ayoung: me, no I don;t have one | 16:38 |
| ayoung | then why are you prioritizing it? | 16:38 |
| henrynash | ayoungL or something Dr Cahdwick might have etc. | 16:38 |
| ayoung | henrynash, what I was thinking was this | 16:39 |
| *** nellysmitt has quit IRC | 16:39 | |
| ayoung | there are things out there, hierarchical, that might map to the project/domain hierarchy | 16:39 |
| henrynash | ayoung: because our code is a mess and doing the split let me find 5 new bugs and we need a better, more stable base to land MT and other changes in | 16:39 |
| ayoung | and I was wondering if you were looking to integrate something like LDAP based hostgroups to do the project thing, or if it was the assignment side that you were thinking to consume....something else | 16:40 |
| stevemar | henrynash, that was a great answer :) | 16:40 |
| lbragstad | bknudson: curious if you'd be able to take a look at https://review.openstack.org/#/c/125738/ since you had +2'd it previously | 16:41 |
| lbragstad | dstanek: was look at ^ as well. | 16:41 |
| lbragstad | the tempest change has a +2 | 16:41 |
| ayoung | henrynash, I see you as devious and strategic. You've slipped in killer features almost under the radar. I'm really just wondering what you have cooking.... | 16:41 |
| lbragstad | https://review.openstack.org/#/c/126564/ | 16:41 |
| bknudson | lbragstad: it doesn't pass jenkins | 16:41 |
| lbragstad | bknudson: it requires a change to tempest | 16:42 |
| lbragstad | tempest core wants to see that it has a +2 | 16:42 |
| henrynash | ayoung: so I hadn’t considered anything explicit in terms of projects…..but conceptualluy the idea was to separate (as I say in the spec) the lingua franca that the rest of OpenStack undestands (e.g. projects and roles), from athe (keystone internal) assignment model…so if we want something that maps projecst to something external - cool..it only affects resource, and the assignment model code is never touched etc. | 16:42 |
| lbragstad | before they merge the change to tempest | 16:42 |
| bknudson | ok... I already +2d it. | 16:42 |
| ayoung | lbragstad, I can +2 as well | 16:43 |
| henrynash | ayoung: I;ll take at least one of those adjectives as a compliment :-)…. | 16:44 |
| lbragstad | bknudson: ayoung thanks, tempest has approved the corresponding change to tempest | 16:44 |
| ayoung | henrynash, actually, I was wondering if you had some 3rd party system that you needed to integrate | 16:44 |
| lhcheng_ | lbragstad: question on https://bugs.launchpad.net/keystone/+bug/1393518 | 16:44 |
| uvirtbot | Launchpad bug 1393518 in keystone "v3 service catalog returns services without names, but v2.0 api does not" [Medium,Triaged] | 16:44 |
| ayoung | henrynash, cuz I am starting to think in those terms myself | 16:45 |
| lhcheng_ | lbragstad: should the name attribute still be included if its empty? | 16:45 |
| *** gyee has joined #openstack-keystone | 16:45 | |
| *** ChanServ sets mode: +v gyee | 16:45 | |
| henrynash | ayoung: I don’t…but I do see those requests…and it seems the right tragectory in terms of “keystone as a wrapper” for corporate/federated information providers | 16:45 |
| *** fmarco76 has left #openstack-keystone | 16:46 | |
| *** vejdmn has quit IRC | 16:46 | |
| henrynash | ayoung: a wrapper is really hard if it covers too many concepts (that may come from different sources) | 16:46 |
| morganfainberg | henrynash, ++ | 16:46 |
| ayoung | henrynash, right. So the thing I was wondering is if it makes sense to think in terms of plugging in a projects backend for each domain | 16:47 |
| henrynash | ayoung: “Keystone is a (w)rapper”…I can see the T-shirts already | 16:47 |
| lbragstad | lhcheng_: I'd like to get jamielennox|away 's perspective on it (from dolphm's comment in the bug) | 16:47 |
| lbragstad | if jamielennox|away has does some work to it, he could add some perspective. | 16:48 |
| *** vejdmn has joined #openstack-keystone | 16:48 | |
| morganfainberg | ayoung, i'd be worried about jumping too far down that path to start, but... it doesn't sound absurd | 16:48 |
| henrynash | ayoung: yeah…I had wondered about that (in the shower, as one does)…akin to what we did with identity | 16:48 |
| lhcheng_ | lbragstad, okay I found the bug. Just need to confirm the expected behavior if we want to display or not | 16:48 |
| dolphm | lbragstad: lhcheng_: it'll probably be 5-7 hours before jamielennox|away logs on | 16:49 |
| lhcheng_ | lbragstad, I'll try to catch jamielennox|away later | 16:49 |
| henrynash | ayoung: though it brings us back to the LDAP RO vs RW question…if we have pure RW we can write our own schema (to contain domain)…but for RO….it maybe makes sense | 16:49 |
| dolphm | lhcheng_: yes, it should be included in the v3 response | 16:49 |
| ayoung | morganfainberg, henrynash so what I was thinking was in terms of FreeIPA HBAC and SUDO rules. It doesn't quite align with what we are doing, but it allows an external source to manage access and elevation of privs. It would be a decent approach if each project mapped to a hostgroup in an FreeIPA deployment | 16:49 |
| dolphm | lhcheng_: are you seeing it missing on a stable branch, or master? | 16:49 |
| henrynash | (offline for a few minutes) | 16:49 |
| morganfainberg | ayoung, lets be careful about locking in the *need* for FreeIPA | 16:49 |
| ayoung | So, yeah, for projects, I would want to make that either Read Only, or to look closer at how we create objects on the FreeIPA side | 16:50 |
| ayoung | morganfainberg, not a Need...a possibility | 16:50 |
| morganfainberg | ayoung, but supporting that isn't awful. again, i'd be worried about trying to do too much at once this cycle | 16:50 |
| ayoung | morganfainberg, hostgroups and netgroups are already supportable in LDAP | 16:50 |
| morganfainberg | this is something i might say we backlog to start, finish what we have on deck and see about adding in that support for | 16:50 |
| ayoung | morganfainberg, nah, I'm trying to see if we are even headed in that tragectory | 16:50 |
| lhcheng_ | dolphm: I'm testing on master. If the service name has a value, it is included in the response. If it is empty, the "name" attribute is not included in the response. | 16:50 |
| *** _cjones_ has joined #openstack-keystone | 16:51 | |
| morganfainberg | if it makes sense as we see everything else matierialize | 16:51 |
| dolphm | lhcheng_: i didn't realize services could be missing names! | 16:51 |
| morganfainberg | dolphm, :( yeah | 16:51 |
| *** agireud has quit IRC | 16:51 | |
| lhcheng_ | dolphm: it is optional based on the specs | 16:51 |
| ayoung | morganfainberg, I was just trying to see if other companies are already thinking along those lines....starting with the big one that henrynash is working for.... | 16:51 |
| dolphm | well that's fun. i knew there was no uniqueness constraint, but boo | 16:51 |
| *** agireud has joined #openstack-keystone | 16:52 | |
| ayoung | or yours.... | 16:52 |
| morganfainberg | ayoung, afaik we (the one i work for) are not looking at that | 16:52 |
| morganfainberg | but... i can't say with certainty that we wouldn't be interested in it | 16:52 |
| * morganfainberg breaks fast | 16:52 | |
| morganfainberg | be back soonish | 16:52 |
| *** jaosorior has quit IRC | 16:53 | |
| ayoung | morganfainberg, change of subject... the thing we wer talking about last night, that policy is going to consume...context or toekn or whatever we call it | 16:53 |
| ayoung | I kindof need to get started on something along those lines myself | 16:53 |
| ayoung | here's what I am working on: | 16:53 |
| dolphm | i think i missed that, but a policy enforcement engine should totally be able to utilize the entire authorization context (including request attributes, etc) | 16:54 |
| ayoung | lets say you do SAML to Horizon (or some other godforesaken server side scripted UI in rails..) | 16:54 |
| lhcheng_ | dolphm: so yeah, not sure what is the API standard response for that. Hide the "name" attribute if it is empty, or have it returned as "name":null. | 16:54 |
| ayoung | and doing a redirect to Keystone in order to do a redirect to the SAML IdP is not acceptable for whatever reason.... | 16:54 |
| dolphm | lhcheng_: we default a lot of "null" strings to empty strings (like descriptions) | 16:54 |
| ayoung | to cut to the chase, Horizon needs to get a token for the user using nothing but the SAML assertion | 16:55 |
| dolphm | lhcheng_: i'd rather see data type consistency, so i'd favor an empty string name | 16:55 |
| ayoung | so I wrote a horrible proof of concept that lets a service user impersonate a real user to get a token. I want as a next step to lock this down to a policy check | 16:55 |
| lhcheng_ | dolphm: cool, that works. From a consumer perspective (like horizon), I rather see the "name" to always be there. | 16:55 |
| ayoung | but...I don't want the service user to have to get a token first | 16:56 |
| dolphm | ayoung: that sounds like it's defeating federation? | 16:56 |
| ayoung | this is the slippery slope leading to token-less operations | 16:56 |
| dolphm | lhcheng_: ++ | 16:56 |
| ayoung | dolphm, yes, yes it is....sort of | 16:56 |
| ayoung | dolphm, it means that we are doing a deploiyment where we trust horizon as much as keystone | 16:56 |
| lhcheng_ | dolphm: thanks for the input! I'll check with jamielennox|away later if he has some work overlapping with the bug. | 16:56 |
| *** k4n0 has quit IRC | 16:56 | |
| ayoung | and I want to at least limit the damage that can be done with that assumption | 16:56 |
| ayoung | dolphm, with Kerberos and S4U2 Proxy you have the minimal check that the user actually requested something from Horizon within the timeout of the service ticket. Ideally, this would be no less secure than that | 16:58 |
| ayoung | IE. Horizon would need to send the whole SAML assertion to Keystone. Add to that the service user check | 16:58 |
| ayoung | and use that to get a token | 16:58 |
| ayoung | I'm going to go at it in increments, but the first thing should be getting policy workable in tokenless mode | 16:59 |
| ayoung | which means I need to be able to do a policy check from inside keystone with no token | 16:59 |
| ayoung | so I was thinking along the lines of using the same internal representation of the token data that morganfainberg is going to be building for the token provider cleanup | 17:00 |
| *** jsavak has joined #openstack-keystone | 17:03 | |
| *** diegows has quit IRC | 17:03 | |
| ayoung | morganfainberg, so, I was wondering if you have a prototype of the canonical token-data-context or if I should make a stab at it? | 17:04 |
| *** joesavak has quit IRC | 17:04 | |
| *** joesavak has joined #openstack-keystone | 17:05 | |
| *** patrickeast has quit IRC | 17:05 | |
| *** marg7175 has quit IRC | 17:07 | |
| *** jsavak has quit IRC | 17:07 | |
| *** jsavak has joined #openstack-keystone | 17:08 | |
| *** marg7175 has joined #openstack-keystone | 17:09 | |
| *** marg7175_ has joined #openstack-keystone | 17:10 | |
| *** joesavak has quit IRC | 17:10 | |
| *** NM has quit IRC | 17:10 | |
| *** NM has joined #openstack-keystone | 17:10 | |
| *** marg7175_ has quit IRC | 17:10 | |
| *** marg7175_ has joined #openstack-keystone | 17:11 | |
| *** marg7175_ has quit IRC | 17:11 | |
| *** marg7175 has quit IRC | 17:11 | |
| *** marg7175 has joined #openstack-keystone | 17:12 | |
| *** marcoemorais has joined #openstack-keystone | 17:16 | |
| samuelms | ayoung, https://github.com/samuel-ms/os.unified.policy | 17:20 |
| samuelms | ayoung, will work more on this tonight | 17:20 |
| ayoung | samuelms, thank you | 17:20 |
| ayoung | samuelms, can you put a common section at the top? | 17:21 |
| ayoung | samuelms, also, note that "admin_or_owner" is defined by both keystone and nova. the Nova one is misnamed; it does not check that the user is the owner so much as that the user has some role on the project | 17:21 |
| ayoung | I'd rename the nova one to something like | 17:22 |
| ayoung | user_in_project | 17:22 |
| *** packet has joined #openstack-keystone | 17:22 | |
| ayoung | samuelms, but good start | 17:23 |
| samuelms | ayoung, ok .. took these notes .. will apply soon | 17:24 |
| samuelms | ayoung, thanks | 17:24 |
| ayoung | samuelms, thanks for taking this on | 17:24 |
| samuelms | ayoung, np :) | 17:24 |
| ayoung | samuelms, can you look to see if there are any other duplicates? | 17:24 |
| samuelms | ayoung, sure | 17:24 |
| samuelms | ayoung, what do you mean by the common section at the top? | 17:25 |
| ayoung | samuelms, there are common rules, like is_admin | 17:25 |
| ayoung | the service specific sections stay as is, but the rules that they use get moved to the top | 17:26 |
| samuelms | ayoung, aah .. it s what we just talked about :) | 17:27 |
| ayoung | ++ | 17:27 |
| samuelms | ayoung, once I have a new version I'll ping | 17:27 |
| ayoung | sounds good | 17:27 |
| samuelms | ayoung, will ping you (not a naked one) | 17:27 |
| samuelms | :p | 17:27 |
| ayoung | :) | 17:27 |
| *** ajayaa has quit IRC | 17:29 | |
| *** marcoemorais has quit IRC | 17:33 | |
| *** marcoemorais has joined #openstack-keystone | 17:34 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc https://review.openstack.org/134993 | 17:34 |
| *** marcoemorais has quit IRC | 17:34 | |
| ayoung | nkinder, dolphm had a point that the "let a service user get a token for a real user" approach means that we bypass all of the mapping. Would it make sense to have a second round that would let horizon or some other keystoneclient consumer perform the mapping external to Keystone itself? | 17:36 |
| *** marcoemorais has joined #openstack-keystone | 17:36 | |
| *** thedodd has joined #openstack-keystone | 17:36 | |
| *** links has quit IRC | 17:37 | |
| ayoung | either we do the mapping in Horizon, or we send the assertion to Keystone to do the mapping | 17:37 |
| nkinder | ayoung: the latter sounds better, though I need to think about it more | 17:39 |
| ayoung | nkinder, I like the former | 17:39 |
| nkinder | ayoung: why duplicate mapping logic/code in Horizon? | 17:39 |
| ayoung | it allows offloading the work | 17:39 |
| *** topol has quit IRC | 17:39 | |
| ayoung | not duplicate | 17:39 |
| *** RichardRaseley has joined #openstack-keystone | 17:39 | |
| ayoung | extract out the mapping code into KC | 17:40 |
| nkinder | ayoung: so what does Horizon map to? | 17:40 |
| ayoung | its exactly the same set of steps I outlined for distributed signing.... | 17:40 |
| *** topol has joined #openstack-keystone | 17:40 | |
| *** ChanServ sets mode: +v topol | 17:40 | |
| nkinder | ayoung: Keep in mind that mapping currently is designed to map to keystone group(s) | 17:40 |
| ayoung | nkinder, horizon fetches the mapping from keystone and caches it | 17:40 |
| ayoung | in theory, Horizon could go as far as actually signing the token if we wanted | 17:41 |
| nkinder | I don't like that approach | 17:41 |
| nkinder | we want to take power away from Horizon, not make it all-powerful | 17:41 |
| nkinder | If it can sign tokens, it can mint whatever tokens it wants | 17:41 |
| ayoung | no matter what it is going to be limited | 17:41 |
| ayoung | yeah, but... | 17:41 |
| ayoung | we can limite the tokens it can mint | 17:42 |
| * lbragstad starts listening to "Take The Power Back" - RATM | 17:42 | |
| ayoung | for example, it could only sign for unscoped tokems | 17:42 |
| ayoung | tokens | 17:42 |
| nkinder | lbragstad: makes me want to pick up my bass... :) | 17:43 |
| ayoung | the other services would not accept them as valid. Only Keystone | 17:43 |
| lbragstad | nkinder: :) makes me want to invest in a bass | 17:43 |
| ayoung | I've got a bass. | 17:45 |
| ayoung | It would even work with AE tokens....if you shared the key between horizon and keystone | 17:46 |
| nkinder | ayoung: if we want Keystone to be able to validate the assertion that is forwarded on by Horizon (signature, issuance date, matching user), it could also just do the mapping | 17:46 |
| nkinder | ayoung: in fact, there is a change to allow the mapped methods to be configurable that is out for review right now | 17:47 |
| ayoung | link? | 17:47 |
| nkinder | ayoung: https://review.openstack.org/#/c/133130/ | 17:48 |
| nkinder | ayoung: that came out of some discussions that stevemar and I had at the summit when he was working on OpenID Connect support, and rodrigods picked it up | 17:48 |
| *** harlowja_away is now known as harlowja | 17:51 | |
| rodrigods | nkinder, need to address the comments, btw | 17:51 |
| *** marekd is now known as marekd|away | 17:51 | |
| * rodrigods if marekd don't send a new patchset until I arrive at home, will update it | 17:51 | |
| *** zzzeek has joined #openstack-keystone | 17:53 | |
| rodrigods | morganfainberg, not sure if the tests failing in the HM patch is a signal for a new rebase | 17:53 |
| openstackgerrit | Andre Aranha proposed openstack/keystone-specs: Modify the policy file https://review.openstack.org/135408 | 17:54 |
| *** vejdmn has quit IRC | 17:54 | |
| *** jsavak has quit IRC | 17:55 | |
| *** jsavak has joined #openstack-keystone | 17:55 | |
| *** vejdmn has joined #openstack-keystone | 17:56 | |
| morganfainberg | rodrigods, there was a really awful testools bug that broke *everyone* | 17:56 |
| marekd|away | rodrigods: you can upload | 17:57 |
| *** aix has quit IRC | 17:57 | |
| *** thedodd has quit IRC | 17:59 | |
| *** marcoemorais has quit IRC | 18:01 | |
| *** marcoemorais has joined #openstack-keystone | 18:02 | |
| *** RichardRaseley has quit IRC | 18:05 | |
| marekd|away | topol: thanks for the review, appreciate it! | 18:05 |
| *** _cjones_ has quit IRC | 18:05 | |
| *** _cjones_ has joined #openstack-keystone | 18:06 | |
| topol | marekd, your welcome. looks very useful! | 18:06 |
| rodrigods | morganfainberg, quick question: do I need to create a new bp for the policy lib or should I reference the oslo one:https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-policy ? | 18:06 |
| *** patrickeast has joined #openstack-keystone | 18:06 | |
| morganfainberg | hm. | 18:07 |
| *** patrickeast has left #openstack-keystone | 18:07 | |
| morganfainberg | we can probably retarget that one to keystone | 18:07 |
| morganfainberg | *shrug* | 18:07 |
| morganfainberg | i don't think it matters | 18:07 |
| rodrigods | morganfainberg, hmm ok | 18:08 |
| *** links has joined #openstack-keystone | 18:10 | |
| *** __TheDodd__ has joined #openstack-keystone | 18:20 | |
| *** jaosorior has joined #openstack-keystone | 18:25 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only) https://review.openstack.org/115770 | 18:30 |
| *** marcoemorais has quit IRC | 18:32 | |
| *** marcoemorais has joined #openstack-keystone | 18:33 | |
| *** marcoemorais has quit IRC | 18:34 | |
| *** marcoemorais has joined #openstack-keystone | 18:34 | |
| *** __TheDodd__ has quit IRC | 18:34 | |
| *** marcoemorais has quit IRC | 18:34 | |
| *** marcoemorais has joined #openstack-keystone | 18:35 | |
| *** links has quit IRC | 18:35 | |
| *** raildo_away is now known as raildo | 18:36 | |
| *** radez_g0n3 is now known as radez | 18:44 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Manager driver parameters support https://review.openstack.org/135622 | 18:44 |
| dolphm | morganfainberg: any idea why the gate is having issues? | 18:45 |
| dolphm | (today) | 18:45 |
| morganfainberg | dolphm, not sure about today | 18:45 |
| bknudson | who's our QA liaison? | 18:45 |
| morganfainberg | i know what ... yesterday was? | 18:45 |
| morganfainberg | day before | 18:46 |
| morganfainberg | testtools 1.something broke tons of things | 18:46 |
| dolphm | something new today | 18:46 |
| dolphm | nothing standing out on elastic-recheck | 18:46 |
| bknudson | the neutron errors? | 18:46 |
| morganfainberg | dolphm, not seeing anything on the radar in -infra or -qa atm | 18:46 |
| morganfainberg | bknudson, dstanek is | 18:47 |
| *** packet has quit IRC | 18:49 | |
| *** dnalezyt has joined #openstack-keystone | 18:50 | |
| *** zzzeek has quit IRC | 18:50 | |
| *** sigmavirus24 has left #openstack-keystone | 18:51 | |
| lbragstad | dolphm: I saw this get pushed ot e-r earlier: https://review.openstack.org/#/c/135654/ | 18:52 |
| lbragstad | to* | 18:52 |
| dolphm | lbragstad: oh, that sounds nasty | 18:53 |
| dolphm | anyone know dave walker's irc handle? | 18:53 |
| lbragstad | dolphm: https://bugs.launchpad.net/openstack-ci/+bug/1365046 | 18:53 |
| uvirtbot | Launchpad bug 1365046 in openstack-ci "Job failed due to no devstack directory" [Undecided,Confirmed] | 18:53 |
| lbragstad | it's dead Jim | 18:53 |
| dolphm | devstack failed due to significant lack of devstack | 18:54 |
| *** toddnni has joined #openstack-keystone | 18:58 | |
| *** dims has quit IRC | 19:01 | |
| *** zzzeek has joined #openstack-keystone | 19:02 | |
| *** chrisshattuck has joined #openstack-keystone | 19:03 | |
| *** packet has joined #openstack-keystone | 19:03 | |
| *** marcoemorais has quit IRC | 19:04 | |
| *** jorge_munoz has joined #openstack-keystone | 19:04 | |
| *** marcoemorais has joined #openstack-keystone | 19:04 | |
| *** diegows has joined #openstack-keystone | 19:05 | |
| *** thedodd has joined #openstack-keystone | 19:05 | |
| *** jsavak has quit IRC | 19:17 | |
| *** jsavak has joined #openstack-keystone | 19:17 | |
| *** jorge_munoz has quit IRC | 19:18 | |
| dolphm | ayoung: just got asked to proof a paragraph from a blog post going up on developer.rackspace.com about deploying keystone behind httpd :) | 19:19 |
| *** jorge_munoz has joined #openstack-keystone | 19:19 | |
| morganfainberg | woot | 19:19 |
| openstackgerrit | Merged openstack/keystone: Enable cloud_admin to list projects in all domains https://review.openstack.org/134111 | 19:22 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 19:22 |
| openstackgerrit | Merged openstack/keystone: Remove string from URL in list_revoke_events() https://review.openstack.org/130408 | 19:22 |
| openstackgerrit | Merged openstack/keystone: Update references to auth_token middleware. https://review.openstack.org/132369 | 19:22 |
| openstackgerrit | Merged openstack/keystone: Configuring Keystone edits https://review.openstack.org/131318 | 19:24 |
| *** amakarov is now known as amakarov_away | 19:24 | |
| bknudson | marekd|away: on https://review.openstack.org/#/c/133130/ you were wondering how old tests were passing -- maybe this answers it: https://review.openstack.org/#/c/124603/ | 19:26 |
| ayoung | dolphm, excellent. I was recently rereading the origianal post I followed for Nova on that topic: http://www.rackspace.com/blog/author/jason-cannavale/ | 19:30 |
| ayoung | dolphm, I heard from the eNovance team that they deploy all of the OpenStack services that way | 19:31 |
| EmilienM | o/ | 19:34 |
| EmilienM | ayoung: it's WIP, but yes | 19:34 |
| ayoung | EmilienM, that is freaking AWESOME! | 19:34 |
| * ayoung does a little happy dance | 19:35 | |
| EmilienM | \o/ | 19:35 |
| ayoung | EmilienM, wrt to V3...its really not Keystone the server that is the issue | 19:37 |
| ayoung | right now, we know that it works to do V3 everywhere, but the auth_token middleware piece still needs a patch to get it to let the service user not be in the default domain | 19:37 |
| ayoung | how we want it to work is this | 19:37 |
| ayoung | do your install with service users going in to SQL | 19:38 |
| ayoung | now create a domain for your LDAP based users | 19:38 |
| EmilienM | richm: fyi ^ | 19:38 |
| ayoung | switch the default domain from the service domain to the LDAP backed one | 19:38 |
| richm | right | 19:38 |
| ayoung | in order to make that work, auth_token needs to explicitly request things from the non-default domain. Which means V3 APIs | 19:39 |
| ayoung | let me see where those patches are currently | 19:39 |
| richm | ayoung: is it possible to have a "trustor" in the default LDAP identity backend/domain, and have the "trustee" be in the sql services identity backend/domain? | 19:39 |
| ayoung | https://review.openstack.org/#/c/130534/ I think that commit is right in the middle of the chain | 19:40 |
| ayoung | richm, yes | 19:40 |
| ayoung | trusts can span domains, no problem | 19:40 |
| richm | so you can have "cross domain trusts" - ok | 19:40 |
| EmilienM | ayoung: my first concern if about the v2 deployments that we have, can I expose v3 from Juno and delete v2 endpoints in one cycle? | 19:40 |
| ayoung | Good question...I don't think so | 19:40 |
| ayoung | the older clients can't handle not having V2 | 19:41 |
| ayoung | but... | 19:41 |
| ayoung | maybe we don't care for your deployments | 19:41 |
| ayoung | keystone client itself can deal with V3 only endpoints | 19:41 |
| richm | I think the way it will work is that the services will need to use v3 | 19:41 |
| richm | but existing clients that are not services will be able to use v2 or v3 | 19:41 |
| ayoung | richm, so non-services should be the LDAP case above, which means you would want them in the default domain | 19:42 |
| richm | right | 19:42 |
| ayoung | need to proof-of-concept that | 19:42 |
| richm | right | 19:42 |
| richm | that's next on my plate | 19:42 |
| ayoung | ++ | 19:42 |
| EmilienM | ayoung: my only concern is about the database schema, I wonder if what I created with v2 is 100% exploitable with v3 (my question can be very basic, but I just need to be sure) | 19:42 |
| ayoung | EmilienM, the Keystone server treats V2.0 functionality as a limited subset of V3. Anything you can do with V2 you can do with V3, just not the other way around. THus, they can both be supported by the same database schema, and the default deployment has V3 support enabled | 19:44 |
| EmilienM | ayoung: that's what I wanted to know. Thanks | 19:44 |
| morganfainberg | topol, hEY! | 19:45 |
| *** marcoemorais has quit IRC | 19:47 | |
| *** marcoemorais has joined #openstack-keystone | 19:47 | |
| *** marcoemorais has quit IRC | 19:47 | |
| *** marcoemorais has joined #openstack-keystone | 19:48 | |
| topol | morganfainberg, yes? | 19:57 |
| morganfainberg | topol, i am *not* to blame for your light transformer... you clearly bought that before I became PTL | 19:57 |
| morganfainberg | ^_^ | 19:58 |
| *** thedodd has quit IRC | 19:58 | |
| morganfainberg | ok lunch time. | 19:58 |
| topol | morganfainberg, too true. I really should blame jheck :-) | 19:58 |
| morganfainberg | yep | 19:58 |
| stevemar | topol, or that other guy | 19:59 |
| afaranha | Do anyone knows if is there a way to register only one blueprint (spec also) that affects many projects? | 20:06 |
| *** marcoemorais has quit IRC | 20:07 | |
| *** thedodd has joined #openstack-keystone | 20:09 | |
| *** david-lyle is now known as david-lyle_afk | 20:10 | |
| bknudson | afaranha: there's an openstack-specs repo for common specs now | 20:10 |
| bknudson | afaranha: https://review.openstack.org/#/q/status:open+project:openstack/openstack-specs,n,z | 20:10 |
| *** jorge_munoz has quit IRC | 20:16 | |
| *** dims has joined #openstack-keystone | 20:16 | |
| rodrigods | stevemar, found a potential bug, if this (https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L432) conditional is not true but is a fed token anyway, the get_token_data() method will fail because we do not have a field user | 20:17 |
| rodrigods | stevemar, can you check/confirm this whenever you have a moment? | 20:17 |
| *** jorge_munoz has joined #openstack-keystone | 20:18 | |
| Haneef | ayoung: Just FYI: Few v2 call are very difficult to do in v3. Get Projects users is one such call | 20:18 |
| stevemar | rodrigods, yes, but when would a federation token not meet that conditional? | 20:18 |
| stevemar | Haneef, isn't that just GET /projects/project-id/users? | 20:19 |
| ayoung | Haneef, that is because that call is dumb | 20:19 |
| ayoung | Haneef, in the old world view, tenants owned users | 20:19 |
| ayoung | nowadays, not so muchj | 20:19 |
| ayoung | now users have roles on a project | 20:19 |
| ayoung | and treating all those as equivalent is one of the reason that out policy files are so [a curse word] | 20:20 |
| Haneef | stevemar: as far as I know there is no such api GET /projects/<project-id/users. Only way to do it to get effective role assignements for the user filtering by project id | 20:20 |
| rodrigods | stevemar, but shouldn't we return a meaningful error anyway? | 20:21 |
| ayoung | Haneef, why do you want to do get-users-for-projects? | 20:21 |
| stevemar | Haneef, ah yep - you are both right | 20:21 |
| stevemar | rodrigods, yes, probably add it to: https://review.openstack.org/#/c/133130/12/keystone/token/providers/common.py | 20:22 |
| Haneef | Since v2 has that call, normally they expect that in v3. Once some one asked this question in ask.openstack.org since they have some GUI based on that call | 20:22 |
| rodrigods | stevemar, ++ was writing the tests for _is_mapped... when fall into this case | 20:22 |
| stevemar | rodrigods, yeah, if the method seen isn't in 'federation methods' then it should raise a 401 with an error message | 20:23 |
| rodrigods | stevemar, so we need to check if the method_name is valid at all | 20:26 |
| *** marcoemorais has joined #openstack-keystone | 20:26 | |
| afaranha | bknudson: Thanks! | 20:28 |
| *** marcoemorais has quit IRC | 20:28 | |
| afaranha | bknudson: For the blueprint, if it affects many projects, I can create the spec in the openstack-specs and just create a blueprint in one service, right? | 20:28 |
| *** marcoemorais has joined #openstack-keystone | 20:28 | |
| bknudson | afaranha: I don't know how the blueprint works. | 20:29 |
| *** vejdmn has quit IRC | 20:33 | |
| *** NM has quit IRC | 20:34 | |
| *** vejdmn has joined #openstack-keystone | 20:36 | |
| *** amcrn has joined #openstack-keystone | 20:40 | |
| *** victsou has joined #openstack-keystone | 20:43 | |
| *** victsou is now known as vsilva | 20:43 | |
| vsilva | ping lbragstad stevemar; IIRC you were interested in functional testing for Keystone. Did you reach any conclusions on the summit? Do you know which way we're going? | 20:45 |
| *** vsilva is now known as victsou | 20:47 | |
| *** victsou has quit IRC | 20:47 | |
| *** vsilva has joined #openstack-keystone | 20:47 | |
| stevemar | vsilva, no conclusion reached :( | 20:49 |
| vsilva | stevemar, shouldn't we try to reach one? :o | 20:50 |
| stevemar | vsilva, i don't think anyone has an answer yet :( | 20:51 |
| stevemar | vsilva, nkinder wrote some code to deploye stuff -> https://github.com/nkinder/rdo-vm-factory/blob/master/rdo-kerberos-setup/vm-post-cloud-init-rdo.sh | 20:51 |
| stevemar | i was hoping to use that | 20:51 |
| nkinder | stevemar: I'm happy to help figure out how we can make use of some of my scripts | 20:52 |
| stevemar | nkinder, i think we need to bug some infra folks | 20:56 |
| stevemar | but this is at the bottom of my priority list :( | 20:56 |
| vsilva | nkinder, stevemar, would it make sense to talk about this on the next meeting? is there enough interest from the community? | 20:56 |
| stevemar | vsilva, sure, let morganfainberg or edit the wiki | 20:57 |
| rodrigods | vsilva, https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting | 20:58 |
| dstanek | morganfainberg: bknudson: issues? | 21:00 |
| *** nitin_ has joined #openstack-keystone | 21:05 | |
| nitin_ | ayoung: hello, | 21:05 |
| nitin_ | ayoung: Are you available here. | 21:06 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/134770 | 21:06 |
| ayoung | nitin_, available for what? | 21:08 |
| stevemar | marekd|away, ahh no you're away, i wanted to bug you about token scoping | 21:08 |
| nitin_ | I need to discuss some things with you. | 21:08 |
| nitin_ | Is it possible to create separate channel. | 21:09 |
| *** jimhoagland has joined #openstack-keystone | 21:09 | |
| dstanek | nitin_: you can join whatever channel you want | 21:09 |
| nitin_ | dstanek: yes i know | 21:10 |
| nitin_ | I'm asking so that the other discussions don't get distracted | 21:11 |
| dstanek | nitin_: doubt anyone would mind - not much going on anyway :-) | 21:11 |
| nitin_ | OK. | 21:11 |
| nitin_ | dstanek: no problem. | 21:12 |
| *** jasondotstar has joined #openstack-keystone | 21:12 | |
| ayoung | nitin_, yeah, fire away | 21:12 |
| ayoung | nitin_, you assume I am better positioned to answer your question than the other folks in here....that is not a good assumption | 21:13 |
| *** jasondotstar has quit IRC | 21:13 | |
| morganfainberg | Haneef: fyi, federated users don't really resolve the same way. | 21:14 |
| *** jasondotstar has joined #openstack-keystone | 21:14 | |
| morganfainberg | They won't be in that list anyway. We probably need a better way to show role assignment that can indicate federated as well. | 21:15 |
| morganfainberg | Rather than doing the v2 mechanism over in v3 | 21:15 |
| ekarlso- | https://review.openstack.org/#/c/130159/ < what's wrong there morganfainberg ? | 21:22 |
| morganfainberg | A neutron error it looks like. | 21:24 |
| morganfainberg | Not sure, haven't seen that one yet. | 21:24 |
| morganfainberg | Or before. | 21:24 |
| *** jorge_munoz has quit IRC | 21:25 | |
| morganfainberg | ayoung: you tend to have at least some answer ;). So it's not a bad assumption you have at least a starting place | 21:25 |
| *** gyee has quit IRC | 21:26 | |
| morganfainberg | nitin_: fyi, it's good to just ask in the channel for stuff, it means we can all jump in / or if ayoung wasn't available someone else can try and help. :) | 21:26 |
| *** jorge_munoz has joined #openstack-keystone | 21:26 | |
| *** gyee has joined #openstack-keystone | 21:30 | |
| *** ChanServ sets mode: +v gyee | 21:30 | |
| *** gyee has quit IRC | 21:31 | |
| bknudson | ekarlso-: morganfainberg dstanek -- everything seems to be failing with that neutron error | 21:33 |
| *** zzzeek has quit IRC | 21:36 | |
| lbragstad | vsilva: stevemar I think clarkb had a plan for moving tests from tempest to a project without regression | 21:41 |
| lbragstad | vsilva: stevemar mtreinish did some work with subunit and that had something to do with it. I don't really specifically though. | 21:42 |
| dstanek | bknudson: link? | 21:44 |
| bknudson | dstanek: here's an example https://review.openstack.org/#/c/130159/ | 21:45 |
| ayoung | morganfainberg, ok ,so I just did a quick proof of concept for one user getting token for another, and doing a policy check. What is clear from this little bit of work is that the "canonical" form of the token needs to be a dictionary | 21:48 |
| morganfainberg | ayoung, why? | 21:48 |
| ayoung | https://github.com/admiyo/keystone/commit/8d82d5dfe60bb113eb4bd524a7a8529c9beba833 | 21:48 |
| ayoung | morganfainberg, cuz that is how the policy engine expects it | 21:48 |
| morganfainberg | uh... | 21:48 |
| ayoung | and why should the canonical version not be what is passed to the policy engine? | 21:49 |
| ayoung | morganfainberg, alternatively, we make the policy engine accept it as a straight python object | 21:49 |
| morganfainberg | because often we don't pass the entire thing | 21:49 |
| morganfainberg | iirc | 21:49 |
| morganfainberg | we pass a constructed context | 21:49 |
| morganfainberg | that is separate/different from the token | 21:49 |
| ayoung | morganfainberg, yeah, I just chopped a very small portion of it out in that POC | 21:49 |
| marekd|away | stevemar: what's up? | 21:50 |
| ayoung | + source = {"domain_id": self.domain_id, | 21:50 |
| ayoung | + "roles": self.role_names} | 21:50 |
| ayoung | that would be "creds" if I named it consistantly | 21:50 |
| dstanek | bknudson: we didn't cause that did we? | 21:50 |
| morganfainberg | i'd rather extract the stuff we're looking to pass to policy not assume our token format matches. | 21:50 |
| morganfainberg | which it doesn't "really" match | 21:50 |
| bknudson | dstanek: we never cause tempest failures. | 21:50 |
| stevemar | marekd|away, back to the question of using a token in django_o_auth | 21:50 |
| marekd|away | bknudson: thanks, i will take a loot at it tomorrow :-) | 21:50 |
| *** marekd|away is now known as marekd | 21:50 | |
| marekd | stevemar: yep? | 21:50 |
| bknudson | dstanek: but tempest failures are always causing keystone failures | 21:51 |
| stevemar | marekd, did you end up using the unscoped token as the token id? | 21:51 |
| *** zzzeek has joined #openstack-keystone | 21:51 | |
| *** jimhoagland has left #openstack-keystone | 21:51 | |
| ayoung | morganfainberg, that seems to be the general pattern, but we have to do the same thing in a lot of places...the revocation events for example | 21:51 |
| morganfainberg | ayoung, again this is why i think we're talking about 2 forms of token | 21:51 |
| ayoung | those things often have a flattened view of the token data | 21:51 |
| stevemar | marekd, https://github.com/er0s14/django_openstack_auth/commit/9874c0289d43726654a73b8fad990158d3084463 | 21:51 |
| ayoung | user.id becomes user_id and so on | 21:51 |
| morganfainberg | 1: raw data [what is *inside* keystone], 2: what everything else uses | 21:51 |
| morganfainberg | which is formatted | 21:51 |
| dstanek | bknudson: that looks like lots of no good | 21:52 |
| morganfainberg | which was the idea behind that token_model in keystone | 21:52 |
| ayoung | and then there is the JSON format, so three... | 21:52 |
| morganfainberg | JSON is formatted - | 21:52 |
| morganfainberg | or serialized | 21:52 |
| morganfainberg | so sure, 3? | 21:52 |
| morganfainberg | we can fix all but serialized | 21:52 |
| stevemar | marekd, the login doesn't work, since it says the user is not authorized | 21:52 |
| ayoung | but it does not match the policy or revocation view of the data, nor what we pass from auth_token middleware either | 21:52 |
| morganfainberg | the view keystone is going to have is always going to be somewhat different. | 21:53 |
| ayoung | auth token fragments the hell out of it, doesn't it? Separate headers | 21:53 |
| morganfainberg | yeah | 21:53 |
| ayoung | well, Keystone needs to be able to consume the standard view of tokens to feed into policy | 21:53 |
| bknudson | if the info in an AE token is enough to rebuild a token then the AE token can be the internal representation, too. | 21:53 |
| *** diegows has quit IRC | 21:53 | |
| ayoung | not sure if jamielennox|away 's approach would work here. | 21:53 |
| bknudson | i.e., if all we need for a token is user + scope + etc., then just store that in the token table | 21:54 |
| morganfainberg | ayoung, my goal is "object that you can get all the token data from and format however you need it" is what the token_model would be | 21:54 |
| bknudson | not the whole JSON | 21:54 |
| morganfainberg | that is what is passed to the provider | 21:54 |
| *** jamielennox|away is now known as jamielennox | 21:54 | |
| ayoung | bknudson, the AE format is optimized for size | 21:54 |
| morganfainberg | and the formatter can reverse that | 21:54 |
| ayoung | its not really appropriate for anything other than transport | 21:54 |
| marekd | stevemar: sorry, i am back. | 21:55 |
| stevemar | marekd, i end up with a 'Unauthorized: Could not find user xyz' error message | 21:55 |
| stevemar | np | 21:55 |
| ayoung | and...probably really not even appropriate for that, but, exigencies of the service | 21:55 |
| morganfainberg | ayoung, so, if policy is expecting a specific format, rev. events is, etc and they're all different we start from a common place and then move the disparate formats towards center, not pick something we're reformatting anyway | 21:56 |
| morganfainberg | ayoung, so in short, no a dict is an awful choice | 21:56 |
| marekd | stevemar: so, your problem in ingeneral is that keystone issues an unscoped token and redirects to the horizon and this is where you fail, right? | 21:56 |
| ayoung | morganfainberg, both policy and revocation events expect a flat view | 21:56 |
| morganfainberg | ayoung, we have *very* little control what goes into it | 21:56 |
| morganfainberg | and we should have the data that is passed to the provider and back from the provider be very tightly controlled | 21:57 |
| ayoung | so we need one way to turn a canonical representation into a dictionary | 21:57 |
| morganfainberg | sure. | 21:57 |
| stevemar | marekd, yeah, we're able to get the token id back, but when we use it, it fails to log in | 21:57 |
| jamielennox | ayoung: my approach? | 21:57 |
| ayoung | but the thing is, we need to build that canonical represnation out of either the token data or from the component parts right out of the database | 21:57 |
| morganfainberg | or make the cannonical rep *act* like a dict when policy accesses it | 21:57 |
| marekd | stevemar: AFAIR you need both uuid (X-Auth-Token) and the JSON itself. | 21:57 |
| ayoung | jamielennox, representint the token inside keystone client | 21:57 |
| morganfainberg | __getitem__ | 21:57 |
| morganfainberg | no i am not above things like that. | 21:58 |
| morganfainberg | ;) | 21:58 |
| ayoung | morganfainberg, yeah...I tried that...policy didn't seem to like it, but I can try again | 21:58 |
| jamielennox | what's wrong with it? | 21:58 |
| ayoung | morganfainberg, isn't that what the auth plugins do? | 21:58 |
| morganfainberg | ayoung, not exactly | 21:58 |
| * ayoung looking through client code | 21:58 | |
| morganfainberg | ayoung, this is why i am starting work on this cleanup | 21:58 |
| stevemar | marekd, huh? i mean when instantiating the client | 21:59 |
| morganfainberg | AccessInfo is a different beast | 21:59 |
| marekd | stevemar: https://github.com/cernops/keystone/commit/66dabd94b4ad32abca171cef9192210fec289235 | 21:59 |
| ayoung | morganfainberg, yep | 21:59 |
| morganfainberg | accessinfo is like what the current token model is | 21:59 |
| marekd | stevemar: take a look at federation controlles.py file | 21:59 |
| ayoung | jamielennox, where should I be looking? | 21:59 |
| morganfainberg | it's smart enough to know what each of the token formats look like | 21:59 |
| marekd | stevemar: this is what is being returned to the browser,and instantianly redirected to the horizon. | 21:59 |
| morganfainberg | which is the wrong approach, the model shouldn't *care* waht the format is. | 21:59 |
| jamielennox | ayoung: there's a lot of back converstaion there, i'm not sure what you're looking for | 21:59 |
| ayoung | jamielennox, the KC version of the auth context | 22:00 |
| ayoung | the thing that wraps the token data | 22:00 |
| marekd | lbragstad: what's your e-mail? | 22:00 |
| jamielennox | ksc.access:AccessInfo | 22:00 |
| morganfainberg | ayoung, why are we down the path of this becoming a "we need it right this very second and blocking other work"? | 22:00 |
| lbragstad | marekd: lbragstad@gmail.com | 22:00 |
| morganfainberg | ayoung, i'm confused why this landed at the top of the pile. | 22:00 |
| morganfainberg | not that i'm complaining, don't get me wrong | 22:00 |
| ayoung | morganfainberg, cuz I am trying to do something that enforces policy, and I don't want to reinvent...yet again...the marshalling of the token | 22:01 |
| marekd | stevemar: https://github.com/cernops/django_openstack_auth/commit/b7e5b28a83a88b259bfaddbd754c70e1bb420447 -> this is django_openstack_auth commit | 22:01 |
| marekd | stevemar: did you see that? | 22:01 |
| marekd | lbragstad: thanks. | 22:01 |
| ayoung | I'd rather have one place that we do it, and right now we have several | 22:01 |
| lbragstad | marekd: np | 22:01 |
| morganfainberg | ayoung, but we *already* marshal the token. | 22:01 |
| marekd | lbragstad: gonna bug you asynchronously | 22:01 |
| stevemar | marekd, i did, but here you only supply the ID https://github.com/cernops/django_openstack_auth/commit/b7e5b28a83a88b259bfaddbd754c70e1bb420447 | 22:01 |
| stevemar | in backend.py | 22:01 |
| lbragstad | marekd: awesome! | 22:01 |
| stevemar | OHhh | 22:01 |
| stevemar | FFS | 22:01 |
| stevemar | it's the whole ref | 22:01 |
| marekd | FFS? | 22:02 |
| morganfainberg | my question is more, can we use what we have and move towards the better solution ? | 22:02 |
| ayoung | morganfainberg, my problem is that I actually have no token to marshall, just the raw queries against the database | 22:02 |
| morganfainberg | ok lets step back | 22:02 |
| stevemar | marekd, http://www.urbandictionary.com/define.php?term=FFS | 22:02 |
| morganfainberg | what are you actually wokring on atm? | 22:03 |
| ayoung | Ideally, I would be reusing the same logic that we use to build a token to get the internal representation | 22:03 |
| morganfainberg | i feel like i'm missing context ;) | 22:03 |
| morganfainberg | so i can't comment definitively | 22:03 |
| ayoung | morganfainberg, I'm doing a proof of concept for something that calls into Keystone to do work. What it does is not as important as the fact that I want it to do this without having to get a token everytime first | 22:04 |
| ayoung | this is the whole "tokenless operations" thing that we've discussed a few times in the past | 22:04 |
| *** vejdmn has quit IRC | 22:04 | |
| ayoung | so I want to be able to enforce policy on it by getting the minimal amount of data out of the backends | 22:05 |
| ayoung | right now, that logic is buried inside the token provider, so I can't access it directly | 22:05 |
| morganfainberg | ayoung, ok so how does this (besides we've seen the request for it) fall into the roadmap for *all the things* we've talked about for this cycle? | 22:06 |
| ayoung | here is my quick and dirty proof-of-concept: https://github.com/admiyo/keystone/blob/domain-signer-role/keystone/auth/plugins/password.py#L164 | 22:06 |
| morganfainberg | ayoung, because right now it feels like each time we talk there is yetanotherthingthatsuddenlyneedstogetdone. not saying we shouldn't do this, but i'm seeing a ton of things stack up in a way that makes me concerned we're not going to hit *any* mark for kilo | 22:06 |
| ayoung | morganfainberg, enforce policy from keystone client depends on this | 22:07 |
| morganfainberg | this sounds like an optimisation to enforcement, something we can support later but isn't needed right off the bat? | 22:07 |
| stevemar | marekd, thanks, i think that was our issue | 22:08 |
| ayoung | and the Federation work, if I understand what needs to be done, is probably going to need something similar | 22:08 |
| *** _cjones_ has quit IRC | 22:08 | |
| morganfainberg | getting a token *each* time isn't ideal, but we already have a lot of logic to help us on that front, don't we? | 22:08 |
| ayoung | morganfainberg, and actually, revocation events duplicates this code. So the cleanup of that also ties in | 22:09 |
| morganfainberg | we could streamline it, i just don't want to be off in the weeds | 22:09 |
| ayoung | My proof of concept just illustrates the issue. | 22:09 |
| ayoung | really, the issue is how to enforce policy in a standarized way, as I would like to make revocation events use the same format | 22:09 |
| marekd | stevemar: wait, which one? | 22:10 |
| ayoung | and I think it can | 22:10 |
| *** openstackgerrit has quit IRC | 22:10 | |
| *** openstackgerrit has joined #openstack-keystone | 22:10 | |
| morganfainberg | ayoung, ok so i think I see what is going on | 22:10 |
| morganfainberg | ayoung, i *think* there is a lot of work that can be done in parallel. | 22:10 |
| morganfainberg | this may be one of the things that needs to serialize behind some of the other work. | 22:11 |
| stevemar | marekd, we were using just the id, not the ref | 22:12 |
| morganfainberg | and it's fine if we're prioritizing that work | 22:12 |
| morganfainberg | but lets not jump around too much and partially implement bits here there and everywhere | 22:12 |
| morganfainberg | because we will have a brittle / worse system than we have now | 22:13 |
| ayoung | morganfainberg, OK...just found the Client reprentation. http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/access.py | 22:14 |
| morganfainberg | ayoung, eyah AccessInfo is a bit weird and very token-specific but it has suited us for now | 22:15 |
| *** jsavak has quit IRC | 22:15 | |
| morganfainberg | it is something we should be better about long-term. | 22:15 |
| ayoung | morganfainberg, since policy and revocation events both need to be checked outside of the Keystone server, I think it is at least the right starting place | 22:15 |
| morganfainberg | ayoung, ok then lets prioritize the provider cleanup spec | 22:15 |
| morganfainberg | or at least part of that spec. | 22:16 |
| morganfainberg | ayoung, so we can get the parts out of that that are what you need. | 22:16 |
| ayoung | morganfainberg, well, since we are talking about splitting the canonical form from the form passed to the client APIs...maybe they should stay separate | 22:17 |
| morganfainberg | ayoung, i actually am for a client representation and a server side | 22:17 |
| ayoung | Maybe I say that both policy and revocation should be able to consume a AccessInfo | 22:17 |
| morganfainberg | ayoung, since keystone could *construct* a token at anytime, no other service can | 22:17 |
| morganfainberg | ayoung, hmm. | 22:17 |
| morganfainberg | ayoung, this sounds like a good approach | 22:18 |
| ayoung | morganfainberg, right...but if the keystone server can produce an AccessInfo object...we probably should use that everywhere | 22:18 |
| morganfainberg | ayoung, make the client representation the common form. | 22:18 |
| ayoung | yeah, that is what I was getting at | 22:18 |
| morganfainberg | ayoung, AccessInfo is the wrong direction though atm | 22:18 |
| morganfainberg | accessinfo knows all token formats | 22:18 |
| morganfainberg | which is what i'm trying to break away | 22:18 |
| morganfainberg | if that makes sense | 22:18 |
| morganfainberg | so "formatted" is really the serialization form. | 22:19 |
| morganfainberg | if it can be used outside of keystone, i'd be happy with that as well | 22:19 |
| morganfainberg | but my first thought was get keystone to not care about the format of the data. | 22:19 |
| morganfainberg | hence the python object | 22:19 |
| ekarlso- | jamielennox: you around mate ? | 22:19 |
| ayoung | morganfainberg, I would see us wanting to work with what is in the V3 form, with V2 being a one-off | 22:19 |
| jamielennox | ekarlso-: somewhta | 22:20 |
| morganfainberg | ayoung, i think the V3 form is pretty awful. | 22:20 |
| marekd | stevemar: great | 22:20 |
| jamielennox | ugh, just can't type this morning | 22:20 |
| marekd | stevemar: yeah, the token is X-Subject-Token | 22:20 |
| marekd | stevemar: https://github.com/cernops/keystone/commit/66dabd94b4ad32abca171cef9192210fec289235#diff-7acf6caf0073728646f4171a110c1e6fR280 | 22:20 |
| morganfainberg | ayoung, it is an *ok* serialized form. | 22:20 |
| morganfainberg | but not good. | 22:20 |
| jamielennox | AccessInfo is a horrible thing - but it works for certain cases | 22:21 |
| morganfainberg | jamielennox, ++ | 22:21 |
| stevemar | marekd, yeah yeah, it was when doing client.Client(token=...) | 22:21 |
| jamielennox | it's not a serialized form, it's a weird messy hack | 22:21 |
| stevemar | we passed in the id | 22:21 |
| morganfainberg | jamielennox, and that is the same thing the current token_model is. | 22:21 |
| morganfainberg | but it was a stepping stone to make sure we accessed the data in a sane way | 22:21 |
| jamielennox | context needs to be different, it needs to be a very flat dictionary | 22:21 |
| morganfainberg | so i don;t think the V3 form is "right" | 22:22 |
| ayoung | morganfainberg, what if we at least made everything work through the AccessInfo as a starting point? | 22:22 |
| jamielennox | you could very easily build context from the AccessInfo because it handles the abstraction for you, but you shouldn't use AccessInfo itself | 22:22 |
| morganfainberg | we can make the python object act like a flat dict | 22:22 |
| marekd | stevemar: cool, good luck then! :-) | 22:22 |
| ayoung | I thought that was what accessinfo does now? | 22:22 |
| morganfainberg | i want to get away from overloading dicts to do magic properties | 22:22 |
| morganfainberg | ayoung, it is a overloaded dict with magic properties | 22:22 |
| morganfainberg | jamielennox, i think you and i are mostlyn on the same page | 22:22 |
| jamielennox | ayoung: the raw respresentation of AccessInfo is the v2 and v3 token formats with some edge cases | 22:23 |
| jamielennox | it's the properties that handle the abstraction | 22:23 |
| morganfainberg | jamielennox, i'd rather have something that can "deserlize" the token into a useful object, that object *could* act like a context | 22:23 |
| jamielennox | (it adds some extra stuff as well) | 22:23 |
| morganfainberg | right now it's fairly magical *wavy hands* and needs to know the token formats. | 22:24 |
| *** jasondotstar has quit IRC | 22:24 | |
| *** gordc has quit IRC | 22:24 | |
| morganfainberg | that way we can maintain our contracted wire format - and have sane representation internal to python, while controlling the data that goes inot the token | 22:24 |
| morganfainberg | basically no "oops i stuck data into the dict and it just appeared" | 22:25 |
| morganfainberg | now, we *could* make all clients use accessinfo to start. | 22:25 |
| jamielennox | morganfainberg: why would the serialized form be the context | 22:26 |
| jamielennox | i think those should be seperate concepts | 22:26 |
| morganfainberg | jamielennox, i said it could be. i don't think it should be | 22:26 |
| jamielennox | also: https://review.openstack.org/#/c/113163/ | 22:26 |
| ekarlso- | jamielennox: https://review.openstack.org/#/c/130159/ < care to look at that ? | 22:26 |
| morganfainberg | jamielennox, interesting. | 22:26 |
| *** radez is now known as radez_g0n3 | 22:27 | |
| morganfainberg | i mean, i'd be fine with a ".to_context" (equiv) | 22:27 |
| morganfainberg | or whatever way we get there | 22:27 |
| ayoung | morganfainberg, does this call for its own spec? | 22:28 |
| ayoung | unify token-to-dict conversions or something? | 22:28 |
| ayoung | something that at least pulls together all the places we duplicate the logic? | 22:28 |
| morganfainberg | i think it might be a side-effect of the other work | 22:28 |
| morganfainberg | i could be it's own spec | 22:28 |
| morganfainberg | it might not need ot be | 22:28 |
| morganfainberg | if that makes sense | 22:28 |
| ayoung | I just want to make sure we identify the places that need to be updated to use the AccessInfoNextGeneration | 22:29 |
| *** packet has quit IRC | 22:30 | |
| morganfainberg | ayoung, sure. | 22:31 |
| morganfainberg | it's a fair point | 22:31 |
| morganfainberg | like i said, it def. could stand on it's own as a spec | 22:31 |
| *** _cjones_ has joined #openstack-keystone | 22:31 | |
| ayoung | the one thing that I don't think this affects is your token cleanup | 22:32 |
| ayoung | token provider goes from database to JSON | 22:32 |
| ayoung | doesn't need to be in this AccessInfo format | 22:32 |
| *** stevemar has quit IRC | 22:32 | |
| morganfainberg | ayoung, not always. | 22:33 |
| morganfainberg | thats the point | 22:33 |
| ayoung | when does it need to be? | 22:33 |
| jamielennox | ekarlso-: looks fine, commented that you added some whitespace | 22:34 |
| morganfainberg | ayoung, it gets used in context a lot | 22:34 |
| *** saipandi has quit IRC | 22:34 | |
| morganfainberg | ayoung, interally. | 22:34 |
| morganfainberg | ayoung, not just for enforcement but for understanding some assumed "what am i acting on" | 22:35 |
| morganfainberg | json != python dict. | 22:35 |
| morganfainberg | so, the provider is used both interfacing externally (wire serialization) as well as internally. | 22:35 |
| morganfainberg | in the latter case it needs to be some representation we can work with. | 22:35 |
| *** jimhoagland has joined #openstack-keystone | 22:39 | |
| ayoung | morganfainberg, ok. let me start a spec. We can all take stabs at it | 22:41 |
| ayoung | morganfainberg, this spec....should it be a kilo spec or a keystone client spec? Or both? | 22:42 |
| ayoung | the unified format should live in the client | 22:42 |
| *** jistr|mtg has quit IRC | 22:42 | |
| ayoung | and needs to be usable by several points in the server | 22:42 |
| ayoung | If I could make use of the AccessInfo now, it would provide a single place to clean up in the future | 22:43 |
| ekarlso- | jamielennox: removed that | 22:44 |
| openstackgerrit | Endre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version https://review.openstack.org/130159 | 22:44 |
| *** topol has quit IRC | 22:50 | |
| *** david-lyle_afk is now known as david-lyle | 22:50 | |
| *** thedodd has quit IRC | 22:51 | |
| *** gyee has joined #openstack-keystone | 22:55 | |
| *** ChanServ sets mode: +v gyee | 22:55 | |
| *** gyee has quit IRC | 22:55 | |
| *** hockeynut_ has joined #openstack-keystone | 22:56 | |
| *** hockeynut_ has quit IRC | 23:01 | |
| *** r-daneel has quit IRC | 23:03 | |
| *** nitin_ has quit IRC | 23:06 | |
| *** jasondotstar has joined #openstack-keystone | 23:08 | |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Docstring usability improvements https://review.openstack.org/127856 | 23:11 |
| *** agireud has quit IRC | 23:15 | |
| openstackgerrit | ayoung proposed openstack/keystone-specs: Access Info https://review.openstack.org/135774 | 23:17 |
| ayoung | jamielennox, morganfainberg ^^ | 23:17 |
| *** gyee has joined #openstack-keystone | 23:18 | |
| *** ChanServ sets mode: +v gyee | 23:18 | |
| openstackgerrit | Everett Toews proposed openstack/keystone-specs: Add requirement for APIImpact flag https://review.openstack.org/132303 | 23:20 |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Replace magic numbers with named symbols https://review.openstack.org/135127 | 23:23 |
| *** dnalezyt has quit IRC | 23:27 | |
| *** jaosorior has quit IRC | 23:33 | |
| *** jasondotstar has quit IRC | 23:33 | |
| *** agireud has joined #openstack-keystone | 23:34 | |
| *** jasondotstar has joined #openstack-keystone | 23:36 | |
| *** marg7175 has quit IRC | 23:49 | |
| *** richm has quit IRC | 23:50 | |
| jamielennox | ayoung: so we talked a little about that AccessInfo idea when morganfainberg did the token model, from memory morgan decided he didn't want to have to fix client if there were issues on the server with representation | 23:51 |
| *** _cjones_ has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!