Wednesday, 2014-11-19

ayoungyou set the USERNAME to the cn field, remember?00:00
telemonstergotcha fixing00:01
telemonsterkeystone token-get00:02
telemonsterExpecting a username provided via either --os-username or env[OS_USERNAME]00:02
*** lhcheng_ has quit IRC00:04
telemonsterI think it uses the first one on the backend to resolve the common name then reuses the common name over and over for queries00:04
ayoungtelemonster, do you need to use CN?00:05
ayoungfor now, just set both user_id and username to use sAMAccountName00:05
telemonsterput_filter: "(&(sAMAccountName=OpenStack Admin)(objectClass=person))"00:05
telemonsterI see that coming up now, with those two reversed00:05
telemonsterI don't know that I care that much about the cn00:06
*** david-lyle is now known as david-lyle_afk00:06
telemonsterI can change both to sAMA or forgo one?00:06
ayoungyou can change both to sAMAccountName00:06
*** stevemar has joined #openstack-keystone00:07
*** ChanServ sets mode: +v stevemar00:07
telemonsterdoing that now, I know that causes existing config to not allow login but maybe with other settings00:07
telemonster1 sec00:07
ayoungwhen 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 again00:08
telemonsterour users log in wiht the sAMAccount name00:08
telemonsterall the time00:08
telemonsterdid you want me to use OS_USERNAME or OS_USER_ID ?00:08
*** jorge_munoz has left #openstack-keystone00:09
ayoungtelemonster, set OS_USERNAME=cloudadmin00:09
ayoungthat is the value in sAMAccountName, right?00:10
telemonsterand it fails00:10
telemonsterthe only case it works is with the id cn and user sAMA IIRC00:10
ayounghold on00:11
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Allow loading other auth methods in auth_token
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Split identity server into v2 and v3
telemonster1 sec00:11
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Additional discovery changes
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Use real discovery object in auth_token middleware.
jamielennoxbknudson: 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 way00:12
ayoungtelemonster, ok,  so make sure the OS_TENANTNAME and the rest are all unset.00:12
ayoungMake sure that we are limiting things to doing an unscoped token00:12
telemonsterlet me back out and retry00:13
telemonsterexport OS_USERNAME=cloudadmin00:14
telemonsterexport OS_AUTH_URL=
telemonsterand the pass00:14
telemonsterkeystone token-get00:14
telemonsterThe request you have made requires authentication. (HTTP 401)00:14
telemonsterIf 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 cn00:15
telemonsterhmmm on console I see this:00:16
telemonsterput_filter: "(&(sAMAccountName=OpenStack Admin)(objectClass=person))"00:16
telemonsterIt's not in the first request but it's wrong00:16
*** r-daneel has quit IRC00:17
ayoungwhat 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 field00:18
ayoungyou suire you don00:18
ayoungyou sure you don't have the cn field set further down the config, and it is over writing the sAMAccountName value?00:19
telemonsterthe cn field is in there a number of times00:19
telemonster1 sec00:19
telemonsteruser = "CN=AD Bind,OU=Service Accounts,OU=User Accounts,DC=int,DC=aopslab,DC=com"00:20
telemonsteruser_objectclass = person00:20
telemonsteruser_id_attribute = sAMAccountName00:20
telemonsteruser_name_attribute = sAMAccountName00:20
telemonsteruser_enabled_attribute = userAccountControl00:20
telemonsteruser_enabled_mask = 200:20
telemonsteruser_enabled_default = 51200:20
telemonsterthats it, no other cn references... because they're all remarked out00:21
telemonsterwe had a group section for narrowing things down but in the process of elimination it's remarked out00:21
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Use newer requests-mock syntax
*** ncoghlan has joined #openstack-keystone00:23
*** RichardRaseley has quit IRC00:24
telemonsterare both id and name needed?00:25
ayoungyeah, both are used, but that should be OK00:26
ayoungthe user line seems strange00:26
ayounguser = "CN=AD Bind,OU=Service Accounts,OU=User Accounts,DC=int,DC=aopslab,DC=com"00:27
ayoungthat is the admin user...00:27
ayoungand that is done by DN....ok00:27
telemonsterthats just a bind account for the lookups00:27
ayoungthe right that is what I meant00:27
ayoungtelemonster, can you do a simple bind using sAMAccountName for a user?00:28
telemonsterif taht is wrong its ldap permission denied00:28
*** marcoemorais has quit IRC00:28
*** marcoemorais has joined #openstack-keystone00:28
telemonsterI dont think so, the bind account is prob different00:28
telemonsterAD is different in that it doesn't allow random binds00:28
*** marcoemorais has quit IRC00:28
*** marcoemorais has joined #openstack-keystone00:29
ayoungtelemonster, that might be the issue.  I'm not an AD expert00:29
ayoungand my AD expert is missing00:29
telemonsterNope, that part is good. If I dork that up it will fail to even try a user/pass00:30
*** stevemar has quit IRC00:30
telemonsterthe 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 work00:31
telemonsterthats why I get invalid password when both are set to sAMAccount and try to login via web or key request via cli00:31
morganfainberglbragstad, i see you've convinced ayoung AE isn't bad!00:31
morganfainbergayoung, AD?00:33
telemonsterActive Directory00:33
morganfainbergno i was wondering what was going on w/ it00:33
morganfainbergtelemonster, i'm reading the backscroll00:34
openstackgerritMerged openstack/keystone-specs: Token Provider Cleanup Spec
openstackgerritMerged openstack/keystone-specs: Update headers slightly for API specification(s)
morganfainbergtelemonster, a lot of ADs will use the email name for binding ... i don't remember what that mode is called... Principal bind?00:35
morganfainbergi know i had to support that around a bunch of custom AD code a long while ago (custom openstack/keystone development)00:35
morganfainbergthe point was i had to bind with the principal name not the CN/DN00:36
telemonsterAh. 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 permissions00:36
morganfainbergso identity is backed by AD?00:36
telemonsterIt comes back with a no project permissions error from web ui00:36
morganfainbergand assignment is in SQL?00:36
telemonsterthe user/pass/group comes from AD, then the projects and tenants and stuff are in SQL00:36
telemonsteronly using AD for basic auth00:37
morganfainbergi was going to get scared ;)00:37
telemonsterWE're not a microsoft shop by any means, but for whatever reason auth against AD.00:37
morganfainbergeh, i know a bunch of places like that00:37
morganfainbergAD has a lot of nice featured tbh00:37
morganfainbergi think 3 of my 5 past eployers were like that00:38
telemonsterIt needs an inspector ability to watch queries against AD live :-) Trying to troubleshoot it isn't much fun00:38
telemonsterThe microsoft way seems to be DLL replacements that allow snooping client side.00:38
morganfainbergoh god00:39
morganfainbergmy brain hurts now00:39
morganfainberghave you given a grant specifically to the user in question or only the user's group?00:40
morganfainbergbecause - I wonder if the group is being resolved incorrectly00:40
*** raildo_ has joined #openstack-keystone00:40
morganfainbergAD *can* do groups different than normal LDAP00:41
gyeeyou can use ldapsearch to hit AD00:41
telemonsterldap search came back fine, and this config was running in production on possibly an older havana install for about a year00:41
morganfainbergtelemonster, gyee also is *really* good at LDAP stuff (gyee see what i did there :P )00:41
morganfainbergand in icehouse it broke?00:41
morganfainbergi'm getting the feeling this is related to some of the attribute fetch fixes that were backported00:42
gyeemember versus memberOf?00:42
morganfainberggyee, possibly00:42
openstackgerritRodrigo Duarte proposed openstack/keystone: Remove string from URL in list_revoke_events()
morganfainbergwe had a big rewrite of LDAP stuff00:42
telemonstermorgan - yes, on the RDO version of icehouse the user/pass part didnt work. i grabbed from git the latest from ldap and threw it over it and all of a sudden it would pass the user/pass auth part and fail somewhere else00:43
telemonstercoworkers reverted to havana to hopefully get past it (the goal is to get production back running) and we've hit the same issue00:43
*** oomichi has joined #openstack-keystone00:43
morganfainbergwait, so suddenly havana has the same issue?00:43
rodrigodsdstanek, ^ addressed your comment there00:43
ayoungtelemonster, keystone does a simple bind to authenticate the user00:44
morganfainbergi am going to call shenanigans then. either the config has changed or *something* related to the AD server and directory has changed.00:44
telemonsterthis 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 changed00:44
telemonsterIm trying to get the basic admin role abilityt o log into it authing via ldap00:44
gyeeyou pulling groups from AD too?00:44
ayoungtelemonster, the first thing I would try to resolve is what do you need to do to get a simple bind working for the cloudadmin user00:44
telemonsterit might be the fields in the DB table for admin or some other role issue, not sure00:44
raildo_morganfainberg,  do you have some minutes to review this patch? :) (that is not related to HM hahaha)00:45
telemonsterthe bind part works00:45
ayoungtelemonster, for clouduser?00:45
morganfainbergraildo_, yes i do.00:45
raildo_morganfainberg, thanks00:45
telemonsterI can get that sAMAccountName with the proper vlaue and the CN for proper value, it just fails on belonging to a tenant00:45
dstanekrodrigods: cool, I'll take a look after dinner00:45
morganfainbergraildo_, let me finish this convo w/ telemonster then i'll look00:45
raildo_morganfainberg, np00:45
morganfainbergraildo_ it's in a window waiting to be looked at before i click anywhere else00:45
ayoungtelemonster, um...what are you using for your assignment backend?00:45
morganfainbergayoung, SQL i asked00:46
morganfainbergok so based on this my guess is that somehow the grant is not matching the data returned from AD-LDAP00:46
morganfainbergmismatch of DN vs CN vs SOMETHINGELSE?00:47
ayoungwhat was the table for that in Havana again?00:47
morganfainbergayoung, uh... user_project_something?00:47
ayoungHeh...we all clueless00:47
ayoungif 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
morganfainbergsee i was closE!00:48
* morganfainberg hides in the corner before being mocked more about not knowing.00:48
ayoungselect * from user_project_metadata  where userid = 'cloudadmin';00:48
*** alex_xu has joined #openstack-keystone00:48
gyeetelemonster, select * from user_project_metadata where actor_id = 'clouseradmin'00:48
ayoungor user_id00:48
ayounggyee, actor_id?00:48
morganfainberggyee, thats Juno00:48
morganfainbergisn't it00:48
gyeeJuno? I thought they are running Havana00:48
telemonsterthere is no actor_id00:48
ayoungI think that was the name we picked for the unified assignment table, but it was user_id in Havana00:48
morganfainberg"actor_id" i think that is a juno thing00:49
telemonsterThis is havana00:49
*** chrisshattuck has quit IRC00:49
ayoungNo.  THIS IS SPARTA!00:49
ayoungso, yeah,. user_id00:49
gyeetelemonster, desc user_project_metadata00:49
morganfainberguser_id = sql.Column(sql.String(64), primary_key=True)00:49
ayoungtelemonster, select * from user_project_metadata  where userid = 'cloudadmin';00:50
ayoungif that does not return anything, then  try it with00:50
telemonster| Field      | Type        | Null | Key | Default | Extra |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
morganfainbergayoung, i'd go select * from user_project_metadata  where userid like '%cloudadmin%';00:50
ayoungtelemonster, select * from user_project_metadata  where userid = 'OpenStack Admin';00:50
telemonsterthe userid in that table is a long hex line, and that hex line matches a field in the user table00:50
ayoungmorganfainberg, nah, we know the sAMAccountName from AD00:50
morganfainbergayoung, ahh00:50
ayoungtelemonster, ACHA!00:50
morganfainbergmixed up SQL and LDAP identity!00:51
ayoungtelemonster, select count(*) from user;00:51
ayoungif it is anything more than 10 they lied to you about using LDAP00:51
ayoungOK, so that is a service user00:51
morganfainbergOpenStack Admin is SQL service?00:52
ayoungtelemonster, select count(*) from  user_project_metadata;00:52
ayoungshould return like hundreds, at least one per user of your cloud00:52
morganfainbergno grants given to the LDAP users00:52
ayoungyour database was not restored00:52
ayoungtelemonster, do you have sql backups somewhere?00:53
telemonsterno :-(00:53
telemonsterwe know we're recreating all the accounts00:53
telemonsterI just need to be able to log in as admin via ldap auth00:53
morganfainbergtelemonster, so you need to grant the role to the LDAP admin.00:53
gyeejust redo the role assignment00:53
telemonsterokay, how do I do this?00:53
morganfainbergit's missing the role assignments for *any* ldap user00:53
ayoungyou can do that via SQL or via the CLI using the SERVICE _TOKEN00:53
ayoungI'd go sql at this point00:54
telemonsterwhich table are the roles in00:54
morganfainbergayoung, i'd say use SERVICE_TOKEN00:54
morganfainbergayoung, but thats me.00:54
morganfainbergonly cause i worry about screwing up the SQL personally00:54
ayoungtelemonster, OK...lets do it morganfainberg 's way00:54
telemonster1 sec00:54
ayoungstart by looking at your keystone.conf file00:54
telemonsterI have a table called role, the role table has a hex line00:54
ayoungthere is an field called admin_token00:54
morganfainbergtelemonster, we'll do this via the api00:54
morganfainbergless likely to miss a bit of it00:54
ayoungif you use that, you can do basica operations on the keystone server without having any roles00:54
telemonsterthat role line for the admin role00:55
telemonsterhas been assigned to the cloudadmin user that exists in ldap00:55
telemonstermy coworker undid the ldap part and reverted to sql auth inorder to add it00:55
ayoungtelemonster, OK...restart the keystone server and try to get a token, then00:55
telemonsterI can do that with it like this:00:56
telemonsteruser_id_attribute = cn00:56
telemonsteruser_name_attribute = sAMAccountName00:56
morganfainbergraildo_, ok looking at that patch now. ayoung seems to have this under control (not that he didn't earlier)00:56
raildo_morganfainberg, haha ok00:56
ayoungmorganfainberg, thanks for stepping in.  Where else can you get first line support from the PTL?00:57
telemonsterkeystone --os-username cloudadmin token-get00:57
telemonster| Property |              Value               |00:57
telemonster| expires  |       2014-11-20T00:56:59Z       |00:57
telemonster|    id    | 2715675a540d4f70ada7cf52749b5fa1 |00:57
telemonster| user_id  |         OpenStack Admin          |00:57
morganfainbergayoung, LOL00:57
morganfainbergayoung, i needed a break from meeting hell day00:57
ayoungthat looks unscoped.  Now you need to try it with OS_TENANTNAME set.00:58
ayoungOK so in the database you have:00:58
telemonster keystone --os-username cloudadmin --os-tenant-name admin token-get00:58
*** htruta_ has joined #openstack-keystone00:58
telemonsterThe request you have made requires authentication. (HTTP 401)00:58
ayoungtelemonster, select * from  user_project_metadata  where userid = 'OpenStack Admin';00:58
ayoungthat returns something now?00:59
rodrigodsmorganfainberg, how is the federation env deployment going?01:00
telemonstermysql> select id,name,extra,default_project_id from user;01:00
telemonster| id                               | name       | extra                               | default_project_id               |01:00
telemonster| ac367c8d070a4f77ab72bb037bb8e4c1 | cloudadmin | {"email": ""} | f88b07200f33441fa8a40354b63b4385 |01:00
telemonsterignore that email :-)01:00
morganfainbergrodrigods, haven't started, literally finished meetings 15 mins ago01:00
rodrigodsmorganfainberg, omg01:00
telemonster select * from user_project_metadata;01:00
telemonster| user_id                          | project_id                       | data                                                                                                |01:00
morganfainbergrodrigods, tuesdays my meetings start at 9am and today finished at 4, 20 minute break for lunch at 2:3001:00
telemonster| ac367c8d070a4f77ab72bb037bb8e4c1 | f88b07200f33441fa8a40354b63b4385 | {"roles": [{"id": "3048097427ba4e3f85931ad888862721"}]}                                             |01:00
telemonsterthen the role ...01:01
morganfainbergrodrigods, and all of those are upstream/openstack (no internal meetings included)01:01
telemonstermysql> select * from role;01:01
telemonster| id                               | name            | extra                                                                     |01:01
telemonster| 3048097427ba4e3f85931ad888862721 | admin           | {}                                                                        |01:01
rodrigodsmorganfainberg, omg^301:01
rodrigodstelemonster, would be nice to paste those information in paste.openstack.org01:02
rodrigodstelemonster, easier to read01:02
telemonsterooo your own pastebin!01:02
telemonsteryea let me utilize that01:02
rodrigodsmorganfainberg, know about 1 person that succeeded implementing k2k following my blog post, let me know if you use it as reference anytime hehe01:03
raildo_morganfainberg, how much time per day do you sleep? 1, 2 hours? haha01:03
morganfainbergraildo_, why do you ask? I tend to go to sleep around 10pm these days, up at 6-6:30.01:03
morganfainbergraildo_ so .. 7-8hrs?01:03
raildo_just curiosity haha01:04
morganfainbergi also try and move slow for breakfast / lunch where possible01:04
ayoungtelemonster, ok so01:04
morganfainbergraildo_, ok i see something we need to solve in that patch before it can go in.01:04
telemonsterhere is the paste01:04
morganfainbergraildo_, getting the details before I comment01:05
raildo_morganfainberg, I arrive at work, you're online, I come back home, you're online hahaa01:05
raildo_morganfainberg, ok01:05
morganfainbergraildo_, i work from home.01:05
telemonsterayoung - are there other tables that should have pointers as well?01:05
rodrigodsraildo_, that's not true, morganfainberg appears after our lunch =)01:05
morganfainbergraildo_, and have my phone connected to IRC (i usuaully ignore it when i'm not at my desk)01:05
ayounginsert into user_project_metadata  values ('Cloud Admin', 'f88b07200f33441fa8a40354b63b4385', ' {"roles": [{"id": "3048097427ba4e3f85931ad888862721"}]}');01:05
morganfainbergraildo_ i also have ZNC online so i don't ever leave the channel really.01:05
ayoungmake that01:05
ayounginsert 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
morganfainbergoh wow, we need to do a SQL collapse.01:06
rodrigodsraildo_ you will always see me online -> bip01:06
ayoungtelemonster, you see what I am getting at?01:06
morganfainbergoh boy.01:06
ayoungmorganfainberg, I want to move them to icehouse, but first get them up and running01:06
telemonsterhah I think I get it01:06
morganfainbergayoung, ++01:06
ayoungor even Juno....01:06
morganfainbergjuno would be better, but...01:07
morganfainbergi'd go baby steps01:07
telemonsterTHANK YOU SO MUCH!!!01:07
ayoungI can get them to set up a Keystone server using the Juno code, LDAP, and a backup of their sql data01:07
telemonsterIt worked01:07
morganfainbergayoung, ++ yessss01:07
telemonsterlet me check something01:07
ayoungtelemonster, OK, I'm going home now.  I miss my family01:07
* ayoung pops smoke01:08
* ayoung moves out01:08
* ayoung draws fire01:08
telemonsterayoung - thanks much, so much01:08
telemonsterI'll try to come up with some document and put it out public?01:08
telemonsterso others have a path?01:08
ayoungtelemonster, I'll check back in once I'm home and say hello to my family01:08
telemonsterokay sounds good, do that!! Thanks again01:08
telemonster(to everyone !!)01:08
ayoungglad to help.01:09
*** ayoung has quit IRC01:09
*** nkinder has joined #openstack-keystone01:09
raildo_morganfainberg,so.. what we have to solve about the patch?01:11
morganfainbergraildo_, ok commented01:12
morganfainbergraildo_, but in short, you're missing the SQL migration01:12
morganfainbergyou're adding it to the the table construct, but not to the DB backend01:12
raildo_morganfainberg, i'll read the comment01:12
morganfainbergdb schema01:12
raildo_morganfainberg, ok, i'll do that01:12
morganfainbergso you'll need a SQL Alchemy migration and then you can likely use the @handle conflicts decorator01:13
morganfainbergrather than needing custom "try/except" code01:13
raildo_morganfainberg, great, thanks :)01:13
morganfainbergthen duplicates can never occur because the DB schema prevents it01:13
morganfainbergthe migrate will need to resolve duplicates somehow though01:13
raildo_i understand... I'll implement it now :)01:15
*** _cjones_ has quit IRC01:34
*** jorge_munoz has joined #openstack-keystone01:39
*** gyee has quit IRC01:40
*** jorge_munoz has quit IRC01:42
*** jorge_munoz has joined #openstack-keystone01:42
*** jorge_munoz has quit IRC01:44
lbragstadmorganfainberg: whoop whoop!!01:47
*** joesavak has quit IRC01:53
*** patrickeast has left #openstack-keystone02:05
*** ayoung has joined #openstack-keystone02:05
*** ChanServ sets mode: +v ayoung02:05
*** amcrn has quit IRC02:08
*** ncoghlan is now known as ncoghlan_afk02:12
*** NM has joined #openstack-keystone02:24
*** raildo_ has quit IRC02:30
openstackgerritDave Chen proposed openstack/keystone: Add new "RoleAssignment" exception
*** ncoghlan_afk is now known as ncoghlan02:31
*** ncoghlan is now known as ncoghlan_afk02:36
*** erkules_ has joined #openstack-keystone02:36
*** erkules has quit IRC02:38
openstackgerritDave Chen proposed openstack/keystone: Add new "RoleAssignment" exception
*** soulxu_ has joined #openstack-keystone02:43
*** marcoemorais has quit IRC02:43
*** alex_xu has quit IRC02:46
*** ncoghlan_afk is now known as ncoghlan02:46
jamielennoxanyone know how oslo.policy interprets "admin_api": "is_admin:True"02:47
jamielennoxi assume is_admin is the role == admin ?02:47
*** marg7175 has quit IRC02:50
*** soulxu__ has joined #openstack-keystone02:52
*** stevemar has joined #openstack-keystone02:52
*** ChanServ sets mode: +v stevemar02:52
*** soulxu_ has quit IRC02:55
*** soulxu_ has joined #openstack-keystone02:58
*** soulxu__ has quit IRC03:02
*** jdennis has quit IRC03:04
*** soulxu__ has joined #openstack-keystone03:04
*** links has joined #openstack-keystone03:04
*** dims_ has quit IRC03:05
*** dims has joined #openstack-keystone03:06
*** soulxu_ has quit IRC03:07
openstackgerritSteve Martinelli proposed openstack/python-keystoneclient: OAuth headers are missing
openstackgerritTakashi NATSUME proposed openstack/keystone: Enable cloud_admin to list projects in all domains
*** soulxu_ has joined #openstack-keystone03:12
*** soulxu__ has quit IRC03:16
*** harlowja is now known as harlowja_away03:16
*** soulxu__ has joined #openstack-keystone03:18
*** soulxu_ has quit IRC03:22
*** jdennis has joined #openstack-keystone03:22
ayoungjamielennox, I don't think there is any magic there03:22
jamielennoxyea, i think i figured it out03:23
ayoungwhat policy file are you looking at?03:23
ayoungkeystone?  it is if the Service token is set03:23
*** htruta_ has quit IRC03:23
jamielennoxayoung: it's just doing a look for 'is_admin': True in the passed context03:23
jamielennoxbeen a while since i've done policy stuff03:23
ayoungright, which is set by the service token or if the admin role is set...middleware something or other03:23
jamielennoxmmmm, is that provided by oslo.middleware?03:24
jamielennoxoh, good there is no common yet03:26
*** soulxu_ has joined #openstack-keystone03:27
*** zzzeek has quit IRC03:30
*** soulxu__ has quit IRC03:31
*** NM has quit IRC03:31
jamielennoxayoung: no, it does exist - it's being worked on:
jamielennoxshould we try to remove some of this03:32
jamielennoxkill the is_admin concept or own it in keystonemiddlewaer?03:32
ayoungis that another "make the token into a python object" implementation?03:38
*** chrisshattuck has joined #openstack-keystone03:39
ayoungI kindof loath all of the implementations I've seen so far.03:39
ayoungespecially the one I wrote03:39
jamielennoxayoung: 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 engine03:44
jamielennoxayoung: i would therefore think it should belong in an upcoming oslo.policy03:45
*** soulxu__ has joined #openstack-keystone03:45
jamielennoxthough it's a helper and not a requirement03:45
ayoungpronounce pick-pree03:45
jamielennoxoslo_policy is fine03:46
ayoungnah, we can't use the name oslo we've been told.03:46
ayoungbut whatever03:46
jamielennoxthe 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 itself03:47
ayoungyeah, all of this needs to be unified in the library03:47
jamielennoxwe can probably just put that context into keystonemiddleware with some smarts about how to load it from the expected headers03:47
ayoungwe should start by cleanin up the keystone code in common/controller.py03:47
jamielennoxayoung: resurrcet the pecan?03:47
morganfainbergit can't be oslo_policy if it's under ourprogam03:48
ayoungI think that it should be a straight Python object....marshall to it from JSON03:48
jamielennoxmorganfainberg: if we make the core group keystone-core what difference does it make03:48
*** soulxu_ has quit IRC03:48
morganfainbergjamielennox, it would need to be oslo-core if it was under oslo03:48
*** jorge_munoz has joined #openstack-keystone03:49
ayoungwhat's in a name03:49
*** sigmavirus24 is now known as sigmavirus24_awa03:49
morganfainbergand if we want it graduated this cycle it's coming to us03:49
jamielennoxmorganfainberg: did you know about oslo.context?03:49
jamielennoxayoung: any name like that is way to generic03:49
jamielennoxi don't think i'd use this policy engine out of openstack03:49
ayoungmorganfainberg, OK,  since the three of us are here, let's have this whole context thing out03:49
ayoungjamielennox, you wrote one in client that passes through to the JSON.  I wrote a crappy one for revocaking events03:50
ayoungmorganfainberg, you want us to use...which one again?03:50
*** jorge_munoz has quit IRC03:50
jamielennoxi wrote an auth_plugin - which is very similar03:50
jamielennoxif we could convert token -> context it would be the same thing03:51
*** soulxu_ has joined #openstack-keystone03:51
ayoungTODO(morganfainberg): Collapse this logic with AuthContextMiddleware03:51
ayoungthat is from
ayoungthe revocation events uses03:52
ayoungthen we have the helper in the token03:53
*** soulxu__ has quit IRC03:54
ayoungwe have the model code...03:54
ayoungthat is minimalistic03:54
ayoungwhich is the best one we have so far?03:55
morganfainbergayoung, sorry what are we trying to solve03:58
morganfainbergi'm brain fried03:58
ayoungmorganfainberg, we have about a gazillion different objects to represent the unpacked state of the token03:58
jamielennoxnova has there own as well03:58
*** jorge_munoz has joined #openstack-keystone03:58
jamielennoxso do most others03:58
ayoungtrying to get rid of a few.03:58
morganfainbergthe one inside keystone i wrote will be mucked with a bit more to be a base state that we can convert to the JSON03:58
morganfainberge.g. format03:58
ayoungmorganfainberg, which one is that?03:59
morganfainbergayoung, the model in keystone03:59
morganfainbergthe idea is that one is what we pass to the formatter03:59
ayoungor what file?03:59
ayoungfrom keystone.models import token_model03:59
morganfainbergthat one03:59
ayoungthat is in AuthCOntextMiddleware03:59
jamielennoxi was looking at what happens if we rename the admin role, turns out it's mostly file because the services all cheat03:59
morganfainbergthat one is going to change to be more "internal keystone" [the direction it was headed already]04:00
*** soulxu_ has quit IRC04:00
morganfainbergthat will move away from being a bad copy of AccessInfo andto the base state of "token data" which then can be formatted04:00
ayoungyou you are using the JSON as the state of the object and exposing the properites as getters04:00
*** jorge_munoz has quit IRC04:00
ayoungjamielennox, you ok with that approach?04:00
morganfainbergthat one wont be a dict w/ gettrs and such when i'm done with policy cleanup04:01
morganfainbergit's getting turned on it's head04:01
jamielennoxayoung which appraoch?04:01
*** soulxu_ has joined #openstack-keystone04:01
ayoungjamielennox, nevermind,  morganfainberg 's going a different direction anyway04:01
morganfainbergthat was the intermidiary step so we could have only 1 way to reference tokend ata inside of keystone04:01
morganfainbergoutside of keystone04:01
jamielennoxmorganfainberg: we need a cross project approach - and i don't think it can be your token model04:02
morganfainbergi'm ok with using the AccessInfo type thing04:02
morganfainbergjamielennox, no it can't04:02
ayoungmorganfainberg, OK.  I would suggest that the end state be a pure python object04:02
ayounga POPO if you will, to bastardize a term from Java04:02
morganfainbergayoung, that is the plan, it's how the interface on the token providers will actually work04:02
morganfainbergthat 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
jamielennoxso to get around hardcoding the "admin" role projects do:
morganfainbergayoung, now outside of keystone - i don't have a good answer.04:03
jamielennoxthen fetch that value from the policy
ayoungmorganfainberg, OK.  We start with a simple token object model and take it from there.  Next it moves over to keystoneclient04:04
ayoungor, if you want to make keystonecommon, I'm cool with that04:04
jamielennoxthen check if either 'admin' or that value is set:
morganfainbergi'm thinking we want it in a common lib04:04
jamielennoxthen rely on is_admin that way04:04
ayoungOK, lets go with that for now04:04
morganfainbergso we can have places use it w/o needing all of keystoneclient.04:04
jamielennoxso you can completely change the name of the admin role - but it's symbolic and everything still works on the admin concept04:05
ayoungthat needs to die04:05
ayoungis_admin is_broken04:05
jamielennoxbut at least is_admin doesn't have to be 'admin' :) shoot me04:05
ayoungjamielennox, I'll have to send a drone to shoot you, you are currently out of my max-effective range04:06
jamielennoxthese lines are particularly fun:
ayoungadmin admin duck04:07
jamielennoxso 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' string04:07
jamielennoxnope got nothing04:07
morganfainbergi uh..04:07
morganfainbergwut.04:07 does you guys at least understand my current focus on policy and where I want to go with it?04:07
ayoungand are basically aligned?04:08
morganfainbergayoung, for the most part i have an idea.04:08
jamielennoxayoung: mostly, and enough04:08
morganfainbergi don't think you're wildly off base or anything04:08
ayoungis storing in the database an OK option?04:08
morganfainbergayoung, oh absolutely04:08
morganfainbergin *a* backend.04:08
morganfainbergwhich might just be SQL04:08
morganfainbergbut same concept04:08
jamielennoxi actually think if we do the server side role aliasing etc, then dynamicly fetching the policy isn't that important04:08
ayoungyeah....the schema for the current rules thing might be hideous04:09
morganfainbergjamielennox, we still need it centralized for $OTHER_REASONS$04:09
morganfainbergaka horizon knowing what you can do, etc04:09
ayoungmore important is the clean up of things like that cinder code04:09
morganfainbergits just not as important for the policy enforcement part04:09
morganfainbergayoung, ++04:09
ayoungand the ability to break apart admin into its fundamental parts04:09
jamielennoxi just mean at one stage we were talking about making the definition really dynamic, like different policy files for each domain/project04:09
jamielennoxi like the server side roles approach way better04:10
ayoungjamielennox, so, yeah, that stays on Keystone server04:10
ayoungmake them aliases for the things that will show up in policy04:10
morganfainbergjamielennox, lets not jump to project/domain policy04:10
morganfainberglets worry about that after we have everything in place that we could do it04:10
ayoungOK...need to head to bed...04:10
morganfainbergit may not be needed04:10
jamielennoxwell we don't need it04:10
jamielennoxis what i meant, i prefer the server doing role/capability resolving than making it a policy decision04:11
ayoungmorganfainberg, its what Henrynash is working towards...I'd have prioritized it after everything else04:11
ayoungI think making it a policy decision is the cleaner approach04:11
ayoungotherwise, tokens get huge, but policy stays static and broken04:12
ayoungmaybe first thing is getting a unified policy file04:12
ayoungeven if we don't dynamically generate it04:12
jamielennoxpolicy just becomes a way of naming capabilities, tokens include the global capabilities available04:12
*** jorge_munoz has joined #openstack-keystone04:12
jamielennoxpolicy engine enforces those capabilities04:13
jamielennoxit's just unfortunate we're going to end up with so many definitions of 'role'04:13
ayoungok...gotta crash04:13
*** ayoung is now known as ayoung-ZZZzzzZzz04:13
*** jorge_munoz has quit IRC04:15
*** soulxu__ has joined #openstack-keystone04:21
*** jdennis has quit IRC04:22
*** soulxu_ has quit IRC04:24
*** soulxu_ has joined #openstack-keystone04:31
*** soulxu__ has quit IRC04:33
*** marg7175 has joined #openstack-keystone04:34
*** marg7175 has joined #openstack-keystone04:35
*** soulxu__ has joined #openstack-keystone04:36
*** soulxu_ has quit IRC04:39
*** tellesnobrega has quit IRC04:44
*** soulxu_ has joined #openstack-keystone04:50
*** marg7175 has quit IRC04:52
*** soulxu__ has quit IRC04:53
*** soulxu__ has joined #openstack-keystone04:56
*** soulxu_ has quit IRC04:59
*** jorge_munoz has joined #openstack-keystone05:00
*** jorge_munoz has quit IRC05:04
*** soulxu_ has joined #openstack-keystone05:09
*** chrisshattuck has quit IRC05:11
*** soulxu__ has quit IRC05:12
*** ncoghlan is now known as ncoghlan_afk05:27
*** boris-42 has joined #openstack-keystone05:39
*** soulxu__ has joined #openstack-keystone05:42
*** soulxu_ has quit IRC05:45
*** k4n0 has joined #openstack-keystone05:52
*** soulxu_ has joined #openstack-keystone05:53
*** soulxu__ has quit IRC05:56
*** soulxu__ has joined #openstack-keystone06:00
*** links has quit IRC06:02
*** stevemar has quit IRC06:02
*** soulxu_ has quit IRC06:03
*** ncoghlan_afk is now known as ncoghlan06:04
*** david-ly_ has joined #openstack-keystone06:11
*** david-lyle_afk has quit IRC06:12
*** soulxu_ has joined #openstack-keystone06:12
*** soulxu__ has quit IRC06:15
*** ukalifon1 has joined #openstack-keystone06:31
*** k4n0 has quit IRC06:39
*** ukalifon1 has quit IRC06:50
*** marg7175 has joined #openstack-keystone06:53
*** k4n0 has joined #openstack-keystone06:54
*** marg7175 has quit IRC06:57
*** david-ly_ has quit IRC07:18
*** kevinbenton has quit IRC07:22
*** k4n0 has quit IRC07:31
*** soulxu_ is now known as alex_xu07:36
*** ukalifon1 has joined #openstack-keystone07:43
*** k4n0 has joined #openstack-keystone07:44
*** amerine has joined #openstack-keystone07:47
*** boris-42 has quit IRC07:47
*** samuelms_ has joined #openstack-keystone07:51
*** nellysmitt has joined #openstack-keystone07:53
*** samuelms_ has quit IRC08:03
*** marekd|away is now known as marekd08:12
*** alex_xu has quit IRC08:13
*** links has joined #openstack-keystone08:21
*** ajayaa has joined #openstack-keystone08:37
*** david-lyle_afk has joined #openstack-keystone08:49
*** NM has joined #openstack-keystone08:50
*** samuelms_ has joined #openstack-keystone08:51
*** marg7175 has joined #openstack-keystone08:53
*** amerine has quit IRC08:53
*** amerine has joined #openstack-keystone08:54
*** NM has quit IRC08:54
*** marg7175 has quit IRC08:57
*** henrynash has joined #openstack-keystone09:15
*** ChanServ sets mode: +v henrynash09:15
marekdhenrynash: can you take a look at the patch ?09:15
henrynashmarekd: sure09:15
marekdhenrynash: thanks09:15
samuelms_hi marekd, henrynash :)09:16
*** oomichi has quit IRC09:16
marekdsamuelms_: hey09:16
henrynashsamuelms: hi09:16
marekdsamuelms_: 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 erkules09:18
marekdsamuelms_: lol09:18
samuelms_henrynash, I was thinking about role-groups vs hierarchical roles ..09:18
marekdsamuelms_: what are role-groups09:18
henrynashsamuelms: ok09:18
marekdwhere can i read about it09:18
samuelms_henrynash, do you have a couple of minutes to discuss?09:18
samuelms_marekd, hierarchical roles
henrynashsamuelms: let me just finish reviewing marekd’s patch09:19
samuelms_marekd, group of rles
samuelms_henrynash, sure09:19
marekdsamuelms_: and that's all or some introductionary reading is required?09:21
*** ityaptin has quit IRC09:21
samuelms_marekd, I think that's enough09:23
marekdsamuelms_: and more info about hierarchical multitenancy?09:24
marekdlike i know almost nothing about it and for some reasons i need to know more.09:24
samuelms_marekd, hmm09: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
samuelms_marekd, in which we have a part merged .. and a part under review09:26
*** esp has quit IRC09:26
samuelms_marekd, the part that is still under review starts at
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 soon09:28
marekdsamuelms_: 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
marekdsamuelms_: so start with icehouse09:33
samuelms_marekd, ok .. will do09:33
marekdsamuelms_: yes, icehouse is just keystone acting as a SP09:33
*** ncoghlan has quit IRC09:39
*** jamielennox is now known as jamielennox|away09:41
henrynashsamuelms: hi09:47
*** ajayaa has quit IRC09:50
samuelms_henrynash, hi09:50
samuelms_henrynash, so I was thinking that, basically, role-groups and hierarchical roles have the same goal09: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
henrynashsamuelms: well, I think you can implement hieracrchical role-groups…not hierarchical roles09:53
samuelms_henrynash, but they can do the same, right?09:53
marekdhenrynash: thanks for the review, will fix soon.09:54
henrynashsamuelms: well, the same effect, yes09: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
henrynashsamuelms_: so part of my argument here is that many, many peopel won’t use hierachies at all…but they do want role groups09:55
samuelms_henrynash, right09:55
samuelms_henrynash, roles are groups of capabilities, right?09:56
henrynashsamuelms: …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 down09:56
henrynashsamuelms_: 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-user09:58
henrynashsameulms_: agreed…and infact we could work toward this….take the following example10:00
*** esp has joined #openstack-keystone10:00
henrynashsameulms_: we introduce this new role-group thing….let’s actually call them “domain-roles”10:00
henrynashsameulms_: service policy files start to fill out thirpooicy file with more and more one role for one API10: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
henrynashsamuelms_: nearly all assignments become doman-role assignments10:02
henrynashsamuelms_: listing a domain-role now effectively lists teh capabilities of that domain role10:02
henrynashsamuelms_: 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 scratch10:04
henrynashsamuelms_: I guess that’s what I’m pitching as a way this all eveolves10:04
samuelms_henrynash, hmm interesting10: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
henrynashsamuelms_: 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
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 policy10:11
samuelms_henrynash, so that we can start representing  'what capabilities a role has?' for domain-roles ..10:11
samuelms_henrynash, right?10:11
henrynashsamuelms_: 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 that10:12
samuelms_henrynash, :D10:12
samuelms_henrynash, I can't see how would be the transition .. like defining a separated policy for domain-roles -> capabilities?10:14
henrynashsamuelms_: not sure I follow10: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', etc10:17
henrynashsamuelms_: 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 it10:19
henrynashsamuelms_: so I remain unconvinced (yet convincable!) that we need to change policy10:19
henrynashsamulems_: at least not for this reason…there may be others outside of this10: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 role10:21
samuelms_henrynash, what would be that capabilities? would be the API calls?10:21
henrynashsamuelms_:  if someone has chosen to craete fine grained roles and assign one to each API, yes10:22
henrynashsamuelms_: but that’s there option, I don’t want to force people to have to do that10:22
*** aix has joined #openstack-keystone10:23
samuelms_henrynash, hm.. so roles are capabilities ..10:24
samuelms_henrynash, wait, let me write something in an etherpad10:24
henrynashsamuelms_: for peopele who have craeted them that way, yes10:24
*** ajayaa has joined #openstack-keystone10:26
*** lhcheng has joined #openstack-keystone10:33
*** tellesnobrega has joined #openstack-keystone10:38
samuelms_henrynash, ok I think we converged to the idea I was thinking about10:38
samuelms_henrynash, we can talk more about this later, when everyone is up :D10:39
henrynashok, speak later10:39
*** henrynash has quit IRC10:39
*** boris-42 has joined #openstack-keystone10:40
*** lhcheng_ has joined #openstack-keystone10:50
*** lhcheng has quit IRC10:53
*** tellesnobrega has quit IRC10:56
*** xianghui_ is now known as xianghui10:58
*** samuelms_ has quit IRC10:58
*** henrynash has joined #openstack-keystone11:05
*** ChanServ sets mode: +v henrynash11:05
*** henrynash has quit IRC11:08
*** dims has quit IRC11:09
*** dims has joined #openstack-keystone11:09
*** henrynash has joined #openstack-keystone11:09
*** ChanServ sets mode: +v henrynash11:09
samuelmshenrynash, just one more thing I'd like to synchronize with you :)11:18
samuelmshenrynash, have in mind that model we've discussed .. 'defining permissions on-the-fly'11:19
samuelmshenrynash, how could a domain admin set that people with the domain-role 'member' should be allowed to get_project only of their project11:21
*** diegows has joined #openstack-keystone11:21
samuelmshenrynash, basically, how could we set constraints like 'project_id:%(project_id)s'11:22
samuelmshenrynash, on-the-fly11:22
samuelmshenrynash, 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
henrynashsamuelms: 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
samuelmshenrynash, because you have to be member on the project you're requesting get_project11:37
samuelmshenrynash, and then you must have the 'project_id:%(project_id)s' thing11:37
samuelmshenrynash, 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 domain11:38
henrynashsamuelms: well that just ensures you have project token for the right project…11:39
samuelmshenrynash, so that we give flexibility to different domains .. it is like having one policy file per domain (now on-the-fly policy) :)11:39
henrynashsamuelms: before we agree that we need this additional level of fleibility….I’m still unclear on the problem we are trying to solve11:40
*** vsilva_ has joined #openstack-keystone11:40
*** tellesnobrega has joined #openstack-keystone11:40
samuelmshenrynash, yes .. what we agreed is clear ..11:40
samuelmshenrynash, but now .. suppose the following use case:11:41
samuelmshenrynash, domain_a where project members can get_project on any project11:41
samuelmshenrynash, domain_b where project members can get_project *only* on the project he is member11:41
samuelmshenrynash, how to fit both requirements if we have a single policy file?11:42
samuelmshenrynash, we need to put 'project_id:%(project_id)s' for domain_a, but not for domain_b11:42
samuelmshenrynash, makes sense?11:42
henrynashsamuelms: I would give all the users domain-inherited role that let them do get_project11:42
samuelmshenrynash, oh wait .. but this give all domain-admin capabilities11:43
samuelmshenrynash, I don't want this .. just in the case of projects11:44
*** ekarlso- has quit IRC11:44
henrynashsaumelms: no….it’ an inherited role…so only truns up on projects...11:45
samuelmshenrynash, ok . I understand your point11:47
samuelmshenrynash, but think about reseller use case11:47
samuelmshenrynash, wait I'll get a better example11:48
*** kashyap has joined #openstack-keystone11:48
*** ekarlso- has joined #openstack-keystone11:49
samuelmshenrynash, in our previous discussion, we defined a such amazing idea that allows domain admins to define what roles access what capability, right?11:51
samuelmshenrynash, on-the-fly :)11:51
henrynashsamuelms: indeed11:51
henrynashsamuelms: (“amazing” might be pushing it….)11:52
*** aix has quit IRC11:52
samuelmshenrynash, haha, yes .. just kidding :)11:52
samuelmshenrynash, so, what I'm thinking now is:11:52
samuelmshenrynash, beside roles, I'm saying that we should allow them to add others constraints for capabilities11:53
henrynashsamulems: 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
samuelmshenrynash, 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
henrynashsamuelms: or whether you just think it is more intuaive to admins11:54
samuelmshenrynash, my points with this is flexibility11:55
samuelmshenrynash, imagine things like: users with this domain-role can only create instances with a project if available quotas > 40%11:55
henrynashsamuelms: ah, ok…so you want to do this becsue our new “capabilities” are still not fine grained enough (or maybe lack context)?11:55
samuelmshenrynash, EXACTLY11:56
samuelmshenrynash, we that would be good to make them more  fine grained, do you agree?11:57
samuelmshenrynash, we could do amazing things with those constraints (querying resource states, for e.g. available quotas, etc)11:59
henrynashsamuelms: 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 provider11:59
samuelmshenrynash, exactly12:00
henrynashsamules: 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
samuelmshenrynash, and then with all this ^ we don't have to have one policy file per domain12:00
henrynashsamuelms: agreed….it’s an alternative approach….12:01
samuelmshenrynash, ok .. makes sense ..12:01
samuelmshenrynash, is there a convergence point between this approach and adam's one?12:02
samuelmshenrynash, maybe ..12:02
samuelmshenrynash, I need to document all this .. will do in an etherpad, ok? think will be better to present the whole idea to other people12:02
henrynashsamuelms: 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 IRC12:05
samuelmshenrynash, cool12:06
samuelmshenrynash, 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
henrynashsamuelms: 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 that12:10
henrynashsamuelms: 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 IRC12:12
samuelmshenrynash, :DDD12:14
samuelmshenrynash, totally agree12:14
samuelmshenrynash, so let's close this point and start the last one I thought :p12:14
samuelmshenrynash, suppose now we're in the future and we've all this implemented12:14
henrynashsamulems: so a ne service could register themslevs, their services and egt going…all via REST !12:14
samuelmshenrynash, exactly12:15
henrynashsamuelms: ok, back to reality12:15
samuelmshenrynash, haha .. wait12:15
samuelmshenrynash, just the last point12:15
samuelmshenrynash, suppose we're in a future where we've all this implemented, ok?12:15
samuelmshenrynash, this morning adam will come with his idea of hierarchical roles ..12:15
samuelmshenrynash, how do we implement that?12:15
samuelmshenrynash, answer: domain-role (role groups) composition12:16
samuelmshenrynash, as I told you earlier12:16
henrynashsamuelms: 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-roles12:17
samuelmshenrynash, exactly ! :D12:17
samuelmshenrynash, now we can get back to the reality12:17
samuelmshenrynash, where I'll write a etherpad clarifying this proposal and listing all the points :)12:18
samuelmshenrynash, ok?12:18
henrynashsamulems: 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 yours12:18
samuelmshenrynash, ok12:18
samuelmshenrynash, I'll request your review before exposing it to everybody12:18
henrynashsamuelms: ok!12:18
samuelmshenrynash, to avoid confusing people with naming :)12:19
samuelmshenrynash, I think I will use the spec template ..12:19
ekarlso- - anyone know why that's failing ?12:21
rodrigodsmarekd, are you working in the dynamic checking patch? otherwise I can address the comments here and submit12:26
*** alex_xu has joined #openstack-keystone12:34
*** tellesnobrega has quit IRC12:42
*** aix has joined #openstack-keystone12:42
*** jdennis has joined #openstack-keystone12:49
*** ekarlso- has quit IRC12:50
*** ekarlso- has joined #openstack-keystone12:50
*** afazekas has joined #openstack-keystone12:53
*** dims has quit IRC12:58
*** dims has joined #openstack-keystone12:58
*** kashyap has quit IRC13:00
*** henrynash has quit IRC13:00
openstackgerritRodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc
openstackgerritDave Chen proposed openstack/keystone: Add new "RoleAssignment" exception
*** dims has quit IRC13:08
*** ajayaa has quit IRC13:08
*** dims has joined #openstack-keystone13:08
*** topol has joined #openstack-keystone13:09
*** ChanServ sets mode: +v topol13:09
*** jaosorior has joined #openstack-keystone13:12
*** NM has joined #openstack-keystone13:15
*** richm has joined #openstack-keystone13:23
marekdrodrigods: if you haven't started it yet i can do this.13:25
marekdrodrigods: was busy with sth else.13:25
rodrigodsmarekd, you can start, thanks =)13:28
marekdrodrigods: OK13:29
openstackgerritDavid Chadwick proposed openstack/keystone-specs: Specification for IETF ABFAB federation
*** ayoung-ZZZzzzZzz is now known as ayoung13:33
ayoungrodrigods, 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-keystone13:34
rodrigodsayoung, isn't this a step for the future?13:35
rodrigodsI mean, after we get some stuff in place first13:35
ayoungwe can parallelize13:35
ayoungthey can all use the same file, we just need a means to deploy it, which could be done by puppet13:36
ayoungI populated with the keystone cloud-sample to start13:36
samuelmsayoung, works for me13:36
samuelmsayoung, taking a look at the pad13:36
ayounglet me add in nova and glances.13:37
ayoungglance needs to be namespaced as I recall13:37
rodrigodsayoung, omg13:38
ayoungjust added cinder at the bottom13:38
samuelmsayoung, what roles are you expecting to be used on that unified policy?13:38
samuelmsayoung, those reader, writer ones?13:38
ayoungsamuelms, to start  just member13:38
samuelmsayoung, ok13:39
samuelmsayoung, member and the default admin .. right13:39
rodrigodsayoung, samuelms, how well is the hierarchical roles vs group roles synchronized?13:39
ayoungI'm going to put in comments using #  but those will need to be stripped out to be valid JSON13:39
rodrigodsI mean, is it the same thing after all or not13:39
ayoungMember?  Sort of....13:40
*** tellesnobrega has joined #openstack-keystone13:40
ayoungits kindof cheating13:40
*** tellesnobrega has quit IRC13:40
ayoungright now, there are a bunch of Nova rules that accept any role for the project13:40
ayoungwe make a rule that converts that to either member on the project or admin on the project to start13:41
marekdwhat do we have, in general, in service catalog - objects? entities?13:41
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Remove middleware architecture doc
ayoungmarekd, the entities in the service catalog are services, with endpoints scoped below them13:42
marekdayoung: ok13:43
marekdayoung: and, something like identity_provider in Keystone is what?13:43
marekdwhat's the good name to call such things?13:43
samuelmsayoung, omg .. that nova policy lol13:43
rodrigodsayoung, samuelms, it hurts my eyes every time I open that json file13:44
rodrigods300+ rules13:44
*** richm has quit IRC13:44
samuelmsayoung, rodrigods do you have a link for the unified policy spec? (we have one, right?)13:45
rodrigodssamuelms, just a sec13:45
ayoungsamuelms, yeah, one sec13:45
rodrigodsayoung, I won \o/13:45
samuelmsrodrigods, thanks13:45
ayoungyes.  yes you did.13:45
ayoungI wonder if we can make a rule that will get ignored just to use for comments13:46
rodrigodsayoung, good workaround13:47
ayounglike  "identity:aaa-header-aaa" :""13:47
ayounggonna do that13:47
rodrigodsor "comment: ..."13:47
ayoungrodrigods, I want to be able to sort the file by ABC order13:48
ayoungwith the exception of the common rules13:48
ayoungand I think each rule needs to be unique.13:48
rodrigodsayoung, why not by service?13:48
ayoungrodrigods, yes,  by services13:48
rodrigodsby services and ABC13:49
ayoungeach rule should be prefixed by the service name, like "identity:create_endpoint"13:49
rodrigodshmm, true13:49
samuelmsayoung, great13:49
rodrigodsso "identity:COMMENT"13:50
rodrigodssomething to catch the eyes for the reader13:50
samuelmsrodrigods, the problem is that we cant repeat that13:50
ayoungrodrigods, samuelms before you make any changes to the pad,  make sure there is a saved revision.13:50
rodrigodssamuelms, so we add As or Bs or 1s or 2s13:50
ayoungI just did the initial one13:50
ayoungrodrigods, only for comments13:51
samuelmsayoung, neutron and glance are the only services that have no prefix on API operations13:51
ayoungyeah, but some of the others have multiple, and there might be conflicts13:52
rodrigodssamuelms, do have the link from afaranha patches there?13:52
samuelmsayoung, so we should add image:: for glance and network:: for neutron?13:52
samuelmsrodrigods, yes .. just a sec13:52
ayoungcinder has "backeup": for example13:52
ayoungand nova has a bunch that start with volume13:53
ayoungand network13:53
*** jistr has joined #openstack-keystone13:53
openstackgerritMarek Denis proposed openstack/keystone-specs: Service Provider for K2K
*** jistr is now known as jistr|mtg13:53
rodrigodsayoung, why not just add the service name?13:53
samuelmsrodrigods, ++13:54
ayoungrodrigods, heh,  you used the word "just"13:54
ayoungdo you really think *just* adding the service name would be simple?13:54
rodrigodsmarekd, omg, you're fast =)13:54
rodrigodsmarekd, could you add me as contributor? You know I'm interested on it =)13:55
samuelmsayoung, rodrigods err.. maybe after we can rename them after ..13:55
marekdrodrigods: yes, i can add you13:55
samuelmsayoung, rodrigods for now, lets just find a name for cinder and neutron13:55
marekdi will in the following patch, ok?13:55
rodrigodssamuelms, ayoung, the name: cinder and neutron13:55
marekdthis will probably fail13:55
rodrigodsmarekd, ++13:55
ayoungsed 's!just!first!g'13:55
ayoungso cinder should be 'volume' and neutron should be 'network'13:56
samuelmsayoung, rodrigods  ok then .. lets --just-- FIRTS do the work renaming them13:56
ayoungso I think maybe we first steal those back from nova13:56
ayoungwe could make nova's network into compute_network13:57
ayoungand volume into compute_volume13:57
samuelmsayoung, ++13:57
ayoungand I guess volume_extension becomes compute_volume_extension13:58
ayoungwe make nova's network into compute:network13:58
ayounglooks like that is what neutron is doing already13:59
samuelmsayoung, and compute:volume ?13:59
rodrigodsayoung, samuelms ++13:59
rodrigodswas my next suggestion13:59
ayoungI wonder if we could convince neutron to conver create_network into network:create:....14:00
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Correct Session docstring
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Correct documenting constructor parameters
samuelmsayoung, if they believe on unified-policy, why not?14:00
rodrigodsayoung, /join #openstack-neutron14:00
ayoungyes.  IF14:00
rodrigodsayoung, thought we were about to ask the people over there ¬¬14:01
samuelmsayoung, can I start adding the network: prefix for neutron api?14:01
rodrigodsayoung, can you add a nice HM patch to your reviews list?14:07
*** chrisshattuck has joined #openstack-keystone14:08
ayoungrodrigods, it now has a star14:08
samuelmsayoung, maybe an issue with the way we're doing this (the policy) is that we are now lefting breadscrumbs ..14:09
samuelmsayoung, what has changed from the original policy for each service14:09
samuelmsrodrigods, ^14:09
*** ajayaa has joined #openstack-keystone14:10
*** joesavak has joined #openstack-keystone14:10
rodrigodsayoung, ++14:10
ayoungbknudson,  could use a review.14:11
ayoungits been 3 weeks at +214:11
bknudsonthat's my fault?14:12
openstackgerritMerged openstack/keystone-specs: IETF ABFAB federation protocol.
*** chrisshattuck has quit IRC14:13
rodrigodscan I point to a oslo blueprint in a Keystone spec?14:13
*** richm has joined #openstack-keystone14:14
*** richm has left #openstack-keystone14:14
*** richm has joined #openstack-keystone14:14
ekarlso-anyone that can help me with client change ? It's been stuck in there for a while :(14:15
samuelmsayoung, for volume, we left volume_extension: ?14:16
samuelmsayoung, or the idea would be to have everything there starting with volume?14:16
ayoungsamuelms, no matter what we do it is going to cause some churn14:17
samuelmsayoung, rodrigods I think we should put that in a git repo14:18
samuelmsayoung, rodrigods so that we start from the basic structure14:18
samuelmsand keep track of the changes14:18
rodrigodssamuelms, ++14:18
rodrigodsomg, split assignments is going first than HM14:19
rodrigodsrebase hell14:19
marekdrodrigods: ++14:19
marekdrodrigods: you will be sure you really undestand the code :P14:19
rodrigodsmarekd, =P14:21
samuelmsayoung, are you going to create the repo on your github account? or can I do this?14:23
ayoungsamuelms, go ahead.  I'll let you guys drive this.14:24
samuelmsayoung, ok thanks14:24
*** gordc has joined #openstack-keystone14:28
*** openstackgerrit has quit IRC14:33
*** openstackgerrit has joined #openstack-keystone14:33
ayoungsamuelms, I want a version of etherpad backed by git14:39
*** alex_xu has quit IRC14:39
rodrigodsayoung, 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 there14:41
*** nellysmitt has quit IRC14:41
*** amakarov_away is now known as amakarov14:41
*** r-daneel has joined #openstack-keystone14:42
samuelmsayoung, ok .. I'll commit the first version as being only the policies pasted there ..14:42
samuelmsayoung, and the second as it is right now14:42
samuelmssamuelms, haha .. misunderstood what you said :P it should be great to have an etherpad plugin to that14:45
samuelmsayoung, ^14:45
*** jdennis has quit IRC14:48
rodrigodsayoung, thinking about using the keystone-spec anyway =14:48
ayoungrodrigods, " can I point to a oslo blueprint in a Keystone spec? "  not sure what14:49
ayoungthat would imply14:49
ayoungI know there is some tie in between commits and blueprint updates14:49
rodrigodsayoung, yeah, will use the keystone-specs template14:49
*** openstackgerrit has quit IRC14:49
dimsrodrigods: out of oslo's hands :)14:49
*** openstackgerrit has joined #openstack-keystone14:49
rodrigodsdims, thanks!14:49
*** jacorob has joined #openstack-keystone14:50
openstackgerritRodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc
*** stevemar has joined #openstack-keystone14:54
*** ChanServ sets mode: +v stevemar14:54
rodrigodsdstanek, ^ and also =)14:55
rodrigodsdstanek, thanks for the reviews so far14:55
*** jdennis has joined #openstack-keystone15:00
*** nellysmitt has joined #openstack-keystone15:00
ayoungrodrigods, did I do that?15:01
*** thedodd has joined #openstack-keystone15:03
openstackgerritEndre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version
openstackgerritEndre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version
ekarlso-^ morganfainberg15:16
*** marg7175 has joined #openstack-keystone15:19
morganfainbergekarlso-, thanks15:19
openstackgerritAlexander Makarov proposed openstack/keystone: Manager driver parameters support
*** fmarco76 has joined #openstack-keystone15:21
*** sigmavirus24_awa is now known as sigmavirus2415:23
openstackgerritAlexander Makarov proposed openstack/keystone: Manager driver parameters support
*** saipandi has joined #openstack-keystone15:27
*** ukalifon1 has quit IRC15:31
dstanekrodrigods: i'm ready to +2 the doc change once ayoung's comments are addressed15:31
*** henrynash has joined #openstack-keystone15:32
*** ChanServ sets mode: +v henrynash15: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 , 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 plugins15:44
*** thedodd has quit IRC15:55
*** jacorob has quit IRC15:56
samuelmsdstanek, ayoung: rodrigods is at lunch time .. will be back soon15:56
*** mflobo has quit IRC15:57
*** patrickeast has joined #openstack-keystone16:00
*** josecastroleon has quit IRC16:01
*** patrickeast has quit IRC16:02
*** patrickeast has joined #openstack-keystone16:03
* morganfainberg goes to get breakfast now.16:05
morganfainbergayoung, 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 priority16:06
morganfainbergthe reason for this is to make sure people don't sneak BPs onto a milestone w/o us knowing16:06
topolmorganfainberg, OK cool16:07
bknudsonsneaky jerks16:07
bknudsonwhat do we have targeted for k1?16:07
morganfainbergbknudson, uhm...16:08
morganfainbergbknudson, /me hasn't done that yet.16:08
bknudsonI assume it's HMT16:08
dolphmmorganfainberg: ++16:08
dolphmbknudson: there's like 4 bp's16:08
morganfainbergand i need to go through the bugs.16:09
bknudsonk2 is going to be a big hill to climb.16:09
morganfainbergbknudson, yes.16:09
bknudsondstanek is working on Enable tests on non-SQLite databases16:10
bknudsonand Allow a subset of tests to fail16:10
bknudsonand we removed all sorts of deprecated stuff... that should be done?16:10
dstanekbknudson: correcto16:11
bknudsonmorganfainberg: already has code, but no series16:13
morganfainbergbknudson, yeah16:13
morganfainbergthats the stuff i'm expecting to fix today16:13
morganfainbergor ask someone to poke at ;)16:14
*** bdossant has joined #openstack-keystone16:17
*** vejdmn has joined #openstack-keystone16:20
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation
*** agireud has joined #openstack-keystone16:21
henrynashmorganfainberg, ayoung, stevemar: gonna keep chipping away for this one!
stevemarah the deprecation proxy, right henrynash16:23
*** jacorob has joined #openstack-keystone16:25
*** afazekas has quit IRC16:29
*** afazekas has joined #openstack-keystone16:30
*** david-lyle_afk is now known as david-lyle16:34
ayounghenrynash, soooooo...where do you plan on getting assignements from, once this goes in?16:34
henrynashayoung: which?16:34
ayoungsplitting off assignements from projects16:35
ayoungare you going to get projects exteranal from Keystone, or assignments?16:35
henrynashayoung: not sure I follow16:35
ayoungwhat are you hoping to gain from splitting assignments and resources?16:35
henrynashayoung: I’m sure you are asking a deep and meaningful question….I’m just struggling16:36
ayoungDo you expect either to consume something from outside of Keystone?16:36
henrynashayoung: 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/rpojects16:37
ayounghenrynash, "allowing alternative assignments models"  like what?16:37
ayoungdo you have one already?  Guessing that you do, just wondering what it is16:37
henrynashayoung: like an ABAC engine…or the thing that University of Texas is building etc.16:38
henrynashayoung: me, no I don;t have one16:38
ayoungthen why are you prioritizing it?16:38
henrynashayoungL or something Dr Cahdwick might have etc.16:38
ayounghenrynash, what I was thinking was this16:39
*** nellysmitt has quit IRC16:39
ayoungthere are things out there, hierarchical, that might map to the project/domain hierarchy16:39
henrynashayoung: 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 in16:39
ayoungand 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 else16:40
stevemarhenrynash, that was a great answer :)16:40
lbragstadbknudson: curious if you'd be able to take a look at since you had +2'd it previously16:41
lbragstaddstanek:  was look at ^ as well.16:41
lbragstadthe tempest change has a +216:41
ayounghenrynash, 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
bknudsonlbragstad: it doesn't pass jenkins16:41
lbragstadbknudson: it requires a change to tempest16:42
lbragstadtempest core wants to see that it has a +216:42
henrynashayoung: 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 - only affects resource, and the assignment model code is never touched etc.16:42
lbragstadbefore they merge the change to tempest16:42
bknudsonok... I already +2d it.16:42
ayounglbragstad, I can +2 as well16:43
henrynashayoung: I;ll take at least one of those adjectives as a compliment :-)….16:44
lbragstadbknudson: ayoung thanks, tempest has approved the corresponding change to tempest16:44
ayounghenrynash, actually, I was wondering if you had some 3rd party system that you needed to integrate16:44
lhcheng_lbragstad: question on
uvirtbotLaunchpad bug 1393518 in keystone "v3 service catalog returns services without names, but v2.0 api does not" [Medium,Triaged]16:44
ayounghenrynash, cuz I am starting to think in those terms myself16:45
lhcheng_lbragstad: should the name attribute still be included if its empty?16:45
*** gyee has joined #openstack-keystone16:45
*** ChanServ sets mode: +v gyee16:45
henrynashayoung: 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 providers16:45
*** fmarco76 has left #openstack-keystone16:46
*** vejdmn has quit IRC16:46
henrynashayoung: a wrapper is really hard if it covers too many concepts (that may come from different sources)16:46
morganfainberghenrynash, ++16:46
ayounghenrynash, right.  So the thing I was wondering is if it makes sense to think in terms of plugging in a projects backend for each domain16:47
henrynashayoung: “Keystone is a (w)rapper”…I can see the T-shirts already16:47
lbragstadlhcheng_: I'd like to get jamielennox|away 's perspective on it (from dolphm's comment in the bug)16:47
lbragstadif jamielennox|away has does some work to it, he could add some perspective.16:48
*** vejdmn has joined #openstack-keystone16:48
morganfainbergayoung, i'd be worried about jumping too far down that path to start, but... it doesn't sound absurd16:48
henrynashayoung: yeah…I had wondered about that (in the shower, as one does)…akin to what we did with identity16:48
lhcheng_lbragstad, okay I found the bug. Just need to confirm the expected behavior if we want to display or not16:48
dolphmlbragstad: lhcheng_: it'll probably be 5-7 hours before jamielennox|away logs on16:49
lhcheng_lbragstad, I'll try to catch jamielennox|away later16:49
henrynashayoung: 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 sense16:49
dolphmlhcheng_: yes, it should be included in the v3 response16:49
ayoungmorganfainberg, 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 deployment16:49
dolphmlhcheng_: are you seeing it missing on a stable branch, or master?16:49
henrynash(offline for a few minutes)16:49
morganfainbergayoung, lets be careful about locking in the *need* for FreeIPA16:49
ayoungSo, yeah, for projects, I would want to make that either Read Only, or to look closer at how we create objects on the FreeIPA side16:50
ayoungmorganfainberg, not a Need...a possibility16:50
morganfainbergayoung, but supporting that isn't awful. again, i'd be worried about trying to do too much at once this cycle16:50
ayoungmorganfainberg, hostgroups and netgroups are already supportable in LDAP16:50
morganfainbergthis is something i might say we backlog to start, finish what we have on deck and see about adding in that support for16:50
ayoungmorganfainberg, nah, I'm trying to see if we are even headed in that tragectory16: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-keystone16:51
morganfainbergif it makes sense as we see everything else matierialize16:51
dolphmlhcheng_: i didn't realize services could be missing names!16:51
morganfainbergdolphm, :( yeah16:51
*** agireud has quit IRC16:51
lhcheng_dolphm: it is optional based on the specs16:51
ayoungmorganfainberg, 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
dolphmwell that's fun. i knew there was no uniqueness constraint, but boo16:51
*** agireud has joined #openstack-keystone16:52
ayoungor yours....16:52
morganfainbergayoung, afaik we (the one i work for) are not looking at that16:52
morganfainbergbut... i can't say with certainty that we wouldn't be interested in it16:52
* morganfainberg breaks fast16:52
morganfainbergbe back soonish16:52
*** jaosorior has quit IRC16:53
ayoungmorganfainberg, change of subject...  the thing we wer talking about last night, that policy is going to consume...context or toekn or whatever we call it16:53
ayoungI kindof need to get started on something along those lines myself16:53
ayounghere's what I am working on:16:53
dolphmi 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
ayounglets 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
ayoungand  doing a redirect to Keystone in order to do a redirect to the SAML IdP is not acceptable for whatever reason....16:54
dolphmlhcheng_: we default a lot of "null" strings to empty strings (like descriptions)16:54
ayoungto cut to the chase, Horizon needs to get a token for the user using nothing but the SAML assertion16:55
dolphmlhcheng_: i'd rather see data type consistency, so i'd favor an empty string name16:55
ayoungso 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 check16:55
lhcheng_dolphm: cool, that works. From a consumer perspective (like horizon), I rather see the "name" to always be there.16:55
ayoungbut...I don't want the service user to have to get a token first16:56
dolphmayoung: that sounds like it's defeating federation?16:56
ayoungthis is the slippery slope leading to token-less operations16:56
dolphmlhcheng_: ++16:56
ayoungdolphm, yes,  yes it is....sort of16:56
ayoungdolphm, it means that we are doing a deploiyment where we trust horizon as much as keystone16: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 IRC16:56
ayoungand I want to at least limit the damage that can be done with that assumption16:56
ayoungdolphm, 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 that16:58
ayoungIE.  Horizon would need to send the whole SAML assertion to Keystone.  Add to that the service user check16:58
ayoungand use that to get a token16:58
ayoungI'm going to go at it in increments, but the first thing should be getting policy workable in tokenless mode16:59
ayoungwhich means I need to be able to do a policy check from inside keystone with no token16:59
ayoungso 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 cleanup17:00
*** jsavak has joined #openstack-keystone17:03
*** diegows has quit IRC17:03
ayoungmorganfainberg, 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 IRC17:04
*** joesavak has joined #openstack-keystone17:05
*** patrickeast has quit IRC17:05
*** marg7175 has quit IRC17:07
*** jsavak has quit IRC17:07
*** jsavak has joined #openstack-keystone17:08
*** marg7175 has joined #openstack-keystone17:09
*** marg7175_ has joined #openstack-keystone17:10
*** joesavak has quit IRC17:10
*** NM has quit IRC17:10
*** NM has joined #openstack-keystone17:10
*** marg7175_ has quit IRC17:10
*** marg7175_ has joined #openstack-keystone17:11
*** marg7175_ has quit IRC17:11
*** marg7175 has quit IRC17:11
*** marg7175 has joined #openstack-keystone17:12
*** marcoemorais has joined #openstack-keystone17:16
samuelmsayoung, will work more on this tonight17:20
ayoungsamuelms, thank you17:20
ayoungsamuelms, can you put a common section at the top?17:21
ayoungsamuelms, 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 project17:21
ayoungI'd rename the nova one to something like17:22
*** packet has joined #openstack-keystone17:22
ayoungsamuelms, but good start17:23
samuelmsayoung, ok .. took these notes .. will apply soon17:24
samuelmsayoung, thanks17:24
ayoungsamuelms, thanks for taking this on17:24
samuelmsayoung, np :)17:24
ayoungsamuelms, can you look to see if there are any other duplicates?17:24
samuelmsayoung, sure17:24
samuelmsayoung, what do you mean by the  common section at the top?17:25
ayoungsamuelms, there are common rules,  like is_admin17:25
ayoungthe service specific sections stay as is, but the rules that they use get moved to the top17:26
samuelmsayoung, aah .. it s what we just talked about :)17:27
samuelmsayoung, once I have a new version I'll ping17:27
ayoungsounds good17:27
samuelmsayoung, will ping you (not a naked one)17:27
*** ajayaa has quit IRC17:29
*** marcoemorais has quit IRC17:33
*** marcoemorais has joined #openstack-keystone17:34
openstackgerritRodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc
*** marcoemorais has quit IRC17:34
ayoungnkinder, 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-keystone17:36
*** thedodd has joined #openstack-keystone17:36
*** links has quit IRC17:37
ayoungeither we do the mapping in Horizon,  or we send the assertion to Keystone to do the mapping17:37
nkinderayoung: the latter sounds better, though I need to think about it more17:39
ayoungnkinder, I like the former17:39
nkinderayoung: why duplicate mapping logic/code in Horizon?17:39
ayoungit allows offloading the work17:39
*** topol has quit IRC17:39
ayoungnot duplicate17:39
*** RichardRaseley has joined #openstack-keystone17:39
ayoungextract out the mapping code into KC17:40
nkinderayoung: so what does Horizon map to?17:40
ayoungits exactly the same set of steps I outlined for distributed signing....17:40
*** topol has joined #openstack-keystone17:40
*** ChanServ sets mode: +v topol17:40
nkinderayoung: Keep in mind that mapping currently is designed to map to keystone group(s)17:40
ayoungnkinder, horizon  fetches the mapping from keystone and caches it17:40
ayoungin theory,  Horizon could go as far as actually signing the token if we wanted17:41
nkinderI don't like that approach17:41
nkinderwe want to take power away from Horizon, not make it all-powerful17:41
nkinderIf it can sign tokens, it can mint whatever tokens it wants17:41
ayoungno matter what it is going to be limited17:41
ayoungyeah, but...17:41
ayoungwe can limite the tokens it can mint17:42
* lbragstad starts listening to "Take The Power Back" - RATM17:42
ayoungfor example, it could only sign for unscoped tokems17:42
nkinderlbragstad: makes me want to pick up my bass... :)17:43
ayoungthe other services would not accept them as valid.  Only Keystone17:43
lbragstadnkinder: :) makes me want to invest in a bass17:43
ayoungI've got a bass.17:45
ayoungIt would even work with AE tokens....if you shared the key between horizon and keystone17:46
nkinderayoung: 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 mapping17:46
nkinderayoung: in fact, there is a change to allow the mapped methods to be configurable that is out for review right now17:47
nkinderayoung: 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 up17:48
*** harlowja_away is now known as harlowja17:51
rodrigodsnkinder, need to address the comments, btw17:51
*** marekd is now known as marekd|away17:51
* rodrigods if marekd don't send a new patchset until I arrive at home, will update it17:51
*** zzzeek has joined #openstack-keystone17:53
rodrigodsmorganfainberg, not sure if the tests failing in the HM patch is a signal for a new rebase17:53
openstackgerritAndre Aranha proposed openstack/keystone-specs: Modify the policy file
*** vejdmn has quit IRC17:54
*** jsavak has quit IRC17:55
*** jsavak has joined #openstack-keystone17:55
*** vejdmn has joined #openstack-keystone17:56
morganfainbergrodrigods, there was a really awful testools bug that broke *everyone*17:56
marekd|awayrodrigods: you can upload17:57
*** aix has quit IRC17:57
*** thedodd has quit IRC17:59
*** marcoemorais has quit IRC18:01
*** marcoemorais has joined #openstack-keystone18:02
*** RichardRaseley has quit IRC18:05
marekd|awaytopol: thanks for the review, appreciate it!18:05
*** _cjones_ has quit IRC18:05
*** _cjones_ has joined #openstack-keystone18:06
topolmarekd, your welcome. looks very useful!18:06
rodrigodsmorganfainberg, quick question: do I need to create a new bp for the policy lib or should I reference the oslo one: ?18:06
*** patrickeast has joined #openstack-keystone18:06
*** patrickeast has left #openstack-keystone18:07
morganfainbergwe can probably retarget that one to keystone18:07
morganfainbergi don't think it matters18:07
rodrigodsmorganfainberg, hmm ok18:08
*** links has joined #openstack-keystone18:10
*** __TheDodd__ has joined #openstack-keystone18:20
*** jaosorior has joined #openstack-keystone18:25
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only)
*** marcoemorais has quit IRC18:32
*** marcoemorais has joined #openstack-keystone18:33
*** marcoemorais has quit IRC18:34
*** marcoemorais has joined #openstack-keystone18:34
*** __TheDodd__ has quit IRC18:34
*** marcoemorais has quit IRC18:34
*** marcoemorais has joined #openstack-keystone18:35
*** links has quit IRC18:35
*** raildo_away is now known as raildo18:36
*** radez_g0n3 is now known as radez18:44
openstackgerritAlexander Makarov proposed openstack/keystone: Manager driver parameters support
dolphmmorganfainberg: any idea why the gate is having issues?18:45
morganfainbergdolphm, not sure about today18:45
bknudsonwho's our QA liaison?18:45
morganfainbergi know what ... yesterday was?18:45
morganfainbergday before18:46
morganfainbergtesttools 1.something broke tons of things18:46
dolphmsomething new today18:46
dolphmnothing standing out on elastic-recheck18:46
bknudsonthe neutron errors?18:46
morganfainbergdolphm, not seeing anything on the radar in -infra or -qa atm18:46
morganfainbergbknudson, dstanek is18:47
*** packet has quit IRC18:49
*** dnalezyt has joined #openstack-keystone18:50
*** zzzeek has quit IRC18:50
*** sigmavirus24 has left #openstack-keystone18:51
lbragstaddolphm: I saw this get pushed ot e-r earlier:
dolphmlbragstad: oh, that sounds nasty18:53
dolphmanyone know dave walker's irc handle?18:53
uvirtbotLaunchpad bug 1365046 in openstack-ci "Job failed due to no devstack directory" [Undecided,Confirmed]18:53
lbragstadit's dead Jim18:53
dolphmdevstack failed due to significant lack of devstack18:54
*** toddnni has joined #openstack-keystone18:58
*** dims has quit IRC19:01
*** zzzeek has joined #openstack-keystone19:02
*** chrisshattuck has joined #openstack-keystone19:03
*** packet has joined #openstack-keystone19:03
*** marcoemorais has quit IRC19:04
*** jorge_munoz has joined #openstack-keystone19:04
*** marcoemorais has joined #openstack-keystone19:04
*** diegows has joined #openstack-keystone19:05
*** thedodd has joined #openstack-keystone19:05
*** jsavak has quit IRC19:17
*** jsavak has joined #openstack-keystone19:17
*** jorge_munoz has quit IRC19:18
dolphmayoung: just got asked to proof a paragraph from a blog post going up on about deploying keystone behind httpd :)19:19
*** jorge_munoz has joined #openstack-keystone19:19
openstackgerritMerged openstack/keystone: Enable cloud_admin to list projects in all domains
openstackgerritMarek Denis proposed openstack/keystone: Adds dynamic checking for mapped tokens
openstackgerritMerged openstack/keystone: Remove string from URL in list_revoke_events()
openstackgerritMerged openstack/keystone: Update references to auth_token middleware.
openstackgerritMerged openstack/keystone: Configuring Keystone edits
*** amakarov is now known as amakarov_away19:24
bknudsonmarekd|away: on you were wondering how old tests were passing -- maybe this answers it:
ayoungdolphm, excellent.  I was recently rereading the origianal post I followed for Nova on that topic:
ayoungdolphm, I heard from the eNovance team that they deploy all of the OpenStack services that way19:31
EmilienMayoung: it's WIP, but yes19:34
ayoungEmilienM, that is freaking AWESOME!19:34
* ayoung does a little happy dance19:35
ayoungEmilienM, wrt to V3...its really not Keystone the server that is the issue19:37
ayoungright 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 domain19:37
ayounghow we want it to work is this19:37
ayoungdo your install with service users going in to SQL19:38
ayoungnow create a domain for your LDAP based users19:38
EmilienMrichm: fyi ^19:38
ayoungswitch the default domain from the service domain to the LDAP backed one19:38
ayoungin order to make that work, auth_token needs to explicitly request things from the non-default domain.  Which means V3 APIs19:39
ayounglet me see where those patches are currently19:39
richmayoung: 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  I think that commit is right in the middle of the chain19:40
ayoungrichm, yes19:40
ayoungtrusts can span domains, no problem19:40
richmso you can have "cross domain trusts" - ok19:40
EmilienMayoung: 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
ayoungGood question...I don't think so19:40
ayoungthe older clients can't handle not having V219:41
ayoungmaybe we don't care for your deployments19:41
ayoungkeystone client itself can deal with V3 only endpoints19:41
richmI think the way it will work is that the services will need to use v319:41
richmbut existing clients that are not services will be able to use v2 or v319:41
ayoungrichm, so non-services should be the LDAP case above, which means you would want them in the default domain19:42
ayoungneed to proof-of-concept that19:42
richmthat's next on my plate19:42
EmilienMayoung: 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
ayoungEmilienM, 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 enabled19:44
EmilienMayoung: that's what I wanted to know. Thanks19:44
morganfainbergtopol, hEY!19:45
*** marcoemorais has quit IRC19:47
*** marcoemorais has joined #openstack-keystone19:47
*** marcoemorais has quit IRC19:47
*** marcoemorais has joined #openstack-keystone19:48
topolmorganfainberg, yes?19:57
morganfainbergtopol, i am *not* to blame for your light transformer... you clearly bought that before I became PTL19:57
*** thedodd has quit IRC19:58
morganfainbergok lunch time.19:58
topolmorganfainberg, too true. I really should blame jheck :-)19:58
stevemartopol, or that other guy19:59
afaranhaDo anyone knows if is there a way to register only one blueprint (spec also) that affects many projects?20:06
*** marcoemorais has quit IRC20:07
*** thedodd has joined #openstack-keystone20:09
*** david-lyle is now known as david-lyle_afk20:10
bknudsonafaranha: there's an openstack-specs repo for common specs now20:10
*** jorge_munoz has quit IRC20:16
*** dims has joined #openstack-keystone20:16
rodrigodsstevemar, found a potential bug, if this ( conditional is not true but is a fed token anyway, the get_token_data() method will fail because we do not have a field user20:17
rodrigodsstevemar, can you check/confirm this whenever you have a moment?20:17
*** jorge_munoz has joined #openstack-keystone20:18
Haneefayoung: Just FYI:  Few v2 call  are very difficult to do in v3.  Get Projects users is one such call20:18
stevemarrodrigods, yes, but when would a federation token not meet that conditional?20:18
stevemarHaneef, isn't that just GET /projects/project-id/users?20:19
ayoungHaneef, that is because that call is dumb20:19
ayoungHaneef, in the old world view, tenants owned users20:19
ayoungnowadays, not so muchj20:19
ayoungnow users have roles on a project20:19
ayoungand treating all those as equivalent is one of the reason that out policy files are so [a curse word]20:20
Haneefstevemar: 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 id20:20
rodrigodsstevemar, but shouldn't we return a meaningful error anyway?20:21
ayoungHaneef,  why do you want to do get-users-for-projects?20:21
stevemarHaneef, ah yep - you are both right20:21
stevemarrodrigods, yes, probably add it to:
HaneefSince v2 has that call, normally  they expect that in v3.  Once some one asked this question in since they have some GUI based on that call20:22
rodrigodsstevemar, ++ was writing the tests for _is_mapped... when fall into this case20:22
stevemarrodrigods, yeah, if the method seen isn't in 'federation methods' then it should raise a 401 with an error message20:23
rodrigodsstevemar, so we need to check if the method_name is valid at all20:26
*** marcoemorais has joined #openstack-keystone20:26
afaranhabknudson: Thanks!20:28
*** marcoemorais has quit IRC20:28
afaranhabknudson: 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-keystone20:28
bknudsonafaranha: I don't know how the blueprint works.20:29
*** vejdmn has quit IRC20:33
*** NM has quit IRC20:34
*** vejdmn has joined #openstack-keystone20:36
*** amcrn has joined #openstack-keystone20:40
*** victsou has joined #openstack-keystone20:43
*** victsou is now known as vsilva20:43
vsilvaping 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 victsou20:47
*** victsou has quit IRC20:47
*** vsilva has joined #openstack-keystone20:47
stevemarvsilva, no conclusion reached :(20:49
vsilvastevemar, shouldn't we try to reach one? :o20:50
stevemarvsilva, i don't think anyone has an answer yet :(20:51
stevemarvsilva, nkinder wrote some code to deploye stuff ->
stevemari was hoping to use that20:51
nkinderstevemar: I'm happy to help figure out how we can make use of some of my scripts20:52
stevemarnkinder, i think we need to bug some infra folks20:56
stevemarbut this is at the bottom of my priority list :(20:56
vsilvankinder, stevemar, would it make sense to talk about this on the next meeting? is there enough interest from the community?20:56
stevemarvsilva, sure, let morganfainberg or edit the wiki20:57
dstanekmorganfainberg: bknudson: issues?21:00
*** nitin_ has joined #openstack-keystone21:05
nitin_ayoung: hello,21:05
nitin_ayoung: Are you available here.21:06
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements
ayoungnitin_, available for what?21:08
stevemarmarekd|away, ahh no you're away, i wanted to bug you about token scoping21: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-keystone21:09
dstaneknitin_: you can join whatever channel you want21:09
nitin_dstanek: yes i know21:10
nitin_I'm asking so that the other discussions don't get distracted21:11
dstaneknitin_: doubt anyone would mind - not much going on anyway :-)21:11
nitin_dstanek: no problem.21:12
*** jasondotstar has joined #openstack-keystone21:12
ayoungnitin_, yeah, fire away21:12
ayoungnitin_, you assume I am better positioned to answer your question than the other folks in here....that is not a good assumption21:13
*** jasondotstar has quit IRC21:13
morganfainbergHaneef: fyi, federated users don't really resolve the same way.21:14
*** jasondotstar has joined #openstack-keystone21:14
morganfainbergThey 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
morganfainbergRather than doing the v2 mechanism over in v321:15
ekarlso- < what's wrong there morganfainberg ?21:22
morganfainbergA neutron error it looks like.21:24
morganfainbergNot sure, haven't seen that one yet.21:24
morganfainberg Or before.21:24
*** jorge_munoz has quit IRC21:25
morganfainbergayoung: you tend to have at least some answer ;). So it's not a bad assumption you have at least a starting place21:25
*** gyee has quit IRC21:26
morganfainbergnitin_: 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-keystone21:26
*** gyee has joined #openstack-keystone21:30
*** ChanServ sets mode: +v gyee21:30
*** gyee has quit IRC21:31
bknudsonekarlso-: morganfainberg dstanek -- everything seems to be failing with that neutron error21:33
*** zzzeek has quit IRC21:36
lbragstadvsilva: stevemar I think clarkb had a plan for moving tests from tempest to a project without regression21:41
lbragstadvsilva: stevemar mtreinish did some work with subunit and that had something to do with it. I don't really specifically though.21:42
dstanekbknudson: link?21:44
bknudsondstanek: here's an example
ayoungmorganfainberg, 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 dictionary21:48
morganfainbergayoung, why?21:48
ayoungmorganfainberg, cuz that is how the policy engine expects it21:48
ayoungand why should the canonical version not be what is passed to the policy engine?21:49
ayoungmorganfainberg, alternatively,  we make the policy engine accept it as a straight python object21:49
morganfainbergbecause often we don't pass the entire thing21:49
morganfainbergwe pass a constructed context21:49
morganfainbergthat is separate/different from the token21:49
ayoungmorganfainberg, yeah, I just chopped a very small portion of it out in that POC21:49
marekd|awaystevemar: what's up?21:50
ayoung+ source = {"domain_id": self.domain_id,21:50
ayoung+ "roles": self.role_names}21:50
ayoungthat would be "creds" if I named it consistantly21:50
dstanekbknudson: we didn't cause that did we?21:50
morganfainbergi'd rather extract the stuff we're looking to pass to policy not assume our token format matches.21:50
morganfainbergwhich it doesn't "really" match21:50
bknudsondstanek: we never cause tempest failures.21:50
stevemarmarekd|away, back to the question of using a token in django_o_auth21:50
marekd|awaybknudson: thanks, i will take a loot at it tomorrow :-)21:50
*** marekd|away is now known as marekd21:50
marekdstevemar: yep?21:50
bknudsondstanek: but tempest failures are always causing keystone failures21:51
stevemarmarekd, did you end up using the unscoped token as the token id?21:51
*** zzzeek has joined #openstack-keystone21:51
*** jimhoagland has left #openstack-keystone21:51
ayoungmorganfainberg, that seems to be the general pattern, but we have to do the same thing in a lot of places...the revocation events for example21:51
morganfainbergayoung, again this is why i think we're talking about 2 forms of token21:51
ayoungthose things often have a flattened view of the token data21:51
stevemarmarekd, becomes user_id and so on21:51
morganfainberg1: raw data [what is *inside* keystone], 2: what everything else uses21:51
morganfainbergwhich is formatted21:51
dstanekbknudson: that looks like lots of no good21:52
morganfainbergwhich was the idea behind that token_model in keystone21:52
ayoungand then there is the JSON format, so three...21:52
morganfainbergJSON is formatted -21:52
morganfainbergor serialized21:52
morganfainbergso sure, 3?21:52
morganfainbergwe can fix all but serialized21:52
stevemarmarekd, the login doesn't work, since it says the user is not authorized21:52
ayoungbut it does not match the policy or revocation view of the data, nor what we pass from auth_token middleware either21:52
morganfainbergthe view keystone is going to have is always going to be somewhat different.21:53
ayoungauth token fragments the hell out of it, doesn't it?  Separate headers21:53
ayoungwell, Keystone needs to be able to consume the standard view of tokens to feed into policy21:53
bknudsonif 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 IRC21:53
ayoungnot sure if jamielennox|away 's approach would work here.21:53
bknudsoni.e., if all we need for a token is user + scope + etc., then just store that in the token table21:54
morganfainbergayoung, 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 be21:54
bknudsonnot the whole JSON21:54
morganfainbergthat is what is passed to the provider21:54
*** jamielennox|away is now known as jamielennox21:54
ayoungbknudson, the AE format is optimized for size21:54
morganfainbergand the formatter can reverse that21:54
ayoungits not really appropriate for anything other than transport21:54
marekdstevemar: sorry, i am back.21:55
stevemarmarekd, i end up with a 'Unauthorized: Could not find user xyz' error message21:55
ayoungand...probably really not even appropriate for that, but, exigencies of the service21:55
morganfainbergayoung, 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 anyway21:56
morganfainbergayoung, so in short, no a dict is an awful choice21:56
marekdstevemar: 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
ayoungmorganfainberg, both policy and revocation events expect a flat view21:56
morganfainbergayoung, we have *very* little control what goes into it21:56
morganfainbergand we should have the data that is passed to the provider and back from the provider be very tightly controlled21:57
ayoungso we need one way to turn a canonical representation into a dictionary21:57
stevemarmarekd, yeah, we're able to get the token id back, but when we use it, it fails to log in21:57
jamielennoxayoung: my approach?21:57
ayoungbut 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 database21:57
morganfainbergor make the cannonical rep *act* like a dict when policy accesses it21:57
marekdstevemar: AFAIR you need both uuid (X-Auth-Token) and the JSON itself.21:57
ayoungjamielennox, representint the token inside keystone client21:57
morganfainbergno i am not above things like that.21:58
ayoungmorganfainberg, yeah...I tried that...policy didn't seem to like it, but I can try again21:58
jamielennoxwhat's wrong with it?21:58
ayoungmorganfainberg, isn't that what the auth plugins do?21:58
morganfainbergayoung, not exactly21:58
* ayoung looking through client code21:58
morganfainbergayoung, this is why i am starting work on this cleanup21:58
stevemarmarekd, huh? i mean when instantiating the client21:59
morganfainbergAccessInfo is a different beast21:59
ayoungmorganfainberg, yep21:59
morganfainbergaccessinfo is like what the current token model is21:59
marekdstevemar: take a look at federation file21:59
ayoungjamielennox, where should I be looking?21:59
morganfainbergit's smart enough to know what each of the token formats look like21:59
marekdstevemar: this is what is being returned to the browser,and instantianly redirected to the horizon.21:59
morganfainbergwhich is the wrong approach, the model shouldn't *care* waht the format is.21:59
jamielennoxayoung: there's a lot of back converstaion there, i'm not sure what you're looking for21:59
ayoungjamielennox, the KC version of the auth context22:00
ayoungthe thing that wraps the token data22:00
marekdlbragstad: what's your e-mail?22:00
morganfainbergayoung, why are we down the path of this becoming a "we need it right this very second and blocking other work"?22:00
lbragstadmarekd: lbragstad@gmail.com22:00
morganfainbergayoung, i'm confused why this landed at the top of the pile.22:00
morganfainbergnot that i'm complaining, don't get me wrong22:00
ayoungmorganfainberg, cuz I am trying to do something that enforces policy, and I don't want to reinvent...yet again...the marshalling of the token22:01
marekdstevemar: -> this is django_openstack_auth commit22:01
marekdstevemar: did you see that?22:01
marekdlbragstad: thanks.22:01
ayoungI'd rather have one place that we do it, and right now we have several22:01
lbragstadmarekd: np22:01
morganfainbergayoung, but we *already* marshal the token.22:01
marekdlbragstad: gonna bug you asynchronously22:01
stevemarmarekd, i did, but here you only supply the ID
stevemarin backend.py22:01
lbragstadmarekd: awesome!22:01
stevemarit's the whole ref22:01
morganfainbergmy question is more, can we use what we have and move towards the better solution ?22:02
ayoungmorganfainberg, my problem is that I actually have no token to marshall, just the raw queries against the database22:02
morganfainbergok lets step back22:02
morganfainbergwhat are you actually wokring on atm?22:03
ayoungIdeally, I would be reusing the same logic that we use to build a token to get the internal representation22:03
morganfainbergi feel like i'm missing context ;)22:03
morganfainbergso i can't comment definitively22:03
ayoungmorganfainberg, 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 first22:04
ayoungthis is the whole "tokenless operations" thing that we've discussed a few times in the past22:04
*** vejdmn has quit IRC22:04
ayoungso I want to be able to enforce policy on it by  getting the minimal amount of data out of the backends22:05
ayoungright now, that logic is buried inside the token provider, so I can't access it directly22:05
morganfainbergayoung, 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
ayounghere is my quick and dirty proof-of-concept:
morganfainbergayoung, 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 kilo22:06
ayoungmorganfainberg, enforce policy from keystone client depends on this22:07
morganfainbergthis sounds like an optimisation to enforcement, something we can support later but isn't needed right off the bat?22:07
stevemarmarekd, thanks, i think that was our issue22:08
ayoungand the Federation work, if I understand what needs to be done, is probably going to need something similar22:08
*** _cjones_ has quit IRC22:08
morganfainberggetting 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
ayoungmorganfainberg, and actually, revocation events duplicates this code.  So the cleanup of that also ties in22:09
morganfainbergwe could streamline it, i just don't want to be off in the weeds22:09
ayoungMy proof of concept just illustrates the issue.22:09
ayoungreally, the issue is how to enforce policy in a standarized way, as I would like to make revocation events use the same format22:09
marekdstevemar: wait, which one?22:10
ayoungand I think it can22:10
*** openstackgerrit has quit IRC22:10
*** openstackgerrit has joined #openstack-keystone22:10
morganfainbergayoung, ok so i think I see what is going on22:10
morganfainbergayoung, i *think* there is a lot of work that can be done in parallel.22:10
morganfainbergthis may be one of the things that needs to serialize behind some of the other work.22:11
stevemarmarekd, we were using just the id, not the ref22:12
morganfainbergand it's fine if we're prioritizing that work22:12
morganfainbergbut lets not jump around too much and partially implement bits here there and everywhere22:12
morganfainbergbecause we will have a brittle / worse system than we have now22:13
ayoungmorganfainberg, OK...just found the Client reprentation.
morganfainbergayoung, eyah AccessInfo is a bit weird and very token-specific but it has suited us for now22:15
*** jsavak has quit IRC22:15
morganfainbergit is something we should be better about long-term.22:15
ayoungmorganfainberg, since policy and revocation events both need to be checked outside of the Keystone server, I think it is at least the right starting place22:15
morganfainbergayoung, ok then lets prioritize the provider cleanup spec22:15
morganfainbergor at least part of that spec.22:16
morganfainbergayoung, so we can get the parts out of that that are what you need.22:16
ayoungmorganfainberg, well, since we are talking about splitting the canonical form from the form passed to the client APIs...maybe they should stay separate22:17
morganfainbergayoung, i actually am for a client representation and a server side22:17
ayoungMaybe I say that both policy and revocation should be able to consume a AccessInfo22:17
morganfainbergayoung, since keystone could *construct* a token at anytime, no other service can22:17
morganfainbergayoung, hmm.22:17
morganfainbergayoung, this sounds like a good approach22:18
ayoungmorganfainberg, right...but if the keystone server can produce an AccessInfo object...we probably should use that everywhere22:18
morganfainbergayoung, make the client representation the common form.22:18
ayoungyeah, that is what I was getting at22:18
morganfainbergayoung, AccessInfo is the wrong direction though atm22:18
morganfainbergaccessinfo knows all token formats22:18
morganfainbergwhich is what i'm trying to break away22:18
morganfainbergif that makes sense22:18
morganfainbergso "formatted" is really the serialization form.22:19
morganfainbergif it can be used outside of keystone, i'd be happy with that as well22:19
morganfainbergbut my first thought was get keystone to not care about the format of the data.22:19
morganfainberghence the python object22:19
ekarlso-jamielennox: you around mate ?22:19
ayoungmorganfainberg, I would see us wanting to work with what is in the V3 form,  with V2 being a one-off22:19
jamielennoxekarlso-: somewhta22:20
morganfainbergayoung, i think the V3 form is pretty awful.22:20
marekdstevemar: great22:20
jamielennoxugh, just can't type this morning22:20
marekdstevemar: yeah, the token is X-Subject-Token22:20
morganfainbergayoung, it is an *ok* serialized form.22:20
morganfainbergbut not good.22:20
jamielennoxAccessInfo is a horrible thing - but it works for certain cases22:21
morganfainbergjamielennox, ++22:21
stevemarmarekd, yeah yeah, it was when doing client.Client(token=...)22:21
jamielennoxit's not a serialized form, it's a weird messy hack22:21
stevemarwe passed in the id22:21
morganfainbergjamielennox, and that is the same thing the current token_model is.22:21
morganfainbergbut it was a stepping stone to make sure we accessed the data in a sane way22:21
jamielennoxcontext needs to be different, it needs to be a very flat dictionary22:21
morganfainbergso i don;t think the V3 form is "right"22:22
ayoungmorganfainberg, what if we at least made everything work through the AccessInfo as a starting point?22:22
jamielennoxyou could very easily build context from the AccessInfo because it handles the abstraction for you, but you shouldn't use AccessInfo itself22:22
morganfainbergwe can make the python object act like a flat dict22:22
marekdstevemar: cool, good luck then! :-)22:22
ayoungI thought that was what accessinfo does now?22:22
morganfainbergi want to get away from overloading dicts to do magic properties22:22
morganfainbergayoung, it is a overloaded dict with magic properties22:22
morganfainbergjamielennox, i think you and i are mostlyn on the same page22:22
jamielennoxayoung: the raw respresentation of AccessInfo is the v2 and v3 token formats with some edge cases22:23
jamielennoxit's the properties that handle the abstraction22:23
morganfainbergjamielennox, i'd rather have something that can "deserlize" the token into a useful object, that object *could* act like a context22:23
jamielennox(it adds some extra stuff as well)22:23
morganfainbergright now it's fairly magical *wavy hands* and needs to know the token formats.22:24
*** jasondotstar has quit IRC22:24
*** gordc has quit IRC22:24
morganfainbergthat way we can maintain our contracted wire format - and have sane representation internal to python, while controlling the data that goes inot the token22:24
morganfainbergbasically no "oops i stuck data into the dict and it just appeared"22:25
morganfainbergnow, we *could* make all clients use accessinfo to start.22:25
jamielennoxmorganfainberg: why would the serialized form be the context22:26
jamielennoxi think those should be seperate concepts22:26
morganfainbergjamielennox, i said it could be. i don't think it should be22:26
ekarlso-jamielennox: < care to look at that ?22:26
morganfainbergjamielennox, interesting.22:26
*** radez is now known as radez_g0n322:27
morganfainbergi mean, i'd be fine with a ".to_context" (equiv)22:27
morganfainbergor whatever way we get there22:27
ayoungmorganfainberg, does this call for its own spec?22:28
ayoungunify token-to-dict conversions or something?22:28
ayoungsomething that at least pulls together all the places we duplicate the logic?22:28
morganfainbergi think it might be a side-effect of the other work22:28
morganfainbergi could be it's own spec22:28
morganfainbergit might not need ot be22:28
morganfainbergif that makes sense22:28
ayoungI just want to make sure we identify the places that need to be updated to use the AccessInfoNextGeneration22:29
*** packet has quit IRC22:30
morganfainbergayoung, sure.22:31
morganfainbergit's a fair point22:31
morganfainberglike i said, it def. could stand on it's own as a spec22:31
*** _cjones_ has joined #openstack-keystone22:31
ayoungthe one thing that I don't think this affects is your token cleanup22:32
ayoungtoken provider  goes from database to JSON22:32
ayoungdoesn't need to be in this AccessInfo format22:32
*** stevemar has quit IRC22:32
morganfainbergayoung, not always.22:33
morganfainbergthats the point22:33
ayoungwhen does it need to be?22:33
jamielennoxekarlso-: looks fine, commented that you added some whitespace22:34
morganfainbergayoung, it gets used in context a lot22:34
*** saipandi has quit IRC22:34
morganfainbergayoung, interally.22:34
morganfainbergayoung, not just for enforcement but for understanding some assumed "what am i acting on"22:35
morganfainbergjson != python dict.22:35
morganfainbergso, the provider is used both interfacing externally (wire serialization) as well as internally.22:35
morganfainbergin the latter case it needs to be some representation we can work with.22:35
*** jimhoagland has joined #openstack-keystone22:39
ayoungmorganfainberg, ok.  let me start a spec.  We can all take stabs at it22:41
ayoungmorganfainberg, this spec....should it be a kilo spec or a keystone client spec?  Or both?22:42
ayoungthe unified format should live in the client22:42
*** jistr|mtg has quit IRC22:42
ayoungand needs to be usable by several points in the server22:42
ayoungIf I could make use of the AccessInfo now, it would provide a single place to clean up in the future22:43
ekarlso-jamielennox: removed that22:44
openstackgerritEndre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version
*** topol has quit IRC22:50
*** david-lyle_afk is now known as david-lyle22:50
*** thedodd has quit IRC22:51
*** gyee has joined #openstack-keystone22:55
*** ChanServ sets mode: +v gyee22:55
*** gyee has quit IRC22:55
*** hockeynut_ has joined #openstack-keystone22:56
*** hockeynut_ has quit IRC23:01
*** r-daneel has quit IRC23:03
*** nitin_ has quit IRC23:06
*** jasondotstar has joined #openstack-keystone23:08
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Docstring usability improvements
*** agireud has quit IRC23:15
openstackgerritayoung proposed openstack/keystone-specs: Access Info
ayoungjamielennox, morganfainberg ^^23:17
*** gyee has joined #openstack-keystone23:18
*** ChanServ sets mode: +v gyee23:18
openstackgerritEverett Toews proposed openstack/keystone-specs: Add requirement for APIImpact flag
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Replace magic numbers with named symbols
*** dnalezyt has quit IRC23:27
*** jaosorior has quit IRC23:33
*** jasondotstar has quit IRC23:33
*** agireud has joined #openstack-keystone23:34
*** jasondotstar has joined #openstack-keystone23:36
*** marg7175 has quit IRC23:49
*** richm has quit IRC23:50
jamielennoxayoung: 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 representation23:51
*** _cjones_ has quit IRC23:57

Generated by 2.14.0 by Marius Gedminas - find it at!