Thursday, 2014-06-26

*** jamielennox|away is now known as jamielennox00:01
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers.
morganfainbergdstanek, this looks like it's heat00:11
morganfainbergdstanek, doing a delete stack00:11
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf
*** dstanek is now known as dstanek_zzz00:24
*** stevemar has joined #openstack-keystone00:38
stevemarwchrisj, did you get an answer?00:44
wchrisjstevemar - yes, I did, thanks!00:44
stevemarwchrisj, lovely!00:44
wchrisjNot sure why, but you cant login with a username/pwd against the v3 API00:45
wchrisjKeystone requires the domain00:45
jamielennoxwchrisj: ... that doesn't seem right00:45
*** dstanek_zzz is now known as dstanek00:45
jamielennoxwchrisj: oh - yea usernames are only unique per domain, that is right00:45
wchrisjbut you CAN login with the User ID and Pwd - who remembers their user id?!?!? sheesh00:45
wchrisjahhh, but user Ids are unique globally...00:46
wchrisjmakes sense, actually00:46
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not log 14+ INFO lines on a broken pipe error (eventlet)
morganfainbergnkinder, ^00:50
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones
*** dstanek is now known as dstanek_zzz00:55
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not log 14+ INFO lines on a broken pipe error (eventlet)
*** rodrigods_ has quit IRC01:00
*** rodrigods_ has joined #openstack-keystone01:01
*** lbragstad has joined #openstack-keystone01:11
*** browne has quit IRC01:11
openstackgerritClayton O'Neill proposed a change to openstack/keystone: WIP: Add batch flush for MySQL
*** wchrisj has quit IRC01:12
*** gokrokve has quit IRC01:14
*** gokrokve has joined #openstack-keystone01:14
*** rodrigods_ has quit IRC01:17
*** geekinutah has joined #openstack-keystone01:18
*** gokrokve has quit IRC01:19
geekinutahquestion about the v3 domain concept01:19
geekinutahI've heard rumors on the wind that this is being removed?01:19
morganfainberggeekinutah, not really removed. we can't (it's part of the spec)01:31
morganfainberggeekinutah, it will be changed some to support the hiearchy logic01:31
*** richm has left #openstack-keystone01:32
*** marcoemorais has quit IRC01:35
*** mberlin1 has joined #openstack-keystone01:39
*** mberlin has quit IRC01:41
dvorakseems like this has to be an environment problem, but anyone else seen the error 'ImportError: cannot import name Full' when running tox?01:42
nkindermorganfainberg: I just added a small nit to the broken pipe patch01:43
morganfainbergnkinder, sure :)01:43
nkinderjust thinking errno.EPIPE would be nicer than 3201:43
morganfainbergnkinder, ah probably01:44
*** dstanek_zzz is now known as dstanek01:46
dstanekmorganfainberg: if its always heat, maybe there is something wrong in that client01:49
morganfainbergdstanek, dunno if it's always heat01:49
morganfainbergdstanek the case i was given was heat01:49
dstanekmorganfainberg: your patch is much smaller than i would have guessed01:53
ayoungmorganfainberg, so did we decide not to purse stripping the catalog out of the token?01:53
morganfainbergayoung, we should still do that01:54
morganfainbergayoung, but this appears to really be something else.01:54
*** ncoghlan has joined #openstack-keystone01:57
*** stevemar has quit IRC02:02
*** stevemar has joined #openstack-keystone02:02
dstanekmorganfainberg: i added a few comments to your review02:04
*** stevemar has quit IRC02:04
morganfainbergdstanek, ++02:04
morganfainbergnot sure if we want to log at all02:04
*** stevemar has joined #openstack-keystone02:05
*** packet has quit IRC02:05
*** otwieracz has quit IRC02:08
navidayoung: hi I am working on a bug fix regarding revoke events, how can you make revoke event with the idp-id, can you give some links to read about it.02:11
*** otwieracz has joined #openstack-keystone02:15
*** geekinutah has quit IRC02:18
*** gokrokve has joined #openstack-keystone02:20
*** nsquare has quit IRC02:21
ayoungnavid, it would probably be easier for me to fix myself than to explain.02:22
ayoungnavid, what do you mean by  " with the idp-id"02:23
morganfainbergdstanek, you were right can't super an old-style class >.<02:24
ayoungmorganfainberg, OK, so I guess the real question is if anything uses the body of the token02:24
ayoungwhen auth token unpacks, it sticks the data into env vars, so if there isn't even one for catalog, we're clear02:24
ayounglets see02:24
*** gokrokve has quit IRC02:24
ayoung    json encoded keystone service catalog (optional).02:25
ayoung    For compatibility reasons this catalog will always be in the V2 catalog02:25
ayoung    format even if it is a v3 token.02:25
ayounghmmm, that smells like we need the catalog02:25
nkinderayoung: we still need to pursue stripping the catalog from the token, but it's not the cause of the immediate problem morganfainberg is looking at02:25
ayoungnkinder, I don't think we can02:26
ayoungnkinder, I put it there in the first place.02:26
nkinderayoung: sure we can... :)02:26
ayoungnkinder, and it was because the call to validate a token  returned the catalog02:26
nkindermaybe not easily02:26
ayoungso in order to have the same behavior, we need to have some catalog available02:26
ayoungso if its not the one from the token, we have to fetch and cache02:26
nkinderayoung: it definitely has to be available, just not in the token itself02:26
ayoungnkinder, I suspect that, deep down, no one really uses it02:27
navidso when you delete idp the users associated with the idp's tokens should make a revoke event for that. I am looking to see if it can be done by adding idp_id as optional  attribute for revocation event like user_id02:27
navidayoung: so when you delete idp the users associated with the idp's tokens should make a revoke event for that. I am looking to see if it can be done by adding idp_id as optional  attribute for revocation event like user_id02:27
ayoungnavid, yes, you can do that02:28
ayoungnavid, start with auth_token middleware02:28
ayoungwith keystoneclient02:28
ayoungthe file has all of the logic02:28
* ayoung has to remove the corresponding code from keystone02:29
navidayoung: so how about the contrib/revoke/model.py02:29
ayoungin keystone?  That is dead code02:29
ayoungif you want to start by removing it, please do02:29
ayoungit moved to keystoneclient02:30
navidah thanks for letting me know02:30
ayoungnavid, I'm going to open a bug to remove that code and assign to you02:30
ayoungthat's the thanks you get for asking me questions02:31
navidhaha ok02:31
navidso no more questions02:31
ayoungnavid, what is your launchpad id02:32
ayoungjust navid?02:32
morganfainbergdstanek, i am not sure the impact of not re-raising, i'm going to guess minimal, but ... questions to be dug into.02:32
ayoungnavid,  there you go02:33
uvirtbotLaunchpad bug 1334480 in keystone "remove revocation  model" [Undecided,New]02:33
ayoungnavid, that is just to get you started02:33
ayoungnext step02:33
navidayoung, next step02:34
navidayoung, will do what is the next step?02:35
ayoungnavid, I figure out where I put the code02:35
*** praneshp has quit IRC02:37
ayoungnavid, I lied02:38
ayoungthis patch needs to land first02:38
ayoungI had fooled myself into thinking it was already in02:38
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Revocation event API
ayoungmorganfainberg, can I make a deal with you and jamielennox that I submit a new patch for the revocation events that just moves the code over from keystone server as is, and then do a second one on top of it, and you gusy only beat me up about the second patch?02:40
jamielennoxayoung: this is the one that i changed to AccessInfo?02:41
ayoungjamielennox, I haven't even looked02:41
ayoungI just got wrapped up in other tasks and left that one to wither on the vine02:41
ayoungjamielennox, I'm going to submit a new patch which is just the file added to contrib02:41
ayoungandthen I'll rebase the latest on top of it02:42
ayoungno tests, no nothing else02:42
jamielennoxayoung: i don't want to support that dict format in client, i just want accessinfo - how does that work for the server?02:42
ayoungjamielennox, we can clean that up, too.  I like what you are saying02:43
jamielennoxthat was my main problem with the initial patch - i agree it belongs in client and middleware should probably consume it02:43
ayoungand, I think that the AccessInfo structure, if I understand what you are talking about, is the right way to go02:43
ayoungI just think most people are put off by the size of the patch02:43
jamielennoxi was02:44
ayoungOK, so then I'll rebase yours on top of just the straight move of the code02:44
*** gokrokve has joined #openstack-keystone02:44
jamielennoxfine by me, i'm a passenger in morganfainberg's split02:47
*** ncoghlan is now known as ncoghlan_afk02:47
morganfainbergjamielennox huh? my split?02:49
*** ncoghlan_afk is now known as ncoghlan02:49
jamielennoxmorganfainberg: middleware from keysteonclient02:49
*** Camisa has joined #openstack-keystone02:49
*** Camisa has joined #openstack-keystone02:49
ayoungthis needs to be in client02:49
ayoungmiddleware can consume it, but any client should be able to validate a token02:50
morganfainbergsorry digging in eventlet :(02:50
morganfainberghave i mentioned i dislike eventlet02:50
openstackgerritwanghong proposed a change to openstack/python-keystoneclient: expose the revoke token for V3
jamielennoxmorganfainberg: i think everyone has02:51
ayoungjamielennox, out of curiousity what do you get if you run nslookup ipa.younglogic.net02:55
jamielennoxNon-authoritative answer:02:55
ayounginteresting, so yours is updated02:55
ayoungjamielennox, does the webui resolve in a web browser?02:56
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Revocation event API
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Direct move of the model code from keystone server
ayoungjamielennox, OK,  here is what the diff looks like now,cm02:57
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Direct move of the revoke model from keystone server
*** ayoung is now known as ayoung_ZZZzz03:01
morganfainbergdstanek, ok found what i really need to "fix" in eventlet.  this ... uh this is gonna be ugly03:04
*** mhu has quit IRC03:05
*** mhu has joined #openstack-keystone03:10
*** praneshp has joined #openstack-keystone03:17
dstanekmorganfainberg: :-) good luck sir03:25
dstanekmorganfainberg: i just found a py3 issue in
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not log 14+ INFO lines on a broken pipe error (eventlet)
morganfainbergdstanek, ^03:32
morganfainbergdstanek, i haven't run tests, but... i need to get dinner :(03:33
morganfainbergdstanek, figured i'd upload it03:33
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not log 14+ INFO lines on a broken pipe error (eventlet)
morganfainbergdstanek, the logging of the traceback is inside a function defined within a method within a nested try block03:34
morganfainbergdstanek, easier to just filter the log messages >.<03:34
dstanekmorganfainberg: yeah, i figured. otherwise it looked like you would have to do lots of copy/paste03:36
morganfainbergdstanek, yep. :(03:36
morganfainbergdstanek, dunno if i can make that any better thna that, short of squashing all tracebacks03:36
morganfainbergor massive copy/pasta03:36
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Moving delete_user and delete_group calls to IdentityManager
*** lbragstad has quit IRC03:38
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Use callback/notification framework for deletes
*** andreaf_ has joined #openstack-keystone03:44
*** gokrokve_ has joined #openstack-keystone03:44
*** gokrokve has quit IRC03:48
*** zhiyan_ is now known as zhiyan03:55
*** topol has joined #openstack-keystone04:05
*** dstanek is now known as dstanek_zzz04:07
*** cuddyt has joined #openstack-keystone04:07
*** gokrokve_ has quit IRC04:11
*** praneshp has quit IRC04:11
*** gokrokve has joined #openstack-keystone04:11
*** cuddyt has quit IRC04:12
*** gokrokve has quit IRC04:16
*** Camisa is now known as Chicago04:20
*** topol has quit IRC04:31
*** praneshp has joined #openstack-keystone04:32
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones
*** gokrokve has joined #openstack-keystone04:43
*** praneshp_ has joined #openstack-keystone04:47
*** praneshp has quit IRC04:50
*** praneshp_ is now known as praneshp04:50
*** dstanek_zzz is now known as dstanek04:58
*** ajc_ has joined #openstack-keystone04:59
*** gyee has quit IRC05:22
*** ukalifon1 has joined #openstack-keystone05:32
*** dims__ has quit IRC05:40
*** harlowja is now known as harlowja_away05:49
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes a Python3 syntax error
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds several more test modules that pass on Py3
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes test_wsgi for Python3
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes for Python3
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fix the order of assertEqual arguments(pemutils, v3_catalog, etc)
*** jimbaker has quit IRC06:11
*** zhiyan is now known as zhiyan_06:13
*** zhiyan_ is now known as zhiyan06:14
*** dstanek is now known as dstanek_zzz06:18
*** rwsu has quit IRC06:26
*** stevemar has quit IRC06:36
*** dims__ has joined #openstack-keystone06:36
*** dims__ has quit IRC06:41
*** jaosorior has joined #openstack-keystone06:42
openstackgerrithenry-nash proposed a change to openstack/keystone: Add identity mapping capability
*** navid_ has joined #openstack-keystone06:46
*** navid_ has quit IRC06:47
*** chandan_kumar has joined #openstack-keystone06:47
openstackgerrithenry-nash proposed a change to openstack/keystone: Add identity mapping capability
*** BAKfr has joined #openstack-keystone07:02
*** openstackgerrit has quit IRC07:07
*** andreaf_ has quit IRC07:18
*** mrda is now known as manslaughter07:20
*** manslaughter is now known as mrda07:22
*** oomichi has quit IRC07:23
*** rushiagr has left #openstack-keystone07:28
*** openstackgerrit has joined #openstack-keystone07:29
*** dims__ has joined #openstack-keystone07:30
*** dims__ has quit IRC07:35
*** praneshp has quit IRC07:38
*** tomoiaga has joined #openstack-keystone07:42
*** nsquare has joined #openstack-keystone07:55
*** nsquare_ has joined #openstack-keystone08:01
*** nsquare has quit IRC08:04
*** mrda is now known as mrda-away08:08
*** dims__ has joined #openstack-keystone08:31
*** dims__ has quit IRC08:36
*** andreaf_ has joined #openstack-keystone08:37
*** jamielennox is now known as jamielennox|away08:39
*** xianghui^ has quit IRC09:19
*** dims__ has joined #openstack-keystone09:32
*** xianghui^ has joined #openstack-keystone09:32
*** ncoghlan has quit IRC09:36
baffleHm, is there any way to fix issues with authtoken getting bigger than 8K due to catalog size yet? As a workaround I've had to remove some endpoints from the catalog. :-/09:36
*** dims__ has quit IRC09:37
baffleAnd I'm having issues with haproxy returning a 400-error if the length of one HTTP header is > 8K. I have allocated lots of memory for buffers, but the 8K pr. header seems to be stuck.. So all requests with huge authtokens just get dropped..09:37
baffleI'd really like to get Ceilometer API up and running. :)09:37
*** afazekas is now known as __afazekas09:58
*** dims__ has joined #openstack-keystone10:40
*** chandan_kumar is now known as chkumar24610:51
*** chkumar246 is now known as chandan_kumar10:53
*** chandan_kumar has quit IRC10:54
*** chandan_kumar has joined #openstack-keystone10:54
*** henrynash has joined #openstack-keystone10:58
*** nsquare_ has quit IRC11:14
*** nsquare has joined #openstack-keystone11:17
*** nsquare has quit IRC11:22
*** joesavak has quit IRC11:31
*** lbragstad has joined #openstack-keystone11:52
marekdmorganfainberg: I left some comments on websso bp: Let me know when you are available, I'd like to discuss some details.11:54
marekdmorganfainberg: dstanek_zzz ayoung_ZZZzz: Appreciate your eyes on k2k bp, added some proposals to general user workflow and potential impact on the whole solution. Around line 191 in
*** lbragstad has quit IRC11:56
marekddolphm: you too ^^11:56
*** afazekas_ has joined #openstack-keystone11:59
*** diegows has joined #openstack-keystone12:04
*** erecio has joined #openstack-keystone12:13
*** openstackgerrit has joined #openstack-keystone12:27
*** stevemar has joined #openstack-keystone12:31
*** radez_g0n3 is now known as radez12:33
*** dstanek_zzz is now known as dstanek12:39
*** gordc has joined #openstack-keystone12:47
*** gokrokve_ has joined #openstack-keystone12:50
*** gokrokve_ has quit IRC12:50
*** gokrokve_ has joined #openstack-keystone12:51
*** gokrokv__ has joined #openstack-keystone12:52
*** rodrigods_ has joined #openstack-keystone12:52
*** gokrokve has quit IRC12:53
*** gokrokve_ has quit IRC12:55
*** ajc_ has quit IRC13:00
*** lbragstad has joined #openstack-keystone13:02
*** dstanek is now known as dstanek_zzz13:02
*** dstanek_zzz is now known as dstanek13:04
*** stevemar has quit IRC13:08
*** nkinder has quit IRC13:08
*** miqui has joined #openstack-keystone13:12
*** _elmiko is now known as elmiko13:13
*** dstanek is now known as dstanek_zzz13:14
openstackgerritJuan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail.
*** kwss has joined #openstack-keystone13:24
*** richm has joined #openstack-keystone13:26
*** dstanek_zzz is now known as dstanek13:34
jaosoriordolphm, ping13:44
*** hrybacki has joined #openstack-keystone13:49
marekdmhu: hey13:50
marekdmhu: I am curious why would you rather see HTTP POST call initiated by Keystone rather than a JS code.13:52
marekdmhu:  I am not biased to JS, I just want to gather others opinions :-)13:52
*** tomoiaga has quit IRC13:59
*** nkinder has joined #openstack-keystone14:00
henrynashmorganfainberg, dstanek, dolphm, ayoung: 2nd or 3 patches now up on the path to cross-backend uuids…this one adds the mapping fucntionality without actually wiring it in:
*** stevemar has joined #openstack-keystone14:02
stevemarmarekd, thanks for the reviews :)14:02
dstanekhenrynash: great, i'll start taking a look14:02
dstanekseems to have been a flurry of k2k activity14:03
marekdstevemar: happy to help.14:03
marekdstevemar: i wanted to clean it up (tabs) but didn't know if you are not working on sth locally.14:04
marekdstevemar: i am really curious what you and others thing about my poem regarding user workflow and all the impact i had written in the morning :-)14:04
stevemarmarekd, i havent taken a deep look at it all yet, but saw a ton of comments14:05
marekdstevemar: i'd sleep much better if we have agreement on that :-)14:05
stevemarmarekd, ;)14:05
stevemarmarekd, i hope i can upload a new version before lunch14:05
marekdstevemar: i should be online today so maybe you, dstanek and morganfainberg can discuss it together?14:05
marekdstevemar: and myself :P14:06
marekdbetween 2-3pm your time14:06
stevemarmarekd, that would be awesome14:06
marekdbefore it gets *really* late here.14:06
marekddstanek: what do you think?14:07
dstaneki think 2 - 3 EST works for me :-) what will we be discussing?14:07
marekddstanek: k2k14:07
dstanekah, sure14:07
marekddstanek: i made some proposals to user workflow14:07
stevemari do like the fact that it's become k2k now14:07
marekdstevemar: federation thing?14:07
stevemarmarekd, yep14:08
stevemarmarekd, alright, 47 comments to go through! lets do this!14:08
marekdstevemar: good luck with that :-)14:08
* stevemar closes all other tabs in chrome to reduce distraction levels14:08
dstanekhaha, i wish it were more like federation; the remote Keystone treating the local Keystone like any old IdP14:09
marekddstanek: ++10014:09
marekddstanek: i also want to keep the trust somehow limited...14:09
marekddstanek: your use case and one provider being compromised is a simple, yet ingenius example. I did say that in one of my comments in the bp.14:10
dstanekmarekd: thanks. the more i think about it the more i see bad things.14:10
marekddstanek: well, i couldnt see a good reason why this impersonation was really bad.14:11
marekdnow i do.14:11
marekdwell ok...i am fine with impersonation but *limited* impersonation.14:11
dstanekit's interesting because if the local keystone creates the token i think it is doing a part of the authz and that scares me14:12
marekddstanek: anyway, please take a look at my comments in k2k bp.14:12
dstanekmarekd: will do14:12
marekddstanek: i tried to bring together all my thoughts...14:12
marekdEST is canadian tz?14:12
*** hrybacki has quit IRC14:16
*** hrybacki has joined #openstack-keystone14:17
marekddstanek: what's your local time now? ~10:1214:18
mhumarekd: first, I am not very fond of JS :) second, less dispersion in code to maintain14:20
mhumarekd, but it's just an opinion, I am open to discussion if you think JS would work better14:20
dstanekmarekd: yes, 10:20 - i think 2PM EST is 6PM UTC14:21
marekddstanek: haha, it's weird that you guys live in the same country and have specify timezones when you set up the mettings (not talking about stevemar who is canadian) :-)14:22
dstanekmarekd: i think stevemar is in EST too and for morganfainberg it'll be 11AM14:22
marekddstanek: yes, EST is 6h behind me, and UTC 2h behind me.14:22
stevemarmarekd, canada has like 6 tz's it's crazy14:23
*** bknudson has quit IRC14:27
*** mhu has quit IRC14:27
*** david-lyle has joined #openstack-keystone14:27
*** mhu has joined #openstack-keystone14:28
*** rodrigods_ has quit IRC14:28
*** ayoung_ZZZzz is now known as ayoung14:34
ayoungdolphm, in addition to deprecating the LDAP options for Tenant, perhaps it is time to deprecate the hack that says "use the LDAP assignment driver if the LDAP identity driver is specified and there is no assignment driver specified."14:35
openstackgerritMarco Fargetta proposed a change to openstack/keystone-specs: Web Authentication for SAML federated Keystone
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones
openstackgerritMarek Denis proposed a change to openstack/keystone-specs: Web Authentication for SAML federated Keystone
marekdstevemar: thanks for adding me as Co-Author! :-)14:50
*** ukalifon3 has joined #openstack-keystone14:50
*** ukalifon1 has quit IRC14:51
stevemarmarekd, thats just incentive for you to implement more code  :P14:53
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy
marekdstevemar: does it work backwards with code reviews? :P I have some patches stalled :P14:54
stevemarhehe, I think I know which ones :)14:54
*** dstanek is now known as dstanek_zzz14:55
*** cuddyt has joined #openstack-keystone14:58
*** raildo has joined #openstack-keystone15:01
marekdstevemar: btw did you test my client with TFIM?15:03
stevemarmarekd, no, i wanted to get the ball rolling on k2k15:04
marekdstevemar: ok15:04
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones
*** daneyon has joined #openstack-keystone15:06
morganfainbergraildo, woo saw the new spec, will read it over today.15:06
morganfainbergraildo :)15:06
raildomorganfainberg: great =]15:07
*** bobt has joined #openstack-keystone15:09
*** gokrokv__ has quit IRC15:11
*** gokrokve has joined #openstack-keystone15:12
*** erecio has quit IRC15:14
*** andreaf_ has quit IRC15:15
openstackgerritJuan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail
*** dims__ has quit IRC15:21
*** dims__ has joined #openstack-keystone15:22
*** Chicago has quit IRC15:22
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Add optional parameters to EndpointManger create()
*** rodrigods_ has joined #openstack-keystone15:26
*** dstanek_zzz is now known as dstanek15:28
*** Chicago has joined #openstack-keystone15:34
*** Chicago has joined #openstack-keystone15:34
*** ukalifon3 has quit IRC15:35
*** rodrigods_ has quit IRC15:37
*** jgriffith is now known as jfiffith15:38
*** jfiffith is now known as jgriffith15:39
*** erecio has joined #openstack-keystone15:42
*** morganfainberg changes topic to "Please Review and/or Update Proposed Specs"15:43
*** ChanServ changes topic to "Please Review and/or Update Proposed Specs | Hackathon July 9-11:"15:45
*** geekinutah has joined #openstack-keystone15:47
*** henrynash has quit IRC15:49
*** geekinutah has left #openstack-keystone15:50
hrybackiayoung: We've got the glance meeting at 16:00 but I'm supposed to be at a RH volunteer event until 17:00. I'm gonna try and dip out at 15:45 though.15:51
*** dstanek is now known as dstanek_zzz15:52
morganfainbergayoung, dolphm, stevemar, when we have an exception (conflict) raised from SQLAlchemy ( backends) do we want to log the exception at error level?15:55
morganfainbergayoung, dolphm, stevemar, or is the exception info? debug? warning?15:55
morganfainbergrespinning my take on the leaking of sql queries via HTTP 40915:56
*** rwsu has joined #openstack-keystone15:59
*** bvandenh has joined #openstack-keystone15:59
*** chandan_kumar has quit IRC16:02
*** jaosorior has quit IRC16:02
*** arun_kant has joined #openstack-keystone16:03
*** bvandenh has quit IRC16:04
*** __afazekas is now known as afazekas16:04
*** gordc has quit IRC16:05
*** bknudson has joined #openstack-keystone16:05
*** gyee has joined #openstack-keystone16:05
arun_kantall..finally jenkins build is happy, now looking for review comments on
*** henrynash has joined #openstack-keystone16:08
dolphmmorganfainberg: some exceptions are expected - are you referring to *all* exceptions?16:09
morganfainbergdolphm, the @handle conflict ones16:09
dolphmmorganfainberg: can i ask why you're asking?16:09
morganfainbergdolphm, in theory, we shouldn't ever get to the point where we raise a conflict if we did our jobs right?16:09
morganfainbergdolphm, respln on this patch
morganfainbergjust removing the leaking SQL from the exceptions16:10
morganfainberginstead of re-working the entire exception scheme (much simpler)16:10
morganfainbergI can make it debug if it really doesn't matter to an operator16:10
* morganfainberg might just be low on coffee this morning16:11
*** gyee has quit IRC16:11
morganfainbergdolphm, as i type this out. it sounds more and more 'debug' log16:11
*** bobt has quit IRC16:11
dolphmmorganfainberg: if you're going to log, i think debug is fine. i don't see too much point to a higher level log unless someone is asking for it with good reason?16:12
morganfainberglike i said, as i was typing it out, i came to the same conclusion.16:13
* morganfainberg needs to get coffee and breakfast16:13
*** hrybacki has quit IRC16:15
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not leak SQL queries in HTTP 409 (conflict)
morganfainberg^ much simpler change.16:17
morganfainbergsolves the same issue.16:17
dolphmmorganfainberg: looking...16:17
dolphmmorganfainberg: typo in L40516:18
*** kwss has quit IRC16:18
dolphmmorganfainberg: explain "Internal Error" on DBError's?16:19
morganfainbergIt's a integrity error, e.g. foreign key issue?16:19
*** gyee has joined #openstack-keystone16:20
morganfainbergor uh, a number of cases where the DB isn't duplicating an entry, but can't store16:20
*** erecio has quit IRC16:20
morganfainbergmaybe that one needs to be a warning?16:20
*** marekd is now known as marekd|bbl16:22
*** diegows has quit IRC16:22
dolphmmorganfainberg: is it ever the user's fault?16:22
dolphmmorganfainberg: if so "internal error" seems like a misleading message16:23
dolphmmorganfainberg: if not, then ++16:23
morganfainberghm. i think the user _could_ be doing something bad here.16:23
morganfainbergbut. it could probably also be an UnexpectedError (500 ISE)16:23
morganfainbergISE might actually be better.16:24
*** gordc has joined #openstack-keystone16:24
dolphmmorganfainberg: if it's the user's fault, then it shouldn't be 5xx16:24
morganfainbergi don't see how this is going to be the user's fault16:24
dolphmmorganfainberg: if it's the user's fault, then 4xx, but "internal error" isn't super helpful for the user to resolve it16:25
morganfainbergthis is a case where maybe they slipped through and tried to create a project when a domain was deleted (Race)16:25
morganfainbergout check of if domain exists passed, and the SQL driver on the backend goes to write and gets a FK error16:25
morganfainbergbecause the domain is gone16:25
dolphmmorganfainberg: that sounds like a 404 domain not found16:26
morganfainbergexcept we're passed the part where we know what foriegn key could be missing16:26
morganfainbergthis would be if the SQL failed because of a FK constraint failed16:26
dolphmmorganfainberg: alright, 500 then16:27
morganfainberg*nod* fixing now16:27
*** erecio has joined #openstack-keystone16:27
morganfainbergshould this be a higher than debug log for the operator? or still debug only (leaning towards debug.16:28
*** BAKfr has quit IRC16:30
*** zhiyan is now known as zhiyan_16:32
dolphmmorganfainberg: i vote debug16:33
morganfainbergdebug it is16:33
openstackgerritA change was merged to openstack/keystone: Imported Translations from Transifex
*** jimbaker has joined #openstack-keystone16:37
*** joesavak has joined #openstack-keystone16:37
*** gokrokve has quit IRC16:38
*** gokrokve has joined #openstack-keystone16:38
*** diegows has joined #openstack-keystone16:39
dolphmmorganfainberg: should i just pile on another +2 on or +2/+A? (why isn't there a +A already?)16:40
morganfainbergdolphm, probably because people are hesitent to +A a spec16:41
dolphmmorganfainberg: fair enough16:41
dolphmmorganfainberg: going to have a patch on in the next couple minutes? i'm about to run to lunch16:42
morganfainbergdolphm, yes16:42
morganfainbergjust making sure it passed p27/pep816:42
morganfainbergalmost done16:42
*** gokrokve has quit IRC16:42
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not leak SQL queries in HTTP 409 (conflict)
*** hrybacki has joined #openstack-keystone16:44
dolphmmorganfainberg: +2!16:44
*** Chicago has quit IRC16:45
openstackgerritA change was merged to openstack/keystone-specs: Service Token Composite Authorization Specification
*** jaosorior has joined #openstack-keystone16:48
*** dstanek_zzz is now known as dstanek16:57
*** jsavak has joined #openstack-keystone17:00
*** packet has joined #openstack-keystone17:01
*** david-lyle has quit IRC17:01
*** david-lyle has joined #openstack-keystone17:02
*** rodrigods_ has joined #openstack-keystone17:02
*** joesavak has quit IRC17:03
*** david-lyle has quit IRC17:03
*** david-lyle has joined #openstack-keystone17:04
*** praneshp has joined #openstack-keystone17:04
*** harlowja_away is now known as harlowja17:10
openstackgerritAmandeep Chhabra proposed a change to openstack/keystone: Fixes Bug1334739
*** dstanek is now known as dstanek_zzz17:25
*** jsavak has quit IRC17:34
stevemardstanek_zzz, are we meeting to talk about federation at 2 or 3 est... ? I might be a tad late :(17:37
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers.
*** chandan_kumar has joined #openstack-keystone17:41
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers.
*** nsquare has joined #openstack-keystone17:42
*** gordc has quit IRC17:42
*** marekd|bbl is now known as marekd17:46
marekdstevemar: dstanek_zzz i am back17:46
marekdmaybe morganfainberg wants to weigh in?17:46
marekdmorganfainberg: k2k bp17:46
*** stevemar has quit IRC17:47
morganfainbergmarekd, new patch since last night?17:47
* morganfainberg commented a bunch on it last night.17:47
marekdmorganfainberg: new patch, some comments.17:47
morganfainbergmarekd, i can't at the moment. need to get food and coffee17:49
morganfainbergbut i can look at ti a bit later17:49
marekdmorganfainberg: appreciate!17:49
marekdmorganfainberg: bon app!17:49
morganfainbergmarekd, thanks!17:50
*** rodrigods_ has quit IRC17:55
*** zzzeek has joined #openstack-keystone17:57
zzzeekmorganfainberg: hi!17:58
morganfainbergzzzeek, hey!17:58
morganfainbergzzzeek, caught me right before i was headed out.17:58
*** vishy has joined #openstack-keystone17:58
zzzeekah ok17:58
morganfainbergzzzeek, i guess this means you're looking at the lock_mode thing?17:58
zzzeekwas just looking at yes17:58
vishyso is it a known issue that the region table doesn’t properly set utf8?17:58
zzzeekjust curious what does the lock actually block on ?17:58
morganfainbergzzzeek, ooh uh... good question :P it might not block17:59
morganfainbergvishy, it isn't?17:59
morganfainbergvishy, *grumble* we should fix that17:59
zzzeekmorganfainberg: OK, i thought that update, if that row is locked somehow, woudl be the only way for it to block, but i dont really think it does that, i never know for sure unless i can try it on the specific DB + isolation level...18:00
morganfainbergzzzeek, see this is why i ask super smart people to look at these things.18:00
zzzeekmorganfainberg: it might block but then again that’s waht SELECT..FOR UPDATE is for...18:00
vishymorganfainberg: so if you don’t have utf8 set in your default db config then the icehouse db_sync bombs out18:00
morganfainbergzzzeek and we can't select for update due to galera + mysql doing bad things18:00
zzzeekmorganfainberg: yes i know that part18:00
*** david-lyle has quit IRC18:00
zzzeekmorganfainberg: if galera doesnt like to lock things then i dont know that the DB can be reliued upon to lock18:00
morganfainbergvishy, yeah lets fix that ASAP, toss up a bug for me and i'll get something rolled up today.18:01
zzzeekmorganfainberg: does this code run in a single process at least?  or is it distributed ?18:01
morganfainbergzzzeek, if it runs under apache it could be distributed18:01
*** david-lyle has joined #openstack-keystone18:01
zzzeekmorganfainberg: hooray!  then locking is a total PITA :)18:01
morganfainbergzzzeek or even run under multiple physical servers running keystone18:01
morganfainbergzzzeek yeah. it's why we did the with_lockmode thing18:01
zzzeekmorganfainberg: i think we should figure out, if we dont know alredy, what locking primitives galera supports18:01
zzzeekmorganfainberg: something silly that will just work18:02
morganfainbergzzzeek, i think the answer was "it doesn't do locking very well anywhere"18:02
morganfainbergzzzeek it might do table locks18:02
zzzeekmorganfainberg: so this code could in theory just block in that method18:02
zzzeekmorganfainberg: e.g. just loop aroudn w/ a timeout and all that18:03
morganfainbergzzzeek, might cause issues with eventlet18:03
zzzeekmorganfainberg: ah!18:03
zzzeekmorganfainberg: why yes it woudl do that18:03
morganfainbergzzzeek, maybe the better answer is add a row to a "trust consumption" table18:03
zzzeekmorganfainberg: unless you can yield out to eventlet ?18:03
uvirtbotLaunchpad bug 1334779 in keystone "db_sync breaks in non-utf8 databases on region table" [Undecided,New]18:04
morganfainbergzzzeek, well a sleep should yeild. but i am always leery18:04
vishyI’m thinking it might be best to just fix that one inline18:04
vishyand backport it18:04
morganfainbergvishy, probably18:04
*** david-lyle has quit IRC18:04
vishysince anyone running into it will not be able to get past that migration anyway18:04
*** david-ly_ has joined #openstack-keystone18:04
vishyso i don’t think we need a separate migration18:04
morganfainbergvishy, i'll get something proposed today/this afternoon18:04
zzzeekmorganfainberg: right…..OK im going to get lunch as you were just going out….i want to see if we can make consume_use() look a little simpler also…18:05
vishymorganfainberg: awesome18:05
vishymark it for stable/icehouse also18:05
morganfainbergvishy, we actually probably will need a migration, but nbd18:05
morganfainbergvishy, please (if you can) if not just tag it as potential18:05
vishymorganfainberg: as i said i don’t think so18:05
morganfainbergerm icehouse-backport-potential tag18:05
morganfainbergvishy, i'll look at it, will be easy in either case.18:06
vishybecause the migration would assume that someone could get passed that migration without being in utf818:06
vishyand they can't18:06
morganfainbergvishy, no i mean we fix it in the migration in icehouse18:06
vishyso the additional migration will be a no-op in every case18:06
vishyah yes but not add a new migration18:06
morganfainbergand we fix it in a later migration in case someone missed it18:06
vishymorganfainberg: again you can’t miss it18:06
vishythe migration will fail if you are not utf818:07
morganfainbergvishy, ah, sorry carrying on two conversations and mssing coffee :P18:07
morganfainbergvishy, ++ see it now.18:07
vishyso you either have utf8 in which case the new migration woud do nothing18:07
vishyor you don’t and you are stuck pre region migration18:07
morganfainbergyeah, totally easy fix.18:07
vishymorganfainberg: ah crap18:08
vishyi may be wrong18:08
vishyit depends on when the sanity check runs18:08
morganfainbergvishy, i'll poke at it18:08
morganfainbergif we need to fix it in 2 placed, we'll fix it in two places18:08
vishyactually the sanity check must run after the migration18:08
vishyso we do need another migration18:08
morganfainbergan extra migration wont be awful in the worst case18:08
vishyit needs to be fixed in the migration directly after the migration table though18:09
vishy* region table18:09
vishythis could be a little tricky18:09
vishywe may just have to have people manually fix it if they happen to have hit the bug once18:09
vishybecause they will be on the version that adds the table, so the new patched version won’t re-run18:10
*** bobt has joined #openstack-keystone18:10
morganfainbergvishy, i could also muck with the sanity check18:10
vishyyeah but that is in common18:10
vishyanyway let me know what you figure out18:10
morganfainbergvishy, sure thing. i'll work on it post lunch18:10
*** dstanek_zzz is now known as dstanek18:14
dstanekmarekd: sorry, was distracted18:15
marekddstanek: np.18:15
*** openstackgerrit has quit IRC18:20
dstanekmarekd: it's looking much more complete18:21
*** nkinder has quit IRC18:22
*** nkinder has joined #openstack-keystone18:25
marekddstanek: what exactly?18:28
marekddstanek: user workflow?18:29
*** marcoemorais has joined #openstack-keystone18:30
dstanekmarekd: yes, use cases feel more polished too18:31
dstanekmarekd: what is meant by burst in use case 4?18:32
marekddstanek: did you also have a chance to read this (pasted as one big comment)?18:32
marekddstanek: i don't know.18:33
*** erecio has quit IRC18:34
marekddstanek: i don't see 'burst' in use-case 4 description..18:35
*** praneshp_ has joined #openstack-keystone18:37
dstanekmarekd: jobs from A can be burst to C via B18:37
marekdah, this.18:38
marekddstanek: probably something: A federates with B and B federates with C => A can use C's resources.18:38
marekdi don't think we are going tackle this...i wouldn't18:39
marekdwe already have enough problems.18:39
*** praneshp has quit IRC18:39
*** praneshp_ is now known as praneshp18:39
marekdat least not in this release.18:39
*** xianghui^ has quit IRC18:39
marekdwhich ver. pf patch are you reading now?18:39
dolphmdstanek: morganfainberg's fix to remove excess logs for -infra's sake
*** openstackgerrit has joined #openstack-keystone18:40
*** stevemar has joined #openstack-keystone18:42
stevemarmarekd, o/18:42
*** openstackstatus has joined #openstack-keystone18:42
*** ChanServ sets mode: +v openstackstatus18:42
marekdstevemar: \o/18:42
dstanekdolphm: ha, i just reviewed that18:42
stevemarmarekd, did we start yet?18:42
marekdstevemar: i don't think so :-)18:43
dstanekoh, you gave it a +2 too18:43
dolphmdstanek: +A'd :)18:43
dstanekstevemar: not really - i asked a few questions18:43
* marekd wishes one day his patches were +2/+A'd out of the box (just like morganfainberg's) :-)18:44
stevemarmarekd, something we all aspire towards18:44
dstanekmarekd: i'll looking at 1118:44
marekddstanek: OK18:45
dstanekmarekd: just get -infra to complain about whatever it is you are fixing :-)18:45
*** nsquare has quit IRC18:46
*** mberlin1 has quit IRC18:46
*** jamielennox|away has quit IRC18:46
*** ekarlso has quit IRC18:46
*** praneshp has quit IRC18:46
*** david-ly_ has quit IRC18:46
*** chandan_kumar has quit IRC18:46
*** diegows has quit IRC18:46
*** bknudson has quit IRC18:46
*** zzzeek has quit IRC18:46
*** richm has quit IRC18:46
*** miqui has quit IRC18:46
*** afazekas_ has quit IRC18:46
*** htruta has quit IRC18:46
*** mitz has quit IRC18:46
*** ByteSore has quit IRC18:46
*** zhiyan_ has quit IRC18:46
*** jdennis has quit IRC18:46
*** openstackgerrit has quit IRC18:46
*** marcoemorais has quit IRC18:46
*** hrybacki has quit IRC18:46
*** mhu has quit IRC18:46
*** comstud has quit IRC18:46
*** mrda-away has quit IRC18:46
*** mgagne has quit IRC18:46
*** dolphm has quit IRC18:46
*** vishy has quit IRC18:46
*** zigo has quit IRC18:46
*** jgriffith has quit IRC18:46
*** Ephur has quit IRC18:46
*** shufflebot has quit IRC18:46
*** uvirtbot has quit IRC18:46
stevemarglobal notice eh18:46
*** openstackgerrit has joined #openstack-keystone18:46
*** praneshp has joined #openstack-keystone18:46
*** marcoemorais has joined #openstack-keystone18:46
*** david-ly_ has joined #openstack-keystone18:46
*** vishy has joined #openstack-keystone18:46
*** zzzeek has joined #openstack-keystone18:46
*** nsquare has joined #openstack-keystone18:46
*** chandan_kumar has joined #openstack-keystone18:46
*** hrybacki has joined #openstack-keystone18:46
*** diegows has joined #openstack-keystone18:46
*** bknudson has joined #openstack-keystone18:46
*** mhu has joined #openstack-keystone18:46
*** richm has joined #openstack-keystone18:46
*** miqui has joined #openstack-keystone18:46
*** afazekas_ has joined #openstack-keystone18:46
*** mberlin1 has joined #openstack-keystone18:46
*** htruta has joined #openstack-keystone18:46
*** mrda-away has joined #openstack-keystone18:46
*** mitz has joined #openstack-keystone18:46
*** jamielennox|away has joined #openstack-keystone18:46
*** comstud has joined #openstack-keystone18:46
*** ByteSore has joined #openstack-keystone18:46
*** zhiyan_ has joined #openstack-keystone18:46
*** jgriffith has joined #openstack-keystone18:46
*** ekarlso has joined #openstack-keystone18:46
*** Ephur has joined #openstack-keystone18:46
*** mgagne has joined #openstack-keystone18:46
*** jdennis has joined #openstack-keystone18:46
*** dolphm has joined #openstack-keystone18:46
*** uvirtbot has joined #openstack-keystone18:46
*** shufflebot has joined #openstack-keystone18:46
*** zigo has joined #openstack-keystone18:46
*** sets mode: +o dolphm18:46
*** mitz has quit IRC18:46
dstaneklooks like a split!18:46
*** mitz- has joined #openstack-keystone18:47
*** david-ly_ has quit IRC18:47
marekdstevemar: dstanek anyways, getting back to business. I think there is too bug generalisation in the user workflow,  and I tried to bring together some ideas I have about user-flow along with their pros and cons.18:47
marekdstevemar: dstanek of course i might have missed someting, so i wanted to hear your coments.18:47
dstanekwhat is the difference between the new trusted service provider concept and the concept we built for our current federation implementation?18:47
*** david-lyle has joined #openstack-keystone18:47
dstanekmarekd: i've reading your evernote now18:48
marekddstanek: answering your question - the goal is to have better transparency, which idealy would implicate better ser experience.18:48
*** david-lyle has quit IRC18:49
stevemardstanek, in the current impl, keystone is always the SP with an idp being tivoli or something else. In order to have keystone acting as an IdP, we need to have a way to store service providers18:50
*** david-lyle has joined #openstack-keystone18:50
marekdstevemar: i think the right question to answer is : "Why do we wan to Keystone become IdP with all the saml/oidc stuff"18:51
*** openstackgerrit has quit IRC18:51
dstanekah ok, so this is the other side of the equation18:51
*** openstackgerrit has joined #openstack-keystone18:52
stevemardstanek, correcto18:55
stevemarmarekd, yes, thats part of the issue18:55
*** nsquare has quit IRC18:56
*** mberlin1 has quit IRC18:56
*** jamielennox|away has quit IRC18:56
*** ekarlso has quit IRC18:56
marekdstevemar: if we want keystone to become IdP just to provide extended Service Catalog then in my opinion it's completely pointless :-) if we, however, want to make use of the first token, which will prbably happen then maybe we will win something.18:57
marekdstevemar: do you think one token for all federated clouds will work?18:57
*** cuddyt has quit IRC18:57
marekdstevemar: like projected at the very beginning?18:58
stevemarmarekd, upon the first auth request?18:58
*** ayoung is now known as ayoung_afk18:58
marekdstevemar: yes, get a token from CERN, and use exactly this token against IBM.18:58
stevemarmarekd, okay, and assume you get the extended catalog, and IBMs endpoints in your auth request ?18:59
marekdstevemar: heh, exactly. problem number one - extremly big service catalog18:59
marekdstevemar: (note i am not a fan of this solution - one token across many clouds)19:00
stevemarmarekd, not if you did /auth/token&IBM then you just get IBM service catalog, not your own, or other SPs19:00
marekdok, so i need to know all federated clouds a priori?19:01
marekdthen I'd say - use old Icehouse federation.19:01
stevemarmarekd, go back a few steps19:02
stevemarmarekd, if you don't like one token across multiple services, then how do you propose to do it in 1 trip?19:02
marekdwhat do you meant in 1 trip?19:03
marekdstevemar: very likely every cloud will issue it's own token, scoped to project that is local to that cloud.19:04
stevemarmarekd, walk me through the flow you are thinking of :)19:04
marekdstevemar: but..wait.19:05
marekdwe can get back to page one.19:05
stevemari like page one19:06
marekdstevemar: let's suppose we want CERN issue a token19:06
marekdwhich will work across multiple federated clouds.19:06
marekdno new tokens.19:06
*** rwsu has quit IRC19:06
marekdstevemar: who and how should scope this token?19:07
marekddo you want  CERN's keystone to be aware what projects have Rackspace?19:07
marekdhow do i list accessible projects? All in all we want me to talk only with CERN's Keystone.19:07
*** erecio has joined #openstack-keystone19:08
marekdbesides I is Rackspace who should be in power to decide who and how can access their resources (in other words, they should do the mapping, assign groups and later roles)19:08
*** gordc has joined #openstack-keystone19:08
marekdstevemar: next thing: as dstanek pointed out not so long ago - what if send my token to Rackspace, who gets compromised. Now, hackers who own RAX Keystone can intercept this token and access poor IBM.19:09
marekdand all in all it will be CERN who gets billed for all this.19:10
*** rodrigods_ has joined #openstack-keystone19:12
stevemarmarekd, agree that is should be RAX who decides19:14
marekdstevemar: ++19:14
stevemarmarekd, so you think it would be a bad idea for you (a CERN user) to talk to RAX?19:15
marekdstevemar: hm? why?19:15
stevemarmarekd, you wrote "All in all we want me to talk only with CERN's Keystone."19:16
marekdstevemar: ah, no i meant 'let's assume I will get the token only once, from my CERN's Keystone and later use it across remote services like they were my local ones"19:17
*** rwsu has joined #openstack-keystone19:17
stevemarah okay19:17
marekdstevemar: and then i think we have problems with scoping, and hacking external clouds.19:17
*** marcoemorais has quit IRC19:18
*** marcoemorais has joined #openstack-keystone19:18
*** nsquare has joined #openstack-keystone19:19
*** mberlin1 has joined #openstack-keystone19:19
*** jamielennox|away has joined #openstack-keystone19:19
*** ekarlso has joined #openstack-keystone19:19
*** marcoemorais has joined #openstack-keystone19:19
marekdstevemar: i just think 'federation' should also mean limited trust. Keystone-SP will trust that Keystone-IdP says 'i confirm this is Marek'19:19
marekdstevemar: but KSP should not trust KIdP saying 'let this user access project TOP-SECRET-RAX-TENANT'19:19
stevemarmarekd, but thats all in the mapping., isnt it?19:20
marekdstevemar: right, but where is place for the mapping? Can we do it without RAX Keystone issuing new token?19:21
marekdstevemar: if you have any idea then fire away.19:21
marekdstevemar: maybe i am becoming blind to some simple solutions...:(19:21
marekdstevemar: in the initial concept you have your token and doesn't want to have more interaction with IdPs, you simply want to use your token across all those 10 clouds which happen to be federating themselves.19:22
*** rodrigods_ has quit IRC19:23
*** harlowja is now known as harlowja_away19:24
*** topol has joined #openstack-keystone19:24
stevemarbut that token won't have any knowledge about anything other than endpoints19:26
marekdstevemar: but if you want to use it across many clouds all those cloud must validate19:27
marekdthe token is right19:27
marekdand you is you.19:27
marekdand token itself is your  virtual identificator, right?19:28
marekdtoken == you and later your bill and real $$$19:28
marekdstevemar: did I cause you a heart attack? :(19:30
stevemarmarekd, no heart attack :)19:37
marekdstevemar: ufff :-)19:37
marekdhopefully only coffee break :-)19:38
stevemarmarekd, you know it19:38
stevemarmarekd, so what about passing that token to the OS-FED url?19:38
*** david-lyle has quit IRC19:38
stevemarright, then you have yet another token...19:39
marekdstevemar: yes.19:39
marekdyou cannot even pass your token to OS-FED url just as is.19:39
marekdhow do you get the assertion?19:39
marekdthere must be some extra steps19:40
marekdunless you pass assertion in your token :P19:40
stevemarmarekd, the token contains *some* data19:40
stevemari was hoping that between the token data, and mapping, we might get something19:41
marekdstevemar: what token data?19:41
*** erecio has quit IRC19:42
marekdstevemar: okay, maybe you want me to walk through the workflow.19:44
*** david-lyle has joined #openstack-keystone19:47
stevemarmarekd, user auth /v3/auth/token&sp=RAX19:47
stevemarand lets scope it to a project19:48
stevemari should get back a catalog with RAX endpoints and project / user / role data right?19:48
marekdstevemar: /v3/auth/token&sp=RAX -> at CERN's Keystone?19:49
marekdhow CERN's Keystone knows what projcts I can access?19:49
marekdat RAX ofc19:49
stevemarmarekd, scope to whatever project you are working on at CERN, the one that needs more resources19:50
stevemarmarekd, then use that token in the OS-FED request at RAX19:50
stevemarRAX will validate the token is coming from a trusted resource, and will using a mapping to go from project A at CERN to project X at RAX ?19:51
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Make adminurl and internalurl parameters to EndpointManager create() optional
stevemarmarekd, that's what I was thinking anyway19:51
stevemarmarekd, i could be off the mark19:51
marekdstevemar: hmmmmmm19:52
marekdstevemar:  do you want to use assertion somewhere?19:52
marekdor just map projects into projects?19:52
stevemarmarekd, the token is an assertion, it's showing you the user data and what he has authority to access19:52
stevemarmarekd, it's just not a SAML assertion19:53
marekdstevemar: ok, in that case we abandon saml, openidc and all those protocols.19:53
stevemarmarekd, think it through though!19:53
stevemarmarekd, maybe i'm crazy19:53
marekdstevemar: i don't mind :-)19:53
marekdstevemar: but...19:53
marekdwe are getting back to dstanek's question.19:54
dstanekmarekd: yay!19:54
marekdok, i send my token19:54
marekdto RAX19:54
morganfainbergzzzeek, let me know when you're back, i want to run something by you.  for limited use trusts19:54
marekdRAX is compromised19:54
stevemardstanek has been waiting patiently this whole time19:54
marekdintercepts my token19:54
hrybackiayoung_afk: ping19:54
* morganfainberg is also listening now to this convo 19:54
*** david-lyle has quit IRC19:54
zzzeekmorganfainberg: was just going out for a coffee….15 min?19:55
marekdand now bad people can impersonate myself at IBM19:55
stevemarmarekd, i dont have an answer for that, but realistically if someone is able to see your token at this level, he can catch it at another level19:55
morganfainbergzzzeek, great! I wouldn't dream of getting between someone and their coffee19:55
morganfainbergzzzeek, also might owe ya a coffee in Paris for the summit ;)19:55
stevemarmarekd, either way, i think this problem will always exist, no matter the implementation19:56
marekddstanek: morganfainberg do you agree with stevemar ?19:56
dstanekstevemar: i've been watching on/off, and reading19:56
zzzeeki likely have to miss paris b.c. my wifes due date is nov 6 :( :)19:56
morganfainbergzzzeek, thats a damn good reason to miss the summit though ;) gratz!19:56
stevemarzzzeek, that is a very good reason :)19:57
morganfainbergmarekd, hm. this is a tough one.19:57
marekdstevemar: if  the client handles a token per cloud we could avoid this...19:57
stevemarmarekd, do i watch ALG-RUS or KOR-BEL?19:57
morganfainbergmarekd, this is exactly why i always was concerned about cloud X issuing a token for Cloud Y19:57
*** david-lyle has joined #openstack-keystone19:58
morganfainbergmarekd, with the initial proposal that is19:58
stevemarmorganfainberg, that is old news now!19:58
morganfainbergor well using a token that could be used in either.19:58
morganfainbergstevemar, bah, i'm still catching up19:58
morganfainbergstevemar, Kor-Bel19:58
morganfainbergstevemar, No question19:58
morganfainbergI have high hopes for Belgium19:59
morganfainbergthough Korea isn't likely to make it to knock-out19:59
stevemarmorganfainberg, thanks for the suggestion :)20:00
morganfainberg*likely = not possible?20:00
*** lbragstad has left #openstack-keystone20:00
marekdstevemar: did you ask for suggestions or wanted us to guess? :P20:00
stevemarmorganfainberg, the whole mathematics thing is a downer huh20:00
stevemarmarekd, suggestions :)20:00
morganfainbergstevemar, lol20:00
marekdyeah, watch BEL :P20:00
marekdmaybe i should watch it too...20:01
morganfainbergstevemar, ALG vs RUS might be a more even game, but i'd totally watch BEL20:01
marekdbah, i need to pack my stuff for the weekend.20:01
morganfainbergmarekd, where you headed?20:01
marekdgonna see if i manage to climb 4000m above the sea level...20:02
morganfainbergmarekd, like hike? or mountaineering? or rock climbing?20:02
morganfainbergmarekd, awesome!20:02
marekdwe will see :-)20:03
morganfainbergmarekd, I need to go up to visit my brother go for a bike ride this weekend20:03
*** erecio has joined #openstack-keystone20:03
morganfainbergmaybe i'll go for a ride at 6000ft ;)20:03
*** bobt has quit IRC20:03
marekd(need to convert into meters :P)20:03
morganfainbergmarekd, you've inspired me to go to elevation this weekend and be active20:03
morganfainberghey, 6000ft is what... 2km ?20:04
marekd6000ft ~ 1800m20:04
morganfainbergiyeah it's not as high as you're headed20:04
morganfainbergbut still!20:04
*** vhoward has left #openstack-keystone20:04
marekdbut you are biking....20:04
marekdthat's different.20:04
marekdeh, last year i went that high and it wasn't the best experience i've ever had20:05
morganfainbergmarekd, i could go even to 2500m easily, but ugh, always hurts20:05
morganfainbergmarekd, i'm hoping next year to climb (hike?) mt. whitney (4,421 m)20:05
marekdgood for ya :-)20:05
marekdever been that high?20:05
morganfainbergmarekd, reminds me to put in for the permit this year20:05
morganfainbergnever been over 3700m20:06
marekdmorganfainberg: ah, you need permits for that...20:06
morganfainbergbut used to hike up in the sierras when i was younger. (yosemite)20:06
marekd3700 is high enough to suffer from heigh.20:06
morganfainbergand the back country20:06
morganfainbergyeah one of the times i wasn't happy till almost a week into being at elevation20:06
morganfainbergthen it was time to head home >.<20:06
marekdlast year at 4000m i was completely destryed....20:07
morganfainbergmarekd, well this year will be better!20:07
* morganfainberg is positive about these things.20:07
marekdmorganfainberg: let's see ;-)20:07
marekdmorganfainberg: so you are watching the game ?20:07
marekdor hanging around here?20:07
morganfainbergnah, gotta write code20:07
morganfainberghave a nasty bug to fix20:07
morganfainbergthen gotta hit the gym, and see if i can make it to OpenStack LA meetup20:08
marekdpity, I was hoping you want to share your opinions on k2k :P20:08
morganfainbergmarekd, oh i can chat about that now.20:08
morganfainbergalso need to sync up w/ mike about the trust thing20:08
morganfainbergso waiting on coffee returns20:09
morganfainbergmarekd, unrelated can i visit cern? ;)20:09
marekdmorganfainberg: whenever you want.20:09
morganfainbergawesome! I totally want to visit ;)20:09
marekdmorganfainberg: i will make sure you join some underground visits20:09
marekdbefore/afer paris?20:10
morganfainbergafter, wont be before.20:10
zzzeekmorganfainberg: back20:10
morganfainbergzzzeek, welcome back!20:10
marekdmorganfainberg: sure!20:10
stevemarmorganfainberg, so, what do you think about using the token you received from IdP-keystone, and pass that token to OS-FEDERATION url at SP-Keystone. And using the token data as an assertion and put those values through the mapping engin?20:10
stevemar(after the token has been validated as coming from a trusted IdP)20:11
morganfainbergstevemar, let me read that one more time ... brain is just now kicking in post coffee20:11
stevemarmorganfainberg, cool20:11
marekdmorganfainberg: ++20:11
morganfainbergzzzeek, so i'm thinking we just create a table that we inject a row in for each trust issued (limited use trusts), if a trust is completely expired (hit the limit) we can mark it expired explicitly and cleanup the limited use rows.20:12
morganfainbergzzzeek, it doesn't solve race conditions, but at the very least it means we have a clean audit of how many were issued.20:12
zzzeekmorganfainberg: OK, at the moment I dont actually know waht kind of concept we are representing, only that you were locking a row.  i guess you are saying, instead of doing UPDATE just keep INSERTing new rows and clean out old ones20:13
morganfainbergzzzeek, rather than a question as to "well we tried, and we make a best effort to not issue too many but we can't tell you more"20:13
morganfainbergzzzeek yep.20:13
zzzeeki would say that that can be very performant, becuase INSERTs are easy20:13
morganfainbergzzzeek, what we're representing is a decrementing counter. when it hits 0, no more trusts can be issued20:13
zzzeekbut what do you do with the rows in these tables?   ah20:13
morganfainbergzzzeek, trust is a delegation of auth via a keystone token20:13
zzzeekso you need to query it how, that theres a count() of trusts ?20:14
morganfainbergzzzeek, well no, more of a count() of tokens issued for trust X20:14
zzzeekright, so counting tokens20:14
zzzeekdo these tokens have unique identifiers ?20:14
morganfainbergzzzeek, they do, but we're moving away from storing the tokens.20:14
morganfainbergzzzeek, token ids can be > 8k20:15
morganfainbergPKI signed data issue20:15
zzzeekwell if you are storing row-per-token here you might as well put it in …ah .  hm no simple GUID for it?20:15
morganfainbergzzzeek, well, we can use the short-hash.20:15
marekdstevemar: do you want a RAX cloud to return a token in return?20:16
morganfainbergzzzeek, but long story short, i was using select for update to lock the row and prevent extras from being issued. i'm ok if we make a "best effort" on issuance.20:16
morganfainbergzzzeek, but if we make a best effort i want to know how many were issued20:16
morganfainbergzzzeek, audit trail20:16
marekdstevemar: blah...20:16
marekdstevemar: user uses CERN-token and hits RAX20:17
* morganfainberg hates having to work around something silly like a deployment choice (read: best practice) for a certain RDBMS20:17
marekdstevemar: RAX Keystone maps projects and things basing on data from CERN-token.20:17
morganfainbergmarekd, i'll share thoughts once i'm done w/ convo w/ zzzeek.20:17
marekdstevemar: what is returned?20:18
marekdmorganfainberg: okay.20:18
stevemarmarekd, RAX would return a RAX token, scoped to a project (result of the mappin)20:18
morganfainbergstevemar, keystone token as and assertion equivalent?20:18
morganfainbergstevemar, not a bad idea...20:18
marekdstevemar: ha! so if I now wanted to use IBM i would have to get another token, IBM-token20:19
stevemarit's got the user, roles and project info already20:19
marekdand later juggle with both of them?20:19
stevemarmarekd, hmm, yeah...20:19
stevemarmarekd, i guess thats not optimal20:19
marekdstevemar: we don't have one token to be used accross multiple clouds...20:20
stevemarthat would help with dstaneks vulnerability situation20:20
*** david-lyle has quit IRC20:20
marekdstevemar: and this is what i was basically saying :-)20:20
marekdstevemar: i don't think this would really help...20:20
marekdstevemar: you send your token to RAX.20:21
*** david-lyle has joined #openstack-keystone20:21
marekdstevemar: you send your identity to a stranger20:21
morganfainbergzzzeek, unless we can use a transaction to limit issuance?20:21
marekdand have no control what happens with that after that.20:21
zzzeekmorganfainberg: how exactly20:21
morganfainbergupdate trust where id=<trust_id> and count=<expected count> ?20:21
marekdstevemar: how about sending to RAX not a CERN-token, but token which is prepared only for RAX?20:22
marekdstevemar: we have agreed client must handle multiple tokens already....20:22
morganfainbergso query, get the expected count, compare if we've hit the limit, if not try an update. if update fails we try again [unless 100% consumed]20:22
*** harlowja_away is now known as harlowja20:23
zzzeekmorganfainberg: OK these are tokens as they are issued, what deos the update mean20:23
*** andreaf_ has joined #openstack-keystone20:23
marekdstevemar: then, whatever RAX receives, it cannot use with IBM20:23
morganfainbergthe update is on the trust record row, decrementing the counter20:23
*** andreaf_ has quit IRC20:23
zzzeekmorganfainberg: OK is this again one row per trust type?   counting number of issuances ?20:24
morganfainbergzzzeek, so the workflow is supposed to be: check to see if trust can issue tokens, decrement counter, issue token20:24
zzzeekmorganfainberg: sure, so what was the SELECT FOR UPDTE for, because you did a separate SELECT ?20:24
marekdstevemar: one more thing...20:24
zzzeekmorganfainberg: yeah if you can UPDATE in one go then you’re doing it atomically, sure20:24
*** david-lyle has quit IRC20:25
morganfainbergzzzeek, and if we explicitly make the update require the count to be what we queried, we should be safe from races20:25
marekdstevemar: we are here creating another protocol...somehow. do we want to do this? I think at some point morganfainberg was not happy with that. we can use saml/oidc by adding some extra steps in the middle.20:25
zzzeekmorganfainberg: well yes you can do that, it’s kind of like using a version id.    that is, you incerment the “Version” of the row each time you do somethign with it and make sure that’s the version you’d loaded20:25
morganfainbergzzzeek, yep.20:26
zzzeekmorganfainberg: but this is optimistic locking.  if the version isn’t what you expect, what do you want to do ?20:26
morganfainbergzzzeek, i don't like it (select for update is just so much ... cleaner)20:26
marekdstevemar: morganfainberg: - some possible flows, including something similar to what just stevemar proposed (last one)20:26
zzzeekmorganfainberg: ive been assuming pessmistic locking was a req here.  i always use an optimsitic approach20:26
morganfainbergzzzeek, try again, keep trying until either we run out of tokens to issue, or the update is successful20:26
marekdstevemar: morganfainberg i will be back in 20-30 minutes.20:26
morganfainbergzzzeek, ++20:26
stevemarmarekd, same20:27
zzzeekmorganfainberg: OK if you think contention is low, then you can go with that20:27
zzzeekmorganfainberg: i dont know how often this change occurs (100s per second, a few per hour) so that matters20:27
morganfainbergzzzeek, shouldn't be 100s per second, at most it should be a couple per second with window in between20:27
morganfainbergprobably closer to a few a minute at the high high high end20:28
zzzeekmorganfainberg: you can do it like this:   “UPDATE table SET <whatever> WHERE id=<the id> AND counter_thing_we_expect=<the count we expect>”, then count the rows matched.  it should be one20:28
morganfainbergzzzeek, ++ that was the plan.20:29
morganfainbergzzzeek, i'll respin this code to work like that.20:29
morganfainbergthanks! :)20:29
zzzeekmorganfainberg: i see that as cleaner b.c. i see locking as putting a big broken clamp on the database20:29
*** vhoward has joined #openstack-keystone20:30
morganfainbergzzzeek, yeah. there are a lot of concerns i have with races in keystone when we run under apache or with multiple workers20:30
morganfainbergzzzeek, but this one is related to a authorization limit, so i was being a bit more picky about it.20:30
*** erecio has quit IRC20:30
morganfainbergzzzeek, i'll circle up with you as we start working on the other race concerns in keystone, maybe we can cleanly solve more of them with optimistic locking :)20:31
morganfainbergstevemar, marekd, let me know when you're back20:31
zzzeekmorganfainberg: OK :)20:33
*** diegows has quit IRC20:34
*** marcoemorais has quit IRC20:34
*** marcoemorais has joined #openstack-keystone20:34
*** marcoemorais has quit IRC20:35
*** marcoemorais has joined #openstack-keystone20:35
*** marcoemorais has quit IRC20:35
*** marcoemorais has joined #openstack-keystone20:35
morganfainbergvishy, ping - re region table20:43
morganfainbergvishy, all i have to say is "ick" :(20:44
vishyi wish my first thought was correct20:44
vishybecause it would have been way easier20:44
*** david-lyle has joined #openstack-keystone20:44
morganfainbergvishy, yeah. the sanity check is ... i think sort of broken20:44
morganfainbergbecause a bad migration can wedge you20:44
morganfainbergthere is no recovery20:45
morganfainbergi think i'm going to add a --skip-sanity check options to keystone manage, and restrict it to a single version jump if set20:45
morganfainbergvishy, alternatively i could just hack this to run a magic migration to fix the table in this one-off case20:46
*** radez is now known as radez_g0n320:47
*** dstanek is now known as dstanek_zzz20:47
vishymorganfainberg: i think we are just going to fix the migration in place which solves our problem20:48
vishybut the general upstream case is a huge mess for sure20:48
morganfainbergvishy, for you it's less of an issue, i'm thinking from the upstream case20:48
morganfainbergi'm wondering if anyone has really gotten wedged with this besides you.20:49
vishythere was one on the ml20:49
*** dims_ has joined #openstack-keystone20:49
*** bobt has joined #openstack-keystone20:49
morganfainbergok. let me fix the migration. i think i'll add a magic hook for this one off in to go aroudn the migration tools to fix it if wedged20:50
vishyfair enough20:50
morganfainbergbasically if sanity_check fails, and version == <broken version>, go fix table20:50
morganfainbergand try again20:51
morganfainbergi'll tag you on the master review and once we get that in, i'll get it backported to I20:51
* morganfainberg wonders how to craft a test case for this one.20:52
*** jaosorior has quit IRC20:52
*** dims__ has quit IRC20:52
*** andreaf_ has joined #openstack-keystone20:56
*** david-lyle has quit IRC20:57
*** david-lyle has joined #openstack-keystone20:57
*** david-lyle has quit IRC20:58
*** david-lyle has joined #openstack-keystone20:58
marekdmorganfainberg: ok, let's say i am back.21:02
morganfainbergmarekd, hehe21:03
morganfainbergmarekd, so you're thinking if you need to talk to <SP Cloud, e.g. RAX> you should have a token explicitly scoped to talk to RAX and only RAX [can't be used elsewhere for anything else]21:04
marekdmorganfainberg: yes.21:04
morganfainbergmarekd, this seems to play nicely with the session token spec, you know21:05
marekdmorganfainberg: stevemar already agreed there is no way to have *only* one token21:05
marekdmorganfainberg: since remote cloud (RAX) needs to do some mapping etc.21:05
morganfainbergnow, out of curiosity, could keystone issue a non-token assertion that could be used for that purpose?21:05
morganfainbergthis feels an awful lot like we're creating a new protocol21:05
marekdmorganfainberg: we are.21:06
openstackgerritA change was merged to openstack/keystone: Convert explicit session get/begin to transaction context
morganfainberg(not saying we shouldn't if it is the best course of action)21:06
morganfainbergbut if we could use a protocol that already exists, might be better, no?21:06
marekdmorganfainberg: i think we can try to reuse OpenID Connect/SAML but this could mean extra steps in between.21:06
openstackgerritA change was merged to openstack/keystonemiddleware: Update setup.cfg to remove keystoneclient ref
morganfainbergmarekd and the proposers explicitly don't want extra steps21:06
* morganfainberg grumbles a little.21:07
marekdmorganfainberg: they want to always use one token...21:07
marekdmorganfainberg: they don't want to change the client...we already will need to change the client.21:07
marekdmorganfainberg: i was thinking that21:07
marekdwe might want to hide saml authentication a little bit.21:08
morganfainbergmarekd, yeah thats fine21:08
morganfainbergmarekd, i just want to make sure we're not doing a "not invented here" approach21:08
marekdmorganfainberg: a) local user authN with CERN21:08
morganfainbergbut more doing a "this is the best approach, regardless of where it was invented"21:08
*** dstanek_zzz is now known as dstanek21:09
marekdmorganfainberg: we can try making the CERN-token just a 'key' for authentication with Keystone-IdP21:10
marekdand the federation flow is kept.21:10
*** hrybacki has quit IRC21:11
morganfainbergmarekd, i'm ok with using the full mapping system. just making sure we don't ignore something that exists that meets our needs21:11
*** hrybacki has joined #openstack-keystone21:11
morganfainbergand if SAML or other such protocol doesn't fit/meet the needs/can't be made to meet our needs, that is fine21:11
marekdmorganfainberg: i think making our own protocol seems to be easy, but might get harder to make it right..21:12
marekddstanek: did you read that evernote ?21:12
morganfainbergmarekd, ++ and this would be predicated on documenting the protocol and not deviating from it for convienence21:12
morganfainbergi would expect this protocol to work across versions of keystone.21:12
morganfainberg(in fact, it would need to)21:13
morganfainbergmarekd, which is why i want to be 100% sure something that is well defined can't fit the bill :)21:13
morganfainberge.g. SAML, openid, <something else>21:13
marekdmorganfainberg: sure.21:13
marekdmorganfainberg: i think we can reuse existing protocols21:14
marekdmaybe somehow break the workflow21:14
morganfainbergmarekd, yeah.21:14
morganfainbergmarekd, i like everything said so far, i think we're on the right path. I think there is value here21:15
marekdmorganfainberg: hm, look.21:15
morganfainbergi just am concerned about the implementation being "right"21:15
marekdmorganfainberg: me too. and at some point we need to decide "SAML", or "OIDC", or "let's implement something new"21:15
marekdmorganfainberg: ok, lets discuss such scenario.21:16
morganfainbergmarekd, right-o :)21:16
marekdmorganfainberg: CERN - local Keystone, RAX, remote.21:16
* morganfainberg listens.21:17
*** dstanek is now known as dstanek_zzz21:19
marekdmorganfainberg: user logins with CERN, gets token. He now goes to RAX's OS-FED URL and initiates federated authN. RAX Keystone issues SAML/OIDC request authn and sends it directly to keystone-IdP (CERN). It uses user's token as a key to authenticate the user. Keystone-IdP returns SAML assertion, there is mapping and things we do in Icehouse now.21:19
marekduser is not aware there was some communication between keystones21:19
marekdRAX returns token to be used with RAX only.21:19
*** hrybacki has quit IRC21:20
*** andreaf_ has quit IRC21:20
marekdbut we cannot rely on apache modules :( and need to implement SAML-specific logic into keystone.21:20
morganfainbergmarekd, something like pysaml, yes21:20
marekdmorganfainberg: yes, and some hacks on top of it21:20
morganfainbergwould RAX ever see the CERN token in this case?21:20
marekdmorganfainberg: yes.21:20
morganfainbergwould the CERN token be scoped in a way to make it only usable by RAX?21:21
marekdbut i can imagine client somehow makes this token usable with RAX only.21:21
morganfainbergor is it a "normal" token21:21
marekdmorganfainberg: i'd say usable with RAX only, otherwise we are facing impersonation problem again.21:21
morganfainbergyeah, security thoughts MITM + scraping the token and then using with CERN would be bad21:21
*** tellesnobrega has quit IRC21:22
marekdwe can also put some burden on a client.21:22
morganfainbergok so, good from resuse tech, bad from implementing SAML logic directly and hakcing it up [our own protocl that sorta looks like SAML for transport]21:22
marekdso  keystone RAX is not breaking the federation workflow, but it all happens with a client involved.21:22
morganfainbergand CERN's workflow would be issuing an assertion, so it would look normal-ish21:23
morganfainbergit's just very client specific.21:23
marekdclient goes to RAX OS-FED url, he gets authN saml request, client agains passes this request to Keystone-IdP and gets assertion, and again returns to Keystone RAX with an assertion.21:23
marekdyes, very client specific, federation clients are always involved.21:24
marekdprons here are: we can reuse Icehouse federation alsmost entirely21:24
marekdRAX doesn't see CERN's token.21:24
*** tellesnobrega has joined #openstack-keystone21:24
marekdcons: big impact on the client.21:24
morganfainbergmarekd, heck it looks like icehouse's federation might even work (as a consumer, e.g. RAX)21:24
* morganfainberg nods.21:25
*** marcoemorais has quit IRC21:25
marekdmorganfainberg: yes21:25
stevemarmarekd, morganfainberg catching up21:25
marekdmorganfainberg: on the other hand..what's the added value with all that? :-)21:25
*** marcoemorais has joined #openstack-keystone21:25
marekdmorganfainberg: why not leave old federation? :-)21:25
marekdmorganfainberg: we are now talking about implementing LDAP into Keystone...21:26
marekdmorganfainberg: to make it fully functional IdP.21:26
morganfainbergmarekd, it means that the public clouds or external SPs can lag behind a little21:26
morganfainbergmarekd, true.21:26
*** david-lyle has quit IRC21:26
morganfainbergoidc would be about the same (benefits/flaws)21:27
morganfainbergat quick glance21:27
*** david-lyle has joined #openstack-keystone21:27
marekdthe designed workflow is pretty much the same.21:27
marekdi was thinking oAuth21:27
marekd*somehow* but didn't find anything brilliant enough :/21:27
*** henrynash has quit IRC21:27
*** david-lyle has quit IRC21:28
morganfainbergmarekd, so oAuth doesn't fit the bill either21:28
*** david-lyle has joined #openstack-keystone21:28
marekdoauth is generally rather authZ not authN, I think...21:28
marekdwell, basically i didn't find a good use for oAuth.21:29
marekdi think that even if we reuse SAML/OIDS we will be doing some small hacks.21:29
*** henrynash has joined #openstack-keystone21:29
*** henrynash has quit IRC21:31
stevemarmarekd, yeah oauth is authZ only, not authN21:32
morganfainbergmarekd, ok lets explore "implement our own protocol"21:32
marekdmorganfainberg: ++21:32
marekd(also keep in mind joe savak initially wanted to use existing protocols...)21:33
morganfainbergsince we know oAuth isn't going to work, and SAML/OIDC has weird hackyness (not right out, but still not a perfect fit)21:33
marekdmorganfainberg: ofirst of all: we are not compilant with the rest of the world :-)21:34
morganfainbergmarekd, which bugs me some.21:34
morganfainbergbut even if we used SAML we're only "sort-of" compliant21:34
marekdmorganfainberg: yeah.21:34
marekdunless we fully align with saml workflow...which we are desperately trying to avoid :-)21:35
morganfainberglol, it was my original thought that we would head more that direction than avoid it21:35
morganfainbergbut the spec outlines some usecases that makes that a hard(er) sell21:35
marekdmorganfainberg: if we align saml design than again - we are reusing icehouse federation21:36
morganfainbergmarekd, yep. just making keystone more of a first-class IDP (regardless of what the backend is, a lot more support)21:37
marekdmorganfainberg: and we can at maximum define IdP authN method...for instance with a token issued by a local Keystone.21:37
morganfainbergit would almost say we should make keystone-idp it's own process.21:37
marekdmorganfainberg: right.21:37
morganfainbergand keystone only ever consumes (via federation) the IDP data21:37
morganfainbergok so lets set that aside, and see what it'sgoing to take to implement something custom21:38
morganfainbergso i see us needing a couple of things21:38
morganfainbergsecure way to validate/trasnmit data (x509 certs between the keystones?)21:39
*** mrda-away is now known as mrda21:39
marekdmorganfainberg: some public/private key enryption.21:39
morganfainberga definition of what the inter-keystone data looks like.  very well defined, validated, and versioned21:39
marekddoes x509 also covers signing ?21:40
morganfainbergversioning = forward thinking not needed out the gate21:40
morganfainbergyah x509 can do signing, we use it for PKI tokens21:40
morganfainbergwe do s/mime,21:40
morganfainbergkeystone already has to understand CMS (S/MIME) so we can just re-use that21:41
morganfainbergso what data would need to be transmitted to make the mapping engine reusable in this new protocol. - we want to keep the data sets reasonably small.21:42
marekdmorganfainberg: ok21:42
marekdmorganfainberg: stevemar had a nice idea about mapping projects21:42
marekdmorganfainberg: e.g. i authN with my CERN keystone, scope to my CERN's project21:43
marekdbecuause it's running out of resources21:43
marekdand later, RAX Keystone maps projectA -> projectX (at RAX)21:44
morganfainbergthat kind of flexibility would be great21:44
marekdhowever i don know if that's enough21:44
marekdand will cover all the usecases.21:44
marekdand in fact will be flexible enough.21:44
marekdbut should keep tokens small.21:45
marekdwe cannot scope the token to more than one project, can we?21:45
marekdmorganfainberg: hmmm, and how about dynamic mapping?21:45
marekdmorganfainberg: ah no, forget.21:46
morganfainbergmarekd, hehe21:46
morganfainbergmarekd, no can't scope tokens to more than one project atm (and there are arguments as to if we should ever allow that)21:46
marekdmorganfainberg: RAX keystone should issue new token, signed with its key, so RAX-nova doesn't need play with mappings and all that stuff.21:46
marekdall in all we end with multiple tokens ;/21:47
stevemarone per SP21:47
marekdstevemar: yes.21:47
morganfainbergmarekd, yep.21:47
marekdstevemar: but i think we cannot skip that.21:48
marekdhmmm, this could even work and be relatively simple in its design.21:49
marekd(if its simple by design this will probably end up hard in implementation :P)21:49
stevemarmarekd, wouldn't be that hard IMO21:50
stevemarSP CRUD (has to happen no matter what path we go down)21:50
marekdlet's walk through the workflow21:50
stevemarand enhance the mapping21:50
marekdstevemar: and signing, validating, en/decrypting tokens.21:50
stevemarmarekd, yep, beat me to typing that.... that part would be tricky21:51
marekdand possibly error prone.21:51
stevemari'll do the first two items if you do that part :P21:51
stevemarmarekd, what would the client process look like?21:52
stevemarclient flow21:52
marekdstevemar: let me try with that21:52
marekda) client logins with CERN Keystone, asks for extended SC, and says he will want to use RAX remote cloud21:53
marekdb) Keystone CERN issues a token and makes it usable with RAX only (maybe just a single attribute in the token?)21:53
marekdc) client scopes the token to CERN's local project/domain21:54
marekdd) client goes to RAX Keystone (url from Service catalog)21:54
*** rodrigods_ has joined #openstack-keystone21:54
marekde) RAX validates the token, sees it was issued by CERN who is tursted and maps CERN's project into project configured at RAX21:54
marekdf) returns valid token scoped to project_RAX to the user.21:54
morganfainbergmarekd, that seems reasonable.21:56
marekdin case RAX is compromised the token from CERN is not usable with IBM, because CERN's Keystone sets flag e.g. 'USABLE_WITH' to 'RAX'21:56
marekdmorganfainberg: hm, i'd split b) into b1 and b2.21:57
marekdotherwise we force user to know federated clouds apriori.21:57
marekda) user logins to CERN and asks for extended SC. He gets a token with list of all remote Keystones (SPs)21:58
marekdb) he now scopes to the project/domain and says he wants to use now RAX21:58
marekdKeystone returns token scoped to a project with, usable with RAX only.21:59
marekdmakes sense?21:59
*** daneyon has quit IRC22:01
morganfainbergmarekd, yeah that makes sense22:01
*** elmiko is now known as _elmiko22:01
* marekd yay!22:01
marekdhow hard will it be for keystoneclient to handle >1 tokens at once?22:03
morganfainbergmarekd, that becomes a question for the session object22:03
morganfainberg i think plays _very_ nicely into this22:04
morganfainbergregardless of the method we use22:04
marekdmorganfainberg: session.Session ?22:04
morganfainbergmarekd, yeah keystoneclient session.Session would need to be able to do this work22:04
morganfainbergmarekd, but if that object can do it, then all the clients would get a lot of this by aassociation22:04
morganfainbergsince jamielennox|away is trying to get all clients to use it for auth/etc22:04
marekdmorganfainberg: i know nothing about ayoung_afk's bp. I will read it tomorrow.22:05
marekdmorganfainberg: that's cool.22:05
morganfainbergsession tokens would be unscoped tokens.22:05
openstackgerritA change was merged to openstack/keystone: Do not log 14+ INFO lines on a broken pipe error (eventlet)
morganfainbergand you would use that as your "Keystone session"22:05
morganfainbergscoped toekns would no longer be re-scopeable22:05
morganfainbergso you can never go Project scoped token to project2 scoped token, to project3 scoped token22:06
morganfainbergyou'd always use the 'session' token for that22:06
morganfainbergseems like a useful construct for the k2k stuff as well.22:06
morganfainberge.g. session -> scoped token is the part b (wanting rax token) so you get the appropriate scoped data blob to talk to rax22:07
morganfainbergwhich.. could be an unscoped token that rax will honor22:07
marekdmorganfainberg: and where in the session token  can i find info about my local project22:09
marekdmorganfainberg: in our case ofc.22:09
morganfainbergmarekd, well session token doesn't have a project, it is explicitly unscoped22:11
morganfainbergmarekd, you'd need to ask keystone for your projects. in the k2k case, that might be done automatically for you22:11
marekdmorganfainberg: uhm, so any idea basing on what info can RAX do the mapping?22:12
morganfainbergmarekd, ah oh i see, it's project specific on this side to project specific on that side22:12
marekdmorganfainberg: yes22:12
* morganfainberg grubmles22:12
morganfainbergeh, still session token -> RAX scope + project.22:13
morganfainbergbut anyway22:13
morganfainbergi still think we need a very clear definition of what data goes into the inter-keystone token-thing22:13
* marekd agrees22:14
morganfainbergmarekd, it sounds like custom protocol is winning because it matches the usecase, unless we can convince people "no just do SAML"22:14
marekdmorganfainberg: yes.22:14
marekdi am glad we are finally getting some consensus.22:15
*** rodrigods_ has quit IRC22:17
marekdmorganfainberg: i will add this topic to the tuesday's agenda.22:17
marekdk2k in general.22:17
openstackgerritgordon chung proposed a change to openstack/keystonemiddleware: add audit middleware
stevemarmarekd, morganfainberg i'm just glad this is starting to make sense22:18
marekdstevemar: ++22:18
stevemarmorganfainberg, marekd I'm going to do another update to the spec then... i'll try to be specific for what goes into the inter-keystone token22:19
stevemarupdate the flow diagrams and wording too22:19
stevemarmarekd, you will have reading material for tomorrow morning22:20
marekdstevemar: thanks for keeping me busy at work :-)22:20
marekdok, i am going to bed. stevemar , morganfainberg thanks for that discussion. It was great and very productive!22:21
marekdgood night22:22
*** marekd is now known as marekd|away22:22
stevemarmarekd|away, gn22:23
*** rodrigods_ has joined #openstack-keystone22:23
*** chandan_kumar has quit IRC22:24
*** oomichi has joined #openstack-keystone22:24
*** david-lyle has quit IRC22:27
*** david-lyle has joined #openstack-keystone22:28
*** henrynash has joined #openstack-keystone22:30
*** hrybacki has joined #openstack-keystone22:31
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Correct the region table to be InnoDB and UTF8
morganfainbergvishy, ^22:32
*** david-lyle has quit IRC22:32
morganfainbergvishy, that might solve the issue for you - shouldn't be hard to port to Icehouse22:32
vishycool looks pretty good22:34
morganfainbergvishy, minor bug actually22:35
morganfainbergnew patchset coming in a moment22:35
morganfainbergi also don't know how to test this except a local env - unit tests aren't going be easy here22:35
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Correct the region table to be InnoDB and UTF8
*** dstanek_zzz is now known as dstanek22:40
*** topol has quit IRC22:41
*** nkinder has quit IRC22:47
*** kevinbenton has left #openstack-keystone22:51
*** dims_ has quit IRC23:01
*** bobt has quit IRC23:01
*** david-lyle has joined #openstack-keystone23:02
*** bknudson has quit IRC23:02
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Make parameters in EndpointManager optional
*** david-lyle has quit IRC23:13
*** jamielennox|away is now known as jamielennox23:25
*** dims_ has joined #openstack-keystone23:26
*** henrynash has quit IRC23:37
*** arun_kant has quit IRC23:40
*** xianghui has joined #openstack-keystone23:47
*** navid has left #openstack-keystone23:49
*** gordc has left #openstack-keystone23:51
*** nkinder has joined #openstack-keystone23:57

Generated by 2.14.0 by Marius Gedminas - find it at!