Tuesday, 2014-06-17

*** oomichi has quit IRC00:08
*** oomichi has joined #openstack-keystone00:16
openstackgerritLi Ma proposed a change to openstack/keystone: Fix the typo and reformat the comments for the added option  https://review.openstack.org/9894200:19
*** richm has left #openstack-keystone00:20
*** ncoghlan has joined #openstack-keystone00:35
*** dims has joined #openstack-keystone00:38
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Docstrings for usability.  https://review.openstack.org/9975500:39
*** diegows has quit IRC00:39
*** dims has quit IRC00:43
*** rwsu has quit IRC00:52
ayoungmorganfainberg, if we -2 that spec can we just kill keystone to keystone federation?00:53
morganfainbergayoung, no. it's a good idea.00:53
morganfainbergayoung, but the spec needs ... work00:53
ayoungmorganfainberg, I fear it00:53
ayoungI fear scope creep in Keystone00:53
morganfainbergayoung, eh, lets see how it plays out. it might not work this cycle00:54
ayoungmorganfainberg, Keystone is about authorization information local to an openstack install.  I am not sure it really makes sense for that data to be shared across installs00:54
ayoungAuthentication, sure00:54
morganfainbergayoung, and that is what i'm pushing for.00:55
ayoungbut Keystone tokens should not be used for Authentication00:55
morganfainbergayoung, keystone providing identity only to an external keystone00:55
morganfainbergayoung, via something like SAML2 or OpenID Coonnect00:55
morganfainbergayoung, not authorization from a remote keystone00:55
ayoungmorganfainberg, in which case, use SAML, and then this spec is not necessary00:55
morganfainbergayoung, yep. working towards that (with a flexibility to do more than saml, e.g. pluggable for OpenID etc)00:56
*** lbragstad has joined #openstack-keystone00:56
ayoungmorganfainberg, that is why I think we need to kill the spec00:56
ayoungit is not that keystone data shouldn't be shared00:56
morganfainbergayoung, don't jump the gun.00:57
ayoungits that people don't understand what should not be in keystone data00:57
morganfainbergayoung, it might morph into exactly what i described00:57
ayoungmorganfainberg, In which case, it is "SAML from Keystone IdP"00:57
ayoungand this spec dies00:57
ayoungthe only reason this spec lives is this:00:57
ayoung"users want to be able to share their authorization decisions across multiple clouds"00:57
morganfainbergayoung, no the spec wont die, the spec will be implementing SAML / OpenID from keystone00:58
*** dstanek is now known as dstanek_zzz00:58
ayoungmorganfainberg, if Keystone is exporting SAML, then K2K is not a thing00:58
morganfainbergayoung, like i said, don't jump the gun here, we're involving the right people to convince the parties that the authz part isn't needed - they want the same thing we want00:58
morganfainberglets use that.00:58
ayoungit is an instance of Samle 2Keystone00:58
morganfainbergayoung, it _is_ it just is keystone provides SAML00:58
morganfainbergit's a different pronounciation of keystone 2 keystone00:59
ayoungmorganfainberg, It just seems that they are following the famous lines from "The Boxer"00:59
ayoungI have squandered my resistance00:59
ayoungFor a pocketful of mumbles,00:59
ayoungSuch are promises00:59
ayoungAll lies and jest00:59
ayoungStill, a man hears what he wants to hear00:59
ayoungAnd disregards the rest.00:59
ayoungmorganfainberg, so...the thing is, I think there is an assumption that Roles and policy are going to be static across OpenStack deployments, and I am fairly certain that is not a good assumption01:03
ayoungmorganfainberg, so it is going to be a mapping problem anyway:01:04
ayoungif a user comes in with role X on  P  from K1,  that needs to become role R on P2  from K201:04
morganfainbergayoung, yep01:04
ayoungmorganfainberg, which, I think means either flattening the role assignments  to something like R_P01:05
ayoungas the group name01:05
ayoungor  some more flexible mapping01:05
ayoungR1 from  K1  becomes  R2 from K2  across the board01:05
ayoungand P1 from K1 becomes P2 from K201:05
ayoungso then R1P1  maps to R2P2  implicitly01:06
morganfainbergayoung, isn't this already covered by mapping - when you setup something like accepting SAML from a source?01:06
openstackgerritA change was merged to openstack/keystone: Add instructions for removing pyc files to docs  https://review.openstack.org/9714001:06
ayoungmorganfainberg, nope01:07
ayoungthe mapping does not allow for breaking something like a role assignment apart01:08
ayoungso you could say01:08
ayoungR1 in P1 maps to the group R1_P101:08
ayoungbut then you would need a separate rule for R2_P101:08
ayoungand R3_P101:09
ayoungbut also an explicit rule for01:09
ayoungR1_P2 R2_P2 etc01:09
ayoungbut what makes more sense is that you want to carry over the whole set of role assignments from Keystone 1 to Keystone 2,  but only for a subset of domains01:09
ayoungand I've written this up in the past.01:10
ayoungmorganfainberg, more tactically:  is https://review.openstack.org/#/c/98897/  OK?01:12
*** dims has joined #openstack-keystone01:12
*** mberlin1 has joined #openstack-keystone01:12
morganfainbergayoung, let me look it over, but it's close if not there.01:13
morganfainbergand we need to figure out the issues w/ the apache deployment tempest even w/ compression01:13
morganfainbergdid a local run of apache + UUID tokens here, passed w/o errors.01:13
*** marcoemorais has quit IRC01:13
morganfainbergso PKI under apache is still causing issues.01:14
*** mberlin has quit IRC01:15
morganfainbergand it looks like we're losing error data in the logs when under apache, seeing ISE reports but no ISEs (HTTP 500) in the keystone log01:15
*** sbfox has joined #openstack-keystone01:16
*** dstanek_zzz is now known as dstanek01:19
ayoung morganfainberg pki under apache is not running with compression, and won't until ^^ passes01:23
morganfainbergayoung, that log is from your patchset01:23
morganfainbergayoung, it should be using PKIZ there01:23
*** hrybacki has joined #openstack-keystone01:23
morganfainbergayoung, i think we're still dropping errors with apache somewhere, i need to go digging into that01:24
morganfainbergoh interesting... we aren't capturing apache logs :P01:25
ayoungnot other than Horizon01:25
morganfainbergyeah let me propose a fix to infra to capture the root apache errorlog. how much you want to bet we have more info in that01:26
morganfainbergyeah i don't see the 500 errors in that log01:26
morganfainbergand we clearly have at least 1 500 generated from keystone if not more01:26
ayoungmorganfainberg, what is that log at all?01:26
ayoungThere should be no keystone screen for a local wsgi app01:26
ayoungit should be kicked off from HTTPD01:27
morganfainbergit is, it's tailing an apache log01:27
morganfainbergthats all the screen does, same as horizon01:27
ayoungexec /bin/bash -c 'cd /opt/stack/new/keystone && sudo tail -f /var/log/apache2/keystone'01:27
ayoungso that is the log we need01:27
morganfainbergwhich is what that screen log is01:28
ayoungmorganfainberg, if it is the header issue, it won't show up in the keystone log01:28
morganfainbergayoung, exactly01:28
morganfainbergayoung, which is why we need to capture the root debug log.01:28
morganfainbergerm error log01:28
morganfainbergsame way we capture localrc and the configs01:28
morganfainbergjust another log to upload01:28
ayoungthere is the wsgi app ,and httpd error logf01:29
ayoungI guess ^^ is the wsgi app01:29
ayoungso, yeah, we need httpd/error_log01:29
morganfainbergayoung, ++01:29
morganfainbergayoung, and if it's the same header issue / request length issue w/ compressed tokens01:29
ayoungOK,   it looks like [token] provider is left with the default value01:29
morganfainbergayoung, ... what is the next step?01:30
ayoungmorganfainberg, debugging this was a PITA as I recall01:30
ayoungI suspect all we will see in the HTTP log is "invalid header" or something like that01:30
morganfainbergwait you're seeing the provider as non PKIZ?01:30
morganfainbergoh oh right01:30
ayoungNo, provider is pkiz01:30
ayounggrep provider=01:30
*** dstanek is now known as dstanek_zzz01:30
morganfainbergsee it now01:31
ayoung#provider=keystone.token.providers.pkiz.Provider  but not overridden01:31
ayoungmorganfainberg, my guess is that somehow we are skipping the PKIZ code path01:33
morganfainbergayoung, well i have a VM here that i can do a PKIZ run on and see what happens.01:34
morganfainbergayoung, will be quicker than getting changes merged for config (for now)01:34
ayoungmorganfainberg, yeah, that is what I was going to suggest01:34
morganfainbergi'll review the default PKIZ patch while i'm running tempest01:34
ayoungmorganfainberg, I might be able to tell if they are PKIZ tokens from the logs01:35
morganfainbergthough i don't see anything wrong with it.01:35
ayoungmorganfainberg, do we log any tokens?01:35
*** ncoghlan is now known as ncoghlan_afk01:35
*** nsquare has quit IRC01:37
morganfainbergayoung, looks like it claims to be PKIZ01:38
morganfainbergayoung, also... doesn't look like it's compressing much01:38
ayoung "X-Auth-Token: PKIZ_01:38
*** ncoghlan_afk is now known as ncoghlan01:38
morganfainbergayoung, 3.4k with compression01:39
morganfainbergayoung, i think... compression isn't going to solve the catalog problem.01:39
ayoungthat should be small enough to fit through the headers01:39
morganfainbergayoung, is it aggregate headers size or per header01:40
morganfainbergayoung, it might be hitting an aggregrate size limit01:40
*** xianghui has joined #openstack-keystone01:40
ayoungno, just header01:40
morganfainbergwell give me a few restoring my VM so i can do a clean run.01:40
ayoungthere wasn't a problem until the headers hit 8k01:41
ayoungmorganfainberg, WHERE'd you find that token?01:41
morganfainbergayoung, http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/horizon_error.txt.gz01:42
morganfainbergit's not an error, but it shows we are hitting PKIZ code01:42
ayoung REQ: curl -i
ayoungwhat is 8776?01:42
ayoungits not keystone01:42
ayoung RESP: [200]01:42
morganfainbergit's nova01:43
morganfainbergbut it shows we are issuing PKIZ tokens01:43
morganfainbergthat is X-AUTH-TOKEN01:43
ayoungthis is not the same problem...01:43
ayoungnot the header size issue, I think01:43
morganfainbergwell, let me get my VM up and running01:43
morganfainbergoh ... i wonder01:45
morganfainberghave we exploded beyond XML capabilities?01:45
ayoung "tempest/services/identity/v3/xml/identity_client.py", line 522, in auth01:46
*** topol has joined #openstack-keystone01:47
ayoungthere is no line 521.   File "tempest/services/identity/v3/json/identity_client.py", line 521, in auth01:48
morganfainbergxml not json?01:48
ayoungmorganfainberg, and it is not a repo thing, either01:49
ayoungas the github and openstack repos agree01:49
ayoungI wonder if that error is in Keystone?01:49
morganfainbergwell i'll get the tempest run going ... ~30more seconds01:52
*** dstanek_zzz is now known as dstanek01:54
ayoungmorganfainberg, is it possible tempest is checked out from a branch?01:59
morganfainbergayoung, uhm shouldn't be for master01:59
morganfainbergayoung, i'm looking at the devstack gate code01:59
ayoungand there is only stable/havana01:59
ayoungmorganfainberg, ok,  last stack trace startshere02:01
ayoungFile "tempest/services/orchestration/json/orchestration_client.py", line 60, in create_stack02:01
hrybackiayoung: if there were no complaints after rebasing does that mean there were no conflicts?02:01
ayoung uri = 'stacks'02:02
morganfainbergayoung, running tempest now, as soon as I have a traceback i'll let you know02:02
ayounghrybacki, yes02:02
hrybackiayoung: huh. I thought for sure there would be something.02:02
morganfainberghrybacki, git is pretty smart02:02
ayounghrybacki, I'm kinda heads down, and about to head to bed02:02
ayoungmorganfainberg, so that looks like it is calling heat, right?02:03
hrybackiayoung: nods, take care02:03
hrybackimorganfainberg: apparently :)02:03
morganfainbergayoung, yeah that looks like a heat thing02:03
ayoungmorganfainberg, I wonder if somehow they missed the auth_token middleware update?02:03
ayoungOr...if they are doing something wonky with the tokens?02:04
morganfainbergayoung, how? it uses the latest release of ksc02:04
ayoungmorganfainberg, yeah, just ruminating02:04
morganfainbergayoung, remember we are also seeing direct failures in the identity scenarios02:04
morganfainbergeven though we can't figure out from where02:04
ayoungmight be in the heat log02:04
morganfainbergin fact, the first failure is an identity scenario failure02:05
*** ncoghlan is now known as ncoghlan_afk02:05
ayoung File "/opt/stack/new/python-keystoneclient/keystoneclient/v3/client.py", line 202, in get_raw_token_from_identity_service\n    \'%s\' % e)\n', u'AuthorizationFailure: Authorization failed: Internal Server Error (HTTP 500)\n'].02:05
ayoungfrom http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/screen-h-api.txt.gz02:05
ayoungso the problem seems to be in keystone02:05
*** sbfox has quit IRC02:06
morganfainbergayoung, yeah, that doesn't surprise me02:06
*** sbfox has joined #openstack-keystone02:06
ayoung Auth token not in the request header. Will not build auth context. process_request /opt/stack/new/keystone/keystone/middleware/core.py:27102:06
*** sbfox has quit IRC02:07
morganfainbergis that the ISE?02:07
ayoungmorganfainberg, time on that one was: [Mon Jun 16 22:36:08 2014]02:08
morganfainbergayoung, don't think that's it02:09
morganfainbergi se 2800 of those log lines02:09
morganfainbergin that log02:09
*** gordc has joined #openstack-keystone02:10
morganfainbergi thnk we print that anytime we don't have a token (including POST)02:10
morganfainbergfor auth02:10
*** ncoghlan_afk is now known as ncoghlan02:10
morganfainbergayoung, seeing this http://paste.openstack.org/show/84232/02:21
*** browne has quit IRC02:21
morganfainbergayoung, that is ceiliometer.02:21
ayoungmorganfainberg, hmmm, doesn't smell right02:22
ayoungmorganfainberg, is the system accessable?02:22
morganfainbergayoung, ?02:22
ayoungmorganfainberg, is it something I could log in to?02:22
ayoungif not, then02:23
morganfainbergthis is a VM on my laptop02:23
ayoungcurl http://localhost:35357/v2.0/certificates/signing02:23
*** marcoemorais has joined #openstack-keystone02:23
morganfainbergayoung, works fine02:24
ayoungmorganfainberg, are the files in /etc/keystone/ssl.... the same as the ones cached for ceilometer?02:24
ayoungmorganfainberg, what is  signing_dir set to for ceilometer?02:25
morganfainbergayoung, they are the same02:25
morganfainbergayoung /var/cache/celiometer02:25
ayoungmorganfainberg, permissions?02:25
morganfainbergstack/stack 60002:26
morganfainbergit is fine02:26
morganfainbergand i think i didn't see the same error as the gate run02:27
*** ncoghlan is now known as ncoghlan_afk02:27
morganfainbergi forgot to set apache to debug.02:28
ayoungmorganfainberg, I have to crash....02:28
ayoungI'll look into it tomorrow if you don't find a smoking guy02:28
morganfainbergayoung, yeah02:28
morganfainbergayoung, ssee ya later02:28
ayoungwatchout for the smoking man02:28
ayoungmorganfainberg, btw02:29
ayoungFile "/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py", line 1309, in _fetch_cert_file  is not what I have from master02:29
ayoung_fetch_cert_file is line 1461 in master02:29
*** ayoung is now known as ayoung_ZZZzzz02:30
morganfainbergayoung_ZZZzzz, i think if found it.02:32
*** lbragstad has quit IRC02:35
*** marcoemorais1 has joined #openstack-keystone02:35
*** marcoemorais has quit IRC02:37
*** praneshp has quit IRC02:41
morganfainbergayoung_ZZZzzz, [Mon Jun 16 18:41:21 2014] [error] [client] mod_wsgi (pid=28928): Exception occurred processing WSGI script '/var/www/keystone/main'.02:42
morganfainberg[Mon Jun 16 18:41:21 2014] [error] [client] TypeError: expected byte string object for header value, value of type unicode found02:42
*** leseb has joined #openstack-keystone02:42
*** ncoghlan_afk is now known as ncoghlan02:46
*** dstanek is now known as dstanek_zzz02:46
*** leseb has quit IRC02:46
*** sbfox has joined #openstack-keystone02:49
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889702:54
morganfainbergayoung_ZZZzzz, ^ added the str() coersion from the token cms call. unicode biting us again02:55
*** hrybacki has quit IRC02:56
*** ncoghlan is now known as ncoghlan_afk02:57
*** gordc has quit IRC03:00
*** ayoung_ZZZzzz has quit IRC03:00
*** hrybacki has joined #openstack-keystone03:00
*** stevemar has joined #openstack-keystone03:08
*** lbragstad has joined #openstack-keystone03:09
*** gordc has joined #openstack-keystone03:16
*** praneshp has joined #openstack-keystone03:19
*** praneshp_ has joined #openstack-keystone03:20
*** praneshp has quit IRC03:24
*** praneshp_ is now known as praneshp03:24
*** zhiyan_ is now known as zhiyan03:28
*** harlowja is now known as harlowja_away03:37
*** harlowja_away is now known as harlowja03:39
*** leseb has joined #openstack-keystone03:43
*** leseb has quit IRC03:47
*** dstanek_zzz is now known as dstanek03:47
*** daneyon has joined #openstack-keystone03:50
*** daneyon has quit IRC03:50
*** daneyon has joined #openstack-keystone03:51
*** dstanek is now known as dstanek_zzz03:57
*** sbfox has quit IRC04:04
*** hrybacki has quit IRC04:07
*** henrynash has joined #openstack-keystone04:17
*** sbfox has joined #openstack-keystone04:20
*** leseb has joined #openstack-keystone04:44
*** leseb has quit IRC04:48
*** gyee has quit IRC04:51
*** gordc has quit IRC04:53
*** dims has quit IRC04:58
*** stevemar has quit IRC04:58
*** stevemar has joined #openstack-keystone05:03
openstackgerritA change was merged to openstack/python-keystoneclient: Using six.u('') instead of u''  https://review.openstack.org/10008205:04
openstackgerritA change was merged to openstack/python-keystoneclient: Added help text for the debug option  https://review.openstack.org/9931205:06
*** ajayaa has joined #openstack-keystone05:06
*** ajayaa has quit IRC05:11
*** zhiyan is now known as zhiyan_05:20
*** ajayaa has joined #openstack-keystone05:24
*** stevemar has quit IRC05:25
*** stevemar has joined #openstack-keystone05:26
*** henrynash has quit IRC05:29
*** gmurphy has joined #openstack-keystone05:30
*** leseb has joined #openstack-keystone05:44
*** harlowja is now known as harlowja_away05:48
*** leseb has quit IRC05:49
*** ajayaa has quit IRC05:49
*** daneyon has quit IRC05:54
*** stevemar has quit IRC06:00
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/9700506:00
*** ajayaa has joined #openstack-keystone06:00
*** zhiyan_ is now known as zhiyan06:02
*** oomichi has quit IRC06:07
*** oomichi has joined #openstack-keystone06:17
*** sbfox has quit IRC06:26
*** topol has quit IRC06:31
*** afazekas_ has joined #openstack-keystone06:32
*** marcoemorais1 has quit IRC06:36
*** chandan_kumar has quit IRC06:38
*** leseb has joined #openstack-keystone06:45
*** tomoiaga has joined #openstack-keystone06:49
*** leseb has quit IRC06:50
*** BAKfr has joined #openstack-keystone07:04
tomoiagaI wonder if it's possible to initialize keystoneclient with an existing scoped token. It seems keystoneclient will start a new authentication request (generating a new token) even if I pass in an existing token07:05
*** leseb has joined #openstack-keystone07:06
*** leseb_ has joined #openstack-keystone07:08
*** leseb has quit IRC07:11
*** ncoghlan_afk is now known as ncoghlan07:16
*** henrynash has joined #openstack-keystone07:48
tomoiaga(since this is logged) found the solution after looking at the code. auth_ref needs to cached for my needs and passed to the client as a kwarg. It is also commented on the code :)07:51
jamielennoxtomoiaga: another way to do it would be to take the session object and pass that in next time07:52
jamielennoxor better yet construct the session first, then create multiple clients with that session07:52
tomoiagajamielennox: yes, I am using the session object, however I am running a django app and I can't save the session object for the next request (json serialization & stuff) unless I am missing something, I can only save auth_ref in a session for example and re-initialize with that on the next request from the same session07:53
tomoiagajamielennox: it's a good thing you post new stuff on your blog, it helps a lot, thanks! :)07:54
jamielennoxtomoiaga: it's a good thing i started posting that stuff at all - it's getting it out that's the issue07:54
jamielennoxinteresting - so i was expecting this to come up at some point but i wasn't aware anyone was using it yet07:55
jamielennoxso you are serializing the auth_ref?07:55
jamielennoxi've always expected that i need to provide a way to serialize an auth_plugin07:56
tomoiagajamielennox: I'm no expert, I am looking at hos to do this the best way. I just found that if I pass auth_ref (as a dict) to httpclient it will create the auth_ref object for me.07:57
jamielennoxyea, it will - but i consider that the 'old way', i just don't necessarily have a 'new way' yet07:58
jamielennoxtomoiaga: it would be fairly trivial to write your own plugin that just accepted an existing auth_ref, handle the serialization yourself07:59
tomoiagajamielennox: yes. I started to give the token to the main client that uses discovery, however without auth_ref there will always be a new auth post and I wanted to avoid that08:00
jamielennoxif you pass session there won't be an initial auth post08:00
tomoiagajamielennox: yes, I was just thinking of that :) I need to look at the other parts as well but I guess having my own plugin should do the trick.08:01
jamielennoxtomoiaga: look at https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/identity/base.py#L4808:05
jamielennoxif you override that the only function you need to provide is get_auth_ref08:05
jamielennox(you might want to override invalidate as well because i assume you can't fetch a new token on behalf of the user)08:05
*** xianghui has quit IRC08:16
*** gmurphy has quit IRC08:16
*** _elmiko has quit IRC08:16
*** amerine has quit IRC08:16
*** mfisch has quit IRC08:16
*** raildo has quit IRC08:16
*** tomoiaga has quit IRC08:16
*** Chicago has quit IRC08:16
*** thiagop has quit IRC08:16
*** d0ugal has quit IRC08:16
*** jdennis has quit IRC08:16
*** rushiagr has quit IRC08:16
*** morganfainberg has quit IRC08:16
*** harlowja_away has quit IRC08:16
*** mgagne has quit IRC08:16
*** dolphm has quit IRC08:16
*** mhu has quit IRC08:16
*** zigo has quit IRC08:16
*** zhiyan has quit IRC08:16
*** chmouel has quit IRC08:16
*** shufflebot has quit IRC08:16
*** uvirtbot has quit IRC08:16
*** boris-42 has quit IRC08:16
*** vhoward has quit IRC08:16
*** openstackgerrit has quit IRC08:16
*** jimbaker has quit IRC08:16
*** oomichi has quit IRC08:16
*** ajayaa has quit IRC08:16
*** lbragstad has quit IRC08:16
*** jamielennox has quit IRC08:16
*** henrynash has quit IRC08:16
*** afazekas_ has quit IRC08:16
*** praneshp has quit IRC08:16
*** mberlin1 has quit IRC08:16
*** dhellmann has quit IRC08:16
*** bobt has quit IRC08:16
*** rodrigods has quit IRC08:16
*** afazekas has quit IRC08:16
*** htruta has quit IRC08:16
*** tellesnobrega has quit IRC08:16
*** jkappert has quit IRC08:16
*** anteaya has quit IRC08:16
*** leseb_ has quit IRC08:16
*** BAKfr has quit IRC08:16
*** dtroyer_zz has quit IRC08:16
*** ekarlso has quit IRC08:16
*** arunkant has quit IRC08:16
*** ctracey has quit IRC08:16
*** baffle has quit IRC08:16
*** serverascode has quit IRC08:16
*** ChanServ has quit IRC08:16
*** toddnni_ has quit IRC08:16
*** ncoghlan has quit IRC08:17
*** huats has quit IRC08:17
*** dstanek_zzz has quit IRC08:17
*** gpocentek has quit IRC08:17
*** Mikalv has quit IRC08:17
*** comstud has quit IRC08:17
*** ByteSore has quit IRC08:17
*** esmute has quit IRC08:17
*** radez_g0n3 has quit IRC08:17
*** Daviey has quit IRC08:17
*** jaosorior has joined #openstack-keystone08:21
*** leseb_ has joined #openstack-keystone08:21
*** BAKfr has joined #openstack-keystone08:21
*** afazekas_ has joined #openstack-keystone08:21
*** oomichi has joined #openstack-keystone08:21
*** ajayaa has joined #openstack-keystone08:21
*** praneshp has joined #openstack-keystone08:21
*** lbragstad has joined #openstack-keystone08:21
*** mberlin1 has joined #openstack-keystone08:21
*** ncoghlan has joined #openstack-keystone08:21
*** dhellmann has joined #openstack-keystone08:21
*** vhoward has joined #openstack-keystone08:21
*** bobt has joined #openstack-keystone08:21
*** rodrigods has joined #openstack-keystone08:21
*** openstackgerrit has joined #openstack-keystone08:21
*** gpocentek has joined #openstack-keystone08:21
*** afazekas has joined #openstack-keystone08:21
*** huats has joined #openstack-keystone08:21
*** jimbaker has joined #openstack-keystone08:21
*** htruta has joined #openstack-keystone08:21
*** jamielennox has joined #openstack-keystone08:21
*** boris-42 has joined #openstack-keystone08:21
*** tellesnobrega has joined #openstack-keystone08:21
*** jkappert has joined #openstack-keystone08:21
*** anteaya has joined #openstack-keystone08:21
*** dtroyer_zz has joined #openstack-keystone08:21
*** arunkant has joined #openstack-keystone08:21
*** esmute has joined #openstack-keystone08:21
*** ekarlso has joined #openstack-keystone08:21
*** radez_g0n3 has joined #openstack-keystone08:21
*** Daviey has joined #openstack-keystone08:21
*** toddnni_ has joined #openstack-keystone08:21
*** ctracey has joined #openstack-keystone08:21
*** dstanek_zzz has joined #openstack-keystone08:21
*** baffle has joined #openstack-keystone08:21
*** comstud has joined #openstack-keystone08:21
*** serverascode has joined #openstack-keystone08:21
*** Mikalv has joined #openstack-keystone08:21
*** ByteSore has joined #openstack-keystone08:21
*** ChanServ has joined #openstack-keystone08:21
*** dickson.freenode.net sets mode: +o ChanServ08:21
*** tomoiaga has joined #openstack-keystone08:22
*** gmurphy has joined #openstack-keystone08:22
*** xianghui has joined #openstack-keystone08:22
*** _elmiko has joined #openstack-keystone08:22
*** harlowja_away has joined #openstack-keystone08:22
*** raildo has joined #openstack-keystone08:22
*** Chicago has joined #openstack-keystone08:22
*** amerine has joined #openstack-keystone08:22
*** mgagne has joined #openstack-keystone08:22
*** mfisch has joined #openstack-keystone08:22
*** thiagop has joined #openstack-keystone08:22
*** d0ugal has joined #openstack-keystone08:22
*** jdennis has joined #openstack-keystone08:22
*** rushiagr has joined #openstack-keystone08:22
*** dolphm has joined #openstack-keystone08:22
*** mhu has joined #openstack-keystone08:22
*** zhiyan has joined #openstack-keystone08:22
*** zigo has joined #openstack-keystone08:22
*** shufflebot has joined #openstack-keystone08:22
*** chmouel has joined #openstack-keystone08:22
*** uvirtbot has joined #openstack-keystone08:22
*** dickson.freenode.net sets mode: +o dolphm08:22
*** morganfainberg has joined #openstack-keystone08:22
*** dickson.freenode.net sets mode: +o morganfainberg08:22
*** d0ugal has quit IRC08:24
*** d0ugal_ has joined #openstack-keystone08:24
*** d0ugal_ is now known as d0ugal08:25
*** d0ugal has quit IRC08:25
*** d0ugal has joined #openstack-keystone08:25
tomoiagajamielennox: it seems to be working like a charm, thank you again :)08:26
jamielennoxtomoiaga: excellent - no problem08:27
*** mfisch` has joined #openstack-keystone08:27
*** mfisch has quit IRC08:27
*** _elmiko has quit IRC08:27
*** _elmiko has joined #openstack-keystone08:31
*** xianghui has quit IRC08:33
*** gmurphy has quit IRC08:33
*** amerine has quit IRC08:33
*** raildo has quit IRC08:33
*** tomoiaga has quit IRC08:33
*** Chicago has quit IRC08:33
*** thiagop has quit IRC08:33
*** jdennis has quit IRC08:33
*** rushiagr has quit IRC08:33
*** harlowja_away has quit IRC08:33
*** mgagne has quit IRC08:33
*** dolphm has quit IRC08:33
*** mhu has quit IRC08:33
*** zigo has quit IRC08:33
*** zhiyan has quit IRC08:33
*** chmouel has quit IRC08:33
*** shufflebot has quit IRC08:33
*** uvirtbot has quit IRC08:33
*** mfisch` has quit IRC08:35
*** mfisch has joined #openstack-keystone08:35
*** mfisch has quit IRC08:35
*** mfisch has joined #openstack-keystone08:35
*** praneshp has quit IRC08:37
*** jimbaker has quit IRC08:38
*** tomoiaga has joined #openstack-keystone08:43
*** gmurphy has joined #openstack-keystone08:43
*** xianghui has joined #openstack-keystone08:43
*** harlowja_away has joined #openstack-keystone08:43
*** raildo has joined #openstack-keystone08:43
*** Chicago has joined #openstack-keystone08:43
*** amerine has joined #openstack-keystone08:43
*** mgagne has joined #openstack-keystone08:43
*** thiagop has joined #openstack-keystone08:43
*** jdennis has joined #openstack-keystone08:43
*** mhu has joined #openstack-keystone08:43
*** zhiyan has joined #openstack-keystone08:43
*** zigo has joined #openstack-keystone08:43
*** shufflebot has joined #openstack-keystone08:43
*** chmouel has joined #openstack-keystone08:43
*** uvirtbot has joined #openstack-keystone08:43
*** dolphm has joined #openstack-keystone08:43
*** rushiagr has joined #openstack-keystone08:43
*** dickson.freenode.net sets mode: +o dolphm08:43
*** jimbaker has joined #openstack-keystone08:47
*** jimbaker has quit IRC08:47
*** jimbaker has joined #openstack-keystone08:47
*** leseb has joined #openstack-keystone08:49
*** leseb_ has quit IRC08:52
*** andreaf has joined #openstack-keystone08:55
*** jimbaker is now known as 77CAADFPS08:55
*** leseb_ has joined #openstack-keystone08:57
*** henrynash has joined #openstack-keystone09:01
*** leseb has quit IRC09:01
*** openstackgerrit_ has joined #openstack-keystone09:08
*** leseb_ has quit IRC09:11
*** leseb has joined #openstack-keystone09:15
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Document authentication plugins  https://review.openstack.org/8407109:17
*** leseb has quit IRC09:18
*** ncoghlan has quit IRC09:21
*** leseb has joined #openstack-keystone09:25
*** dims_ has joined #openstack-keystone09:27
openstackgerritSteven Hardy proposed a change to openstack/keystone-specs: Spec for trusts redelegation  https://review.openstack.org/9990809:27
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session Adapters  https://review.openstack.org/8623709:27
openstackgerritSteven Hardy proposed a change to openstack/keystone-specs: Spec for trusts redelegation  https://review.openstack.org/9990809:29
*** dims_ has quit IRC09:32
*** Gippa has joined #openstack-keystone09:34
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add oslo-incubator fixtures  https://review.openstack.org/10047009:51
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session Adapters  https://review.openstack.org/8623710:10
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Implement SAML2 ECP authentication  https://review.openstack.org/9216610:11
*** openstackgerrit_ has joined #openstack-keystone10:15
*** leseb has quit IRC10:17
*** leseb has joined #openstack-keystone10:17
*** leseb has quit IRC10:22
*** Gippa has quit IRC10:27
*** topol has joined #openstack-keystone10:32
*** Chicago has quit IRC10:56
*** dims_ has joined #openstack-keystone11:09
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Always use sha1 for cross backend unique identifiers  https://review.openstack.org/10049711:13
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Always use sha1 for cross backend unique identifiers  https://review.openstack.org/10049711:18
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Always use sha1 for cross backend unique identifiers  https://review.openstack.org/10049711:19
*** diegows has joined #openstack-keystone11:38
*** nikunj2512 has joined #openstack-keystone11:47
nikunj2512I need some help regarding keystone api11:55
*** nikunj2512 has quit IRC12:00
*** AndChat|89889 has joined #openstack-keystone12:00
AndChat|89889Hi..  I need some help with Keystone api..12:01
AndChat|89889I am implementing email update in the horizon UI and need help with Keystone V2 api12:03
*** juanmo has joined #openstack-keystone12:07
*** dims_ has quit IRC12:13
*** leseb has joined #openstack-keystone12:40
*** leseb has quit IRC12:43
*** leseb has joined #openstack-keystone12:43
*** Gippa has joined #openstack-keystone12:44
*** joesavak has joined #openstack-keystone12:51
*** gordc has joined #openstack-keystone12:54
*** _elmiko is now known as elmiko12:56
*** bknudson has joined #openstack-keystone12:57
*** bknudson has left #openstack-keystone12:58
*** bknudson has joined #openstack-keystone12:58
*** radez_g0n3 is now known as radez13:06
*** dstanek_zzz is now known as dstanek13:09
marekdmorganfainberg: hello. As long you guys are not meeting at my 3am I  should be able to join :-)13:11
*** richm has joined #openstack-keystone13:11
*** ayoung has joined #openstack-keystone13:15
*** erecio has joined #openstack-keystone13:17
*** zhiyan is now known as zhiyan_13:17
*** AndChat|89889 has quit IRC13:19
joesavakyo marekd!13:23
marekdjoesavak: hey!13:23
joesavakwe're meeting in about 90 minutes (10a central) to discuss federation again13:23
marekdjoesavak: that's great, I will be online :-)13:24
marekdjoesavak: i did see yesterday's convo.13:24
joesavakYeah, sorry about the bad formatting.13:24
marekdjoesavak: no worries, I just scrolled up my IRC client :-)13:24
joesavakIt didn't resolve much but after speaking to Jorge, we think we know where the concern is13:24
marekdjoesavak: cool.13:26
*** jcromer has joined #openstack-keystone13:26
*** nkinder has joined #openstack-keystone13:30
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889713:30
openstackgerritayoung proposed a change to openstack/keystone: pkiz String conversion  https://review.openstack.org/10054513:30
ayoungjoesavak, marekd please include me in these discussions.  It will save you much grief in the long term13:31
ayoungI've kindof been working through the issues on Federation since I started on this project, and I think there are aspects you have not considered13:31
marekdayoung: sure13:31
joesavakayoung - sweet! All convo, including next meetings is being captured in the review. Anyone and everyone welcome.13:32
marekdjoesavak: ++13:32
ayoungjoesavak, I've been reading through it.13:33
ayoungjoesavak, #openstack-meeting?13:33
joesavakright here. ;)13:33
marekd#openstack-federation :D13:34
joesavaky'all want to do that? may make sense to not create much noise in here13:34
marekdjoesavak: i was kidding, but have no issue with a different channel.13:34
ayoungNo, keep it here13:34
ayoungFederation is core to Keystone13:35
joesavakcool. Here it is.13:35
ayoungmorganfainberg, when you wake up...I split out your change for the str conversion in the PKIZ token provider to its own patch.13:37
ayoungjamielennox, if you are still awake:  https://review.openstack.org/#/c/100545/1  is pretty trivial in scope13:40
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907613:52
*** nikunj2512 has joined #openstack-keystone13:55
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9626513:56
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421413:58
*** dims has joined #openstack-keystone13:58
*** hrybacki has joined #openstack-keystone13:59
*** dims has quit IRC13:59
*** ajayaa has quit IRC13:59
*** stevemar has joined #openstack-keystone14:02
*** dims has joined #openstack-keystone14:07
*** tomoiaga has quit IRC14:09
openstackgerritA change was merged to openstack/keystone-specs: Remove template from juno approved specs  https://review.openstack.org/10031014:09
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Convert auth_token to use session  https://review.openstack.org/7490814:11
*** juanmo1 has joined #openstack-keystone14:13
*** juanmo has quit IRC14:15
*** erecio has quit IRC14:15
*** Gippa has left #openstack-keystone14:15
hrybackiayoung: just to clarify, you want me to rebase my commit with https://review.openstack.org/#/c/74908/ yes?14:15
ayounghrybacki, yeah.  here's the deal14:16
*** erecio has joined #openstack-keystone14:16
ayoungthe auth_token code is doing too much14:16
ayoungthe "Session" that jamie wrote handles much of the common logic for anything tlaking to keystone14:16
*** zhiyan_ is now known as zhiyan14:16
ayoungin this case, you need it to provide some access to the 'client'14:16
ayoungonce you have the client object, you can call on the API14:17
ayounghrybacki, I rebased his changes, and will beat the other devs  up about getting it merged14:17
ayoungas you can see, there is a lot in motion here, so it is a tough to stay on top of what goes where14:18
hrybackimakes sense, auth_token was kind of a gorilla14:18
baffleHow do I use the v3 Keystone API from the various command line utilities? I.e. either the new "openstack" utility, or "nova" "keystone" "glance" etc. I.e. what variables do I set? And do I need to configure anything in particular in keystone/the catalog? Horizon uses v3 directly, and it works great with domains.14:18
baffle(Basically, do I need to specify V3 in catalog, and what special variables should I set in my .openrc) :-)14:19
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: pkiz String conversion  https://review.openstack.org/10054514:21
morganfainbergayoung, that was a painful debug btw14:22
ayoungmorganfainberg, thanks for slogging through it14:23
ayoungmorganfainberg, please +1 the patch I submitted in your name14:23
henrynashjoesavak: is there a draft spec for k2k federation?14:24
*** ericvw has joined #openstack-keystone14:24
*** rwsu has joined #openstack-keystone14:24
hrybackiayoung: simplest way to rebase against 74908 simply to git review it, checkout my feature branch and 'git rebase <74908 branch>'?14:25
joesavakyup! https://review.openstack.org/#/c/100023/14:25
joesavakhenrynash ^^14:25
henrynashjoesavak: ta14:25
morganfainbergayoung, ++14:25
ayounghenrynash, oh, come on14:25
ayoung  should be in your bookmarks by now!14:25
* ayoung admits he just added it14:25
* joesavak just added it too14:26
henrynashayoung: :-) but I didn’t see Joe’s there....14:26
*** elmiko has left #openstack-keystone14:26
ayoungITS THE FIRST ONE!14:27
ayounghenrynash, BTW...do you have a new version of your patch anywhere ready to go>14:27
ayoungthe multip backend patch14:27
henrynashayoung: just posted14:27
* ayoung needs to cut back on caffeine14:27
henrynashayoung: teh only issue is that it has the migration of ID gernation from controller to manager in it….so lots of additional unit test changes….we need to decide if we split it up (a bit tiresome) or swallow it whole14:28
ayounghenrynash, +2223, -1147that is hefty.  Whew14:28
ayounghenrynash, looking nowe14:28
henrynashayoung: yep, that’s all the unit test changes (all mechanical, but lots of them)14:29
ayoungnkinder, BTW ^^ is the single most important patch for us.  Please spend some time on it as well.14:29
ayounghenrynash, I see a bunch of new_group = {'domain_id': domain1['id'], 'name': uuid.uuid4().hex}14:30
ayoung        new_group = self.identity_api.create_group(new_group)14:30
ayoungand I think you meant to remove to top line14:30
morganfainbergayoung, ...14:30
morganfainberghow.. did you get gerrit wedged up and in a circular dependency?14:30
ayoungDid I...hmm, did it not give your change a new changeid14:31
henrynashayoung: no…it’s ‘caue the manager now generates the ID14:31
ayoungmorganfainberg, what is the circular?14:31
ayounghenrynash, sorry, two convos at once14:32
ayounghenrynash, I see what you are doing,14:32
morganfainbergayoung, oh nvm14:32
henrynashayoung: ah…14:32
morganfainbergayoung, was mis-reading sorry.14:32
ayoungmorganfainberg, are you using the new view?  It does report it differently14:33
ayoung"Related reviewas" which shows itself14:33
morganfainbergayoung, yeah it got into the new view somehow.14:33
morganfainbergayoung, i fixed it by going back to the old veiw (cookie issue or something)14:33
morganfainberghttps://review.openstack.org/#/c/98897/ please click rebase14:33
ayoungI kind prefer the new14:33
ayoungmorganfainberg, no rebase available14:34
*** juanmo1 has quit IRC14:34
morganfainbergsays it depends on an outdated patchset14:34
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889714:34
morganfainbergthere we go14:34
ayoungmorganfainberg, yeah...again an old-new view thing14:34
ayoungthere was no rebase button on the new view.  went to the old and saw it14:35
morganfainbergnever thought gerrit could have a worse ux than it already had14:35
morganfainbergthen i saw the new view14:35
*** zhiyan is now known as zhiyan_14:35
morganfainbergayoung, thanks for splitting the str thing out14:35
*** zhiyan_ is now known as zhiyan14:36
*** BAKfr has quit IRC14:36
ayounghenrynash, can you do a quickie code review?    https://review.openstack.org/#/c/100545/214:36
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889714:36
henrynashayoung: yep, looking14:36
morganfainbergayoung, ^ fixed a couple typos in your commit message14:36
morganfainbergayoung, (gerrit web interface being able ot change the commit message is win)14:37
*** zhiyan is now known as zhiyan_14:37
*** i159 has joined #openstack-keystone14:37
*** zhiyan_ is now known as zhiyan14:37
ayoungmorganfainberg, ++14:38
morganfainbergayoung, as soon as your compress token change default lands...14:38
morganfainbergi get to propose making one of the gate jobs use apache!! :)14:38
ayoungmorganfainberg, and then the screaming commences14:39
*** juanmo has joined #openstack-keystone14:39
*** Benj__ has joined #openstack-keystone14:39
morganfainbergayoung, haha, i'm hoping it'll be clean and solid enough to switch the default in devstack by the end of J14:39
*** CptE has joined #openstack-keystone14:39
morganfainbergbobt, i think i fixed your concerns in the commit message for the PKIZ token default patch, ^14:40
Benj__Hey peeps, I've just started working on the keystone client (as part of my MSc dissertation) and was wondering if you'd tolerate some noob questions from time to time?14:43
ayoungBenj__, you are a brave brave man14:43
ayoungor owman14:43
ayoungor woman14:43
ayoungdon't want to prejudge14:43
morganfainbergBenj__, awesome! welcome on board :) and yes, ask away14:44
Benj__brave for being here or brave for looking at Keystone CLI?14:44
ayoungBenj__, BTW, hrybacki is pretty much in the same boat14:44
ayoungBenj__, there is no CLI14:44
ayoungthe CLI is a figment14:44
morganfainbergayoung, shush. :P14:44
ayoungOK,  the CLI is going away, and we are trying to get people to focus on the common CLI14:44
morganfainbergBenj__, you'll also want to talk with stevemar and dtroyer_zz for openstack common cli14:45
ayoungthe keystoneclient code is going to stay around as a library14:45
bknudsonthere's also a push to get a common SDK -- openstack-sdk14:45
ayoungBenj__, so... yeah, brave for wading out into a rushing river, but welcome.  And please, ask away.14:46
ayoungbknudson, think that is ever going to happen?14:46
morganfainbergbknudson, i never fully understood their goal - it sounded like tey wanted somethingbut not what the current clients did? i should go re-read what their goals are14:46
bknudsonayoung: I doubt it's ever going to happen14:46
ayoungbknudson, that is my take, too14:46
bknudsonmorganfainberg: their goals seem to change.14:46
morganfainbergayoung, if it supplants the clients completely, i hope it does14:46
morganfainbergayoung, but i'm with bknudson, i don't think it's going to in the near term (dunno about any term)14:47
ayoungBenj__, so, what specifically are you looking at?14:47
bknudsonI would be fine if it did happen, but it's a big project if they want to really reimplement all the clients14:47
Benj__so is the python-keystoneclient on GitHub going away? https://github.com/openstack/python-keystoneclient14:47
bknudsonand that seems to be all they're doing14:47
ayoungBenj__, no14:47
ayoungBenj__, that is going to stay as the keystone library14:47
ayoungjust eh CLI aspect will get rolled into the common CLI14:47
ayoungTHe Common SDK is a pipedream14:48
ayoungand that pipe is stuffed with something very potent14:48
Benj__oh, man... pandora's box or what14:48
bknudsonmaybe with Benj__'s help it'll get done14:48
ayoungBenj__, so...what are you looking at?  Just getting involved, or something specific?14:48
jcromeri just had to use the common client to create domain and domain admin user for use with heat14:49
ayoungjcromer, HEat is making CLI calls, or was that for a setup script?14:49
*** alligator has joined #openstack-keystone14:49
ayoungjcromer, I'm a bash guy, but I've started to switch over to using python calls for that kind of stuff14:49
Benj__please don't hold your breath! Anyway, I'm implementing federated login using an API written by the university here14:49
ayoungBenj__, AH...Fedration14:50
Benj__yes... MIGHTY federation14:50
ayoungOK, so there is a lot of sturm-unt-drang about that right now.  There is a spec ...14:50
ayoungBenj__, 2 things14:51
Benj__well... I'm HORRIBLY confused with the big "this is being deprecated" message in the docstrings of the shell.py script in the python-keystoneclient that I forked on gitHub14:51
hrybackiBenj__: welcome, heh. Hope you bought coffee and headache meds.14:51
*** thedodd has joined #openstack-keystone14:51
jcromerayoung, in icehouse heat auth model changed and requires keystone domain which i couldn't create with the pythonclient14:51
morganfainbergmarekd, glad you're going to be around for the convo.14:51
jcromerayoung, http://hardysteven.blogspot.com/2014/04/heat-auth-model-updates-part-2-stack.html14:52
ayoung1.  Remember that Openstack is not just designed fro interactive work, but rather that it needs to do automated (scripted) taks first and foremost.  SAML has some issues around that14:52
Benj__young yeah, that's SAML. Kent's API uses modules for protocol independence, so a little different.14:52
marekdmorganfainberg: sure.14:52
ayoungBenj__, heh14:52
morganfainbergmarekd, i figured you would be (you're usually online around the time we discussed) - worst case i figured we'd have to discuss a couple times (heck, wasn't sure who'd be around and how many times we'd have conversations)14:53
nikunj2512How can I use the Keystone V2 api to change the email address for non admin users?14:53
ayoungI think I was discussion that with dchadwick 3 years ago now.  He's part of our design community, and the common approach is based off his proof-of-concept14:53
morganfainbergnikunj2512, i believe V2 requires an admin to make that change14:54
morganfainbergnikunj2512, so an admin would need to update the user's email.14:54
ayoungBenj__, what protocol do you need? SAML, or openid connect?  Something else?14:54
nikunj2512Ok..  Because I am able to do this using v3 api14:54
morganfainbergnikunj2512, v2 api is more restrictive, it only has the concept of is_admin and is_not_admin really14:55
dstanekjust finished reading the keystone-to-keystone-federation spec and i'm a bit confused - is that meeting still happening today?14:55
Benj__the protocol isn't that important to me right now, I'm trying to add the federated option to the keystone client and am a little confused if i'm okay to work on the aforementioned git repo14:55
morganfainbergdstanek, yes it is14:55
marekdmorganfainberg: the time chosen is not that bad :P14:55
marekddstanek: happening in few minutes.14:55
marekddstanek: but it's the joesavak who chairs here.14:55
nikunj2512Ok..  The k14:55
nikunj2512Ok..  Thank You morganfainberg14:56
morganfainbergnikunj2512, happy to help14:56
morganfainbergdstanek, marekd, i also asked nkinder to take a look at it when he had some time.14:56
marekdmorganfainberg: saw it, it's great!14:56
dstanekpre question then - it mentions that we already have a keystone->service_provider trust relationship. that's just implicit right?14:57
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907614:57
*** dims_ has joined #openstack-keystone14:57
morganfainbergdstanek, that is explicitly setup14:57
morganfainbergdstanek, it isn't clear in the current spec.14:58
dstanekmorganfainberg: the spec says we already have that14:58
morganfainbergdstanek, it's part of why we're having a deeper conversation so the spec can be made more clear14:58
ayoungBenj__, there is also https://review.openstack.org/#/c/92166/  for the ECP extension, which I think is essential to the non-GUI  use cases14:58
morganfainbergdstanek, yeah it's supposed to be afaict (from the convo yesterday) explicitly configured as part of the setup with this spec14:59
morganfainbergline 164 - "resister the SP"14:59
joesavakhowdy howdy -14:59
*** jorgew has joined #openstack-keystone14:59
marekdjoesavak: hi!14:59
morganfainbergjoesavak, allo there14:59
*** htruta has quit IRC14:59
ayoungBenj__, as for being protocol agnostic, I'd argue it is petter to think in terms of "common to Federation" vs "specific to my protocol"  as that is how we are designing things14:59
morganfainbergjorgew, welcome welcome14:59
jorgewHey guys!15:00
ayoungso, if you want to work with SAML, or OpenID connect, there are other people looking at that now that you can work with15:00
Benj__ayoung, thanks I'll take a look15:00
joesavakalrighty - so continuing from yesterday - same kind of concerns15:00
morganfainbergayoung, about to talk about that spec. fyi15:00
ayoungBenj__, there is also some discussion of Keystone to Keystone15:00
morganfainbergBenj__, ayoung, actually... going to start that now ;)15:00
marekdmorganfainberg: ++15:00
ayoungand that is a whole new canball of wax-worms15:00
joesavak#link: http://paste.openstack.org/show/84236/15:00
joesavak#link: https://review.openstack.org/#/c/100023/315:01
dstanekjoesavak: from reading the spec i don't understand the flow of the token. who issues it and how it's validated..15:01
*** dims has quit IRC15:01
joesavakgotcha. So let's discuss that first15:01
ayoungjoesavak, just to be clear, are we focusing on Keystone to Keystone?15:01
joesavakayoung - yes15:01
morganfainbergjoesavak, dstanek's point is my big concern.15:01
ayoungjoesavak, OK, I move we abbreviate that to K2K15:01
rodrigodsjoesavak, stevemar hey... my team was taking a look at keystone-to-keystone federation, and we really want to part of the spec/dev efforts. i think the first step is to be present at the meetings, right? =)15:01
rodrigodsayoung, ++15:01
marekdrodrigods: ++15:02
jorgewjoesavak,  Do you mind if I talk about the token flow?15:02
joesavakjorgew - go for it.15:02
ayoungjorgew, first, we need a use case.15:02
joesavakLet's focus on use case 1 first15:02
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9626515:02
morganfainbergstevemar, ping ^^15:02
joesavakline 45 of the spec15:02
stevemarmorganfainberg, thanks for the heads up15:02
joesavakayoung ++ for k2k15:03
morganfainbergstevemar, yeah didn't want ya to miss out on the convo15:03
joesavakrodrigods,  yes - meetings and commenting on the spec/reviews would be good too!15:03
ayoungjoesavak, OK,  so The goal of this usecase is to enable one organization to have a common set of authorization decisions across multiple clouds15:03
joesavakayoung, yes15:04
jorgewjoesavak,  I think we have a usecase missing in the spec, which I mentioned last time.  Which is the case where the provider doesn't necessary want the user to know that bursting is occurring :-)15:04
rodrigodsjoesavak, great15:04
ayoungjoesavak, OK,  a couple things to keep in mind15:04
*** chandan_kumar has joined #openstack-keystone15:04
ayoungpolicy is going to vary from cloud to cloud.  Not today, but eventually15:04
ayoungwhich means that roles will have to be remapped15:04
marekdayoung: ++15:04
joesavakjorgew - good point. I'll add it in there. It's implied but not explicit15:04
ayoungso what is "_member_" in cloud 1  might be "user" in cloud 215:04
ayoungjoesavak, but...15:04
ayoungyou don't want to have to redefine that mapping for each project15:05
jorgewayoung, correct role mapping should occur.15:05
ayoungand that means we need to extend the mapping mechanism to "split and join"15:05
marekdplease, let jorgew talk about the workflow.15:05
ayoungMy shorthand is15:05
ayoungR1P1 means Role 1 on Project 115:05
rodrigodsayoung, jorgew who would define this mapping? what if cloud 2 changes from 'user' to 'dev', would be something manual?15:05
*** CptE has quit IRC15:05
ayoungso R1P1 in cloud 1  needs to be mapped to R2P2 in cloud 215:05
joesavak#topic: overall flow15:06
ayoungrodrigods, yes, manual, but should be small impact15:06
joesavakI'd like to table mapping right now15:06
joesavakjust to set a baseline of the flow15:06
morganfainbergayoung, yep, lets circle up on that once we have the basic workflow discussed15:06
ayoungjoesavak, fair enough15:06
joesavakgo for it jorgew. : )15:06
jorgewOkay, there are two keystone one provides the identity (IDP keystone) one provides services (SP keystone)15:07
ayoungservices meaning tokens?15:07
jorgewOut of band there is a relationship established between both keystone…keys are exchange…roles (and possibly tenants, and domains) are mapped.15:07
ayoungIE:  assigned users to roles?15:07
ayoungjorgew, BTW, are you assuming that we've split Keystone into these two pieces, as we discussed at the summit?15:08
jorgewayong, well let me reword. One cloud provides identity…the other cloud provides services like compute or object store.15:08
jorgewThe keystone that belongs to that cloud is the SP keystone15:09
jorgewayoung, Not assuming that now15:09
ayoungjorgew, just to be clear, you are still planning on using tokens for identity.  I think that might be a fatal flaw15:09
ayoungjorgew, I would prefer to say that tokens are authorization data only15:09
ayoungand identity is carried on some cryptographically secure mechanism15:09
dstanekjorgew: when you say provides services you mean does authz for the services in that cloud right?15:09
jorgewayound,  okay tokens == authorization data.15:10
morganfainbergjorgew, ayoung, ++ tokens being authz data only is how i always viewed it15:10
jorgewdstanek, when I say a cloud provides services to another cloud I mean services like compute or object store.15:10
ayoungjorgew, so if Keystone tokens are authorization data, then Fedration is built on coupling SAML or X509 with A Keystone token15:11
ayoungI don't know if Kerberos is a viable solution there or not, but I'd like it to be15:11
jorgewmorganfainberg, ayoung — that said the authorization data may be opague to the services :-)15:11
jorgew…so you can still think it as a token.15:12
dstanekjorgew: so a client would talk to the keystone directly for compute instead of going to that cloud's nova?15:12
ayoungSo, to me, the flow would be:  1 go to IdP SAML, get SAML assertion, present it to Keystone 1,  then, go to Keystone 2, and present SAML and token from K1, get token from K215:12
jorgewOkay hold on guys…let me describe the flow and then you can throw rocks at it :-)15:12
henrynashorder, order...15:12
morganfainbergjorgew, please continue15:12
stevemarsave questions for 5 minutes from now15:13
ayoungjorgew, there is an alternative.  We can build a PKI mechanism in to the token, and sign some portion of the requests used with that token with the Private key.  That was suggested long ago, and is more complex than I think we want to do15:13
morganfainbergayoung, hold up.15:13
jorgew…So anyway, through some magic a relationship is established between IDP keystone and SP keystone.15:13
morganfainbergayoung, let jorgew continue with the current proposal15:13
jorgew…and mapping occurs.15:13
jorgewUser logs in to IDP keystone.15:14
jorgewBear with me here: the user gets a token (which may be PKI or not) and gets a service catalog15:14
jorgewThat catalog will contain endpoints in IDP cloud…but can also contain endpoints in SP cloud15:14
jorgewThe user can send a request to SP cloud endpoint15:15
jorgewThrough some yet to be defined magic, SP middleware can detect that token is not local15:15
jorgewsends validate token request to SP keystone15:15
ayoungjorgew, to be clear, the must go to SP keystone to get a token?15:16
jorgewSP keystone is aware of mappings nessesary so sends response to middle ware with appropriate roles, tenant, domain etc15:16
ayoungor direct to nova?15:16
jorgewayoung, no token comes from IDP keystone…is validated by SP keystone based on mapping15:16
jorgewayong, so the same token is used.15:16
joesavakcontinue to gather rocks for a bit. : )15:17
jorgewayoung, but the response to validate token may vary form one cloud to another.15:17
jorgewThe idea is that the bursting is transparent to the client..she just sees another endpoint15:17
jorgewThe orchestration between SP keystone and IDP keystone will involve the same mechanism we currently use for federation, but that's hidden from the user.15:18
jorgewWe can cache tokens to avoid going back to IDP keystone for every request.15:18
jorgewokay…that's it..15:18
marekdjorgew: 1) how does it scale? the service catalog can grow, what morganfainberg or ayoung thing about it regarding all the efforts for squeezing the token? And I am talking about fedration of..say 50 clouds? 2) If you want to hide federated workflow from the user...K2 would act on behalf of the user?15:18
joesavak#topic scaling15:19
marekdjoesavak: thank you15:19
ayoungjorgew, hold on15:19
ayoungscaling can wait15:19
ayounglets talk correctness first15:19
jorgewayong, okay shoot.15:19
joesavak#topic correctness(sp)?15:19
ayoungthere are a couple ways we could make this happebn15:20
ayoungthe first question is "can Nova trust multiple keystones"15:20
ayoungif the answer is yes, then the question is "how do we divvy up responsibility"15:20
marekdayoung: i think it shouldn't.15:20
marekdin that case.15:20
ayoungmarekd, hold on15:20
ayoungLets say that Keystone Service is the arbiter15:20
jorgewayoung,  I see it slightly differently.  Nova trusts it's local keystone and the question is can that keystone trust other keystones.15:20
morganfainbergmarekd, i am in the same boat, but waiting for the whole set of questions15:20
ayoungand it can make a decision that KIdP is allowed to sign for tokens from domain X15:21
ayoungand only domain X15:21
ayoungnow, when a token comes in for something for domain X,  look at who signed it15:21
ayoungif it was KIdP, then it is OK15:21
ayoungno need to go back to Keystone for each validation15:21
ayoungonly the first time a decision about a foreign token is made15:22
ayoungso, the question is, what Keystone can sign for what data15:22
ayoungwe can inspect the token and pull out the signing data15:22
marekdayoung: i can see a big difference between hosting guests in my appartment and letting them sleep with me in my bed. Do you want your nova to trust and do whatever a foreign Keystone tells it to do?15:22
ayoungand based on that, deduce which keystone signed it15:23
ayoungmarekd, there is no Foreverm, there is only "cache window"15:23
ayoungmarekd, The local Keystone is still the arbiter15:23
marekdayoung: OK!15:23
ayoungit says which beds are available15:24
morganfainbergmarekd, this is more of a "you can sleep on my guest bed, but not mine" if i read it correctly15:24
dstanekhmmm...i need to draw this out15:24
ayoungmarekd, there are other issues:  what if the token talks a bout a project that does not exist15:24
jorgew Keep in mind that the roles that SP nova sees may be mapped  not nessensarly the same roles.  You can control via mapping what roles can be added for whatever mapping you create.  So you can place controls on what access is allowed as you build relationships.15:24
ayoungjorgew, right.15:24
marekdayoung: this in my next concern. that's why i should the token eventually should always be issued by a keystone from that particlar cloud.15:25
ayoungjorgew, so the question there is where should the mapping happen15:25
jorgewayoung,  projects need to be mapped…possibly prefixed by service provider id to avoid clashes.15:25
ayoungjorgew, so I kindof think that the user needs to go to keystone, get a token, hand that to another keystone, and get an appropriate token15:25
jorgewayoung, my thought on mapping is that it happens when the relationship is first built…and it occurs at the SP keystone.15:26
marekdayoung: that's how i see it!15:26
ayounginstead of handing off tokens to nova and making keystone15:26
ayoungmaking nova contact keystone each time15:26
marekdayoung: i think all the burden of trusts, relationships, mapping(!) should be on the Keystone.15:26
morganfainbergmarekd, i see it slightly differently, but same basic concept (sans keystone token, more SAML or openid or other federation tech, but same basic concept)15:26
ayoungNova should not be requesting tokens on behalf of a foreign user15:26
ayoungjorgew, so, some other things we need to keep in mind15:27
ayoungcurrently, any token can be handed in for any other token for the same user15:27
jorgewayoung,  the problem with that approach is that it doesn't meet the criteria of using the same tools etc.  or the usecase of hiding the bursting from the user.15:27
ayoungthuis means the the trust would implicity be two directional, and this is a security nightmare15:27
ayoungwe need to lock down the "direction" of token2token exchanges15:27
ayoungjorgew, who is making the bursting decision?15:28
jorgewayoung,  trust should not be two directional, we made that explicit in the spec, so agree that we would have to lock that down.15:28
ayoungI would think  nova15:28
dstanekjorgew: here's the way i heard you: https://www.dropbox.com/s/lya8koxc6puc4ui/IMG_20140617_112436.jpg15:28
jorgewayoung, The service provider decides that the bursting can occur.  The user bursts by simply making a call to the endpoint.15:28
henrynashjorgew: maybe we could take this up a level….the obvious k2k federation is where we do exactly what we do in federation today, it’s just keystone can act as an idP…..what proboem with that solution is unacceptable and you are trying to solve?15:28
ayoungjorgew, yes.  Just be aware that "locking it down" involves changeing some pretty serious asumptions on the part of Horizon15:28
morganfainberghenrynash, ++15:29
morganfainberghenrynash, that is a very good question.15:29
joesavakdstanek - that's right on15:29
ayounghence: https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens15:29
morganfainbergdstanek, i think my neck dislikes your diagram >.> :P15:30
dstanekjoesavak: my diagram is a bit off and messy, but that clears up many of my questions15:30
dstanekmorganfainberg: serry :-(15:30
morganfainbergdstanek, thanks for posting it :)15:30
dstanekso are you envisioning the remote keystone will not issue it's own token for the client?15:30
jorgewhenrynash,  Here's a scenario that may explain the issue.  Cloud 1, wants to extend it's services to region X where it doesn't have a DC.  It enters into a relationship with Cloud 2 and says please allow my users to use your resources.  Cloud 1 may not nessesary want it's users to know that Cloud 2 is being used.  Think reseller model.15:31
*** amerine has quit IRC15:31
*** amerine has joined #openstack-keystone15:31
morganfainbergjorgew, i see one small problem, there are sometimes local resources (trove?) that may not be available and you'd need to know that15:31
morganfainbergjorgew, if you're bursting into a cloud, it is likely you need to know you are bursting outside of the local cloud - especially if you're referencing a local resource.15:32
*** juanmo1 has joined #openstack-keystone15:32
joesavakmorgan - you touch on another step there. Let's talk about that. How to get a single service catalog15:32
ayoungjorgew, I would do bursting as a service in front of Nova.  THe burst decision is going to require a lot of orchestration15:32
*** zhiyan is now known as zhiyan_15:32
ayoungin that case, the orchestrator (nova or Heat or whatever) can do the token2token request as part of the burst operation15:33
rodrigodsdstanek, morganfainberg neck safe version https://www.dropbox.com/s/tkhu4vbg6z099a0/IMG_20140617_112436.jpg15:33
*** erecio has quit IRC15:33
jorgewayoung, that can work as long as the process is hidden from the user. You'd still want a single catalog etc.15:33
ayoungjorgew, the endpoints would all have to be "burst proxy"15:34
*** erecio has joined #openstack-keystone15:34
ayoungjorgew, you could make it a little more explict by doing this:15:34
ayoungcreate a "burst" proejct15:34
jorgewmorganfainberg, wouldn't that still be an issue if you are dealing with multiple regions in the service catalog, how is that different?15:34
dstanekrodrigods: thx!15:34
*** juanmo has quit IRC15:34
joesavakdstanek - see see line 103: https://review.openstack.org/#/c/100023/3/specs/juno/keystone-to-keystone-federation.rst regarding service broadcasting of remote clouds15:34
ayoungand everything in that project is a remote endpoint15:34
ayoungso if the local context is "full"  use the "burst" context15:34
*** topol has quit IRC15:34
ayounghttp://younglogic.com/images/k2k_fed_flow.jpg  for people that don't want to strain their necks15:35
jorgewayoung, does that mean that all remote users use the same project?15:35
ayoungjorgew, no way15:35
jorgewokay whew…15:36
jorgewThen, I'm not sure I follow.15:36
ayoungjorgew, I'm just thinking outloud quietly here, but I would think the service catalog would be in some...swappable template thingy15:36
ayoungmake it a property of the project:15:36
ayoungand this is horrible, just brainstorming15:36
ayoungsay the region is different15:37
jorgewokay got it.  Correct,  users will see these endpoints as a different region.15:37
ayoungand so a given project is associated with R1.  R2  is the burst region in a remote cloud15:37
joesavakOk - gut check - everyone "get" the flow?15:37
ayoungthen the question is how do you generate a Burst  Project for every project that needs it...and I say you don't15:38
jorgewI like the name..maybe that's what we should call the proposal "Burst Regions"15:38
ayoungyou do it as a query parameter on the service catalog15:38
ayoungjorgew, what if15:38
marekdjoesavak: we rely on the classic regions ?15:38
ayoungfor a give project, we give it an ordered list of regions15:38
ayoungthe first is the default, and then each is used as a burst region in turn15:38
dstanekjoesavak: the only thing i'm wondering now regarding flow is morganfainberg's comments about who issues the token15:39
ayoungso when you get a token for P1, you get the service catalog for R115:39
ayoungdstanek, whomever makes the burst decision15:39
ayoungdstanek, if it is Nova1, then it does the token2token request15:39
joesavaktypically a client in the "local cloud" realm who's identity is accessible by k1 in the flow pic15:40
ayoungif it is heat,15:40
jorgewayoung,  like it, but keep in mind that the local cloud may have several local (non-burst) regions.15:40
ayoungjoesavak, and we can build that logic into the keystone client, but it really only makes sense in the "unified CLI"  approach to work across clouds15:40
ayoungjorgew, yep...and that is why I am not going to implement it until we run it past jaypipes15:41
jorgewayoung, I like the idea of using a query parameter to narrow what regions you get back in general (burst or local)15:41
ayoungactually, I am not going to implement it anyway...just provide guidance15:41
*** amerine has quit IRC15:41
joesavakmarekd - i don't get your question re: classic regions -15:42
ayoungjorgew, OK, I don't think you would want the whole service catalog in there, just the burst Keystone15:42
marekdjoesavak: regions we now have in openstack.15:42
ayoungthen, any client or service that needs to burst takes the token it is given, goes to the burst keystone, and echanges it for one with mapped roles, and a mapped service catalog15:43
joesavakmarekd - those will still work - what i believe ayoung and jorew are talking about is limiting service catalog response to local or bursted regions15:43
ayoungjorgew, and then you just get a ranked list of Keystone endpoints instead of the whole burst catalog15:43
marekdayoung: and the burst keystone can properly scope it to an existsing project/domain15:43
ayoungmarekd, yeah15:43
dstanekmarekd: those would be regions on the local cloud - what i'm hearing is that other regions may appear in the catalog that don't exist in the local cloud - joesavak is that correct?15:43
morganfainbergso... we need to keep the bursting region's service catalog in sync with the idp's region?15:43
joesavakdstanek - right, other regions and other endpoints/services15:44
ayoungmorganfainberg, that is why we just keep the keystone endpoint, not the whole burst catalog15:44
ayoungas I said, I was brainstorming15:44
morganfainbergif that is the case... i still think the right answer is go get a token from the burst region's keystone15:44
jorgewayoung, no…wait.  The burst region should look like any other region.  User should not nessesary know the difference.15:44
morganfainbergayoung, ++ yes, if it's just the endpoint,15:44
marekdayoung: and this is configured as per 'federation', so registered SPs15:44
ayoungjorgew, the end use does not15:44
ayoungjorgew, only the "burst decider" does15:45
jorgewayoung,  oh I get it.15:45
jorgewayoung,  …and we decided the "burst decider" was ___??15:45
morganfainbergayoung, i just think it's compltely unreasonable to ask the IDP keystone to keep an active list of the entire catalog for each SP keystone so it can issue things.15:45
ayoungjorgew, so if I go to nova, and nova says "i'm full"  that could be done as a return code to nova client, and then nova client could do all the logic.  Or Heat...etc15:45
rodrigodsmorganfainberg, ++15:45
ayoungmorganfainberg, you too slow15:45
ayoungI rejected that idea already15:46
morganfainbergayoung, thanks sorry carrying on 2 convos :P15:46
ayoungit was just an idea to generate another idea15:46
marekdmorganfainberg: you already have enough problems with token size, right? :P15:46
morganfainbergmarekd, yep15:46
ayoungmorganfainberg, the real question is "who makes the bursting decision"15:46
jorgewayoung,  don't think it should be the client.15:46
dstaneki was seeing a catalog with r1, r2 and br1 - r1 and r2 are exactly as the are today - br1 get bolted on15:46
ayoungjorgew, I think we can punt on where it happens.  It is going to be a multi-approach thing.  We just need to specify the mechanism15:47
morganfainbergthis sounds like we're somehow mixing heat logic and keystone logic into keystone.15:47
ayoungmorganfainberg, nah15:47
jorgewayoung,  not sure how it would wort with it being heat.  Why can't it be the keystone middleware…talking to keystone.  Isn't keystone the entity aware of the relationships anyway?15:47
ayoungmorganfainberg, let me try to diagram it out...15:47
* ayoung goes to white board...carry on15:47
morganfainbergayoung, depends on how bursting logic is done15:47
dstanekjorgew: if now the client then who will use the bursting endpoint?15:48
jorgewdstanek,  to the client the bursting endpoint just looks like a regular endpoint, the bursting happens under the hood.15:48
dstanektoday we can have r1 and r2 all locally - if r1 is full the client needs to go to r2 right?15:48
rodrigodsdstanek, good question =)15:49
dstanekjorgew: but there is no magic right? the client actually creates a VM on the bursted region15:49
dstanekto me the "under the hood" is getting the "burst regions" setup15:49
rodrigodsi don't get the steps between the burst decision and the k2 token request15:50
jorgewdstanek, yea no magic.  Right under the hood means whatever it takes to setup the burst regions etc.15:50
marekdjorgew: burst regions are handled by a remote cloud, with k2 sitting there, right?15:51
marekdwhereas k1 is my 'local' keystone.15:52
dstanekmorganfainberg: in this particular use case you'd have to put the remote regions in the catalog since the it's really an extension to the cloud15:52
ayoungOK...I have puictures..let me post15:52
jorgewmarekd, yup15:52
joesavakburst regions in a remote cloud are local regions for that remote cloud. What makes them burst regions is another cloud accessing them?15:52
marekddstanek: i think so. still better than all the remote services.15:53
dstanekjoesavak: i think so; it's really burst though it's just a fake local region that point to a remote cloud's local region15:53
marekddoes anybody have a good resource regarding regions? me must educate :(15:55
*** jsavak has joined #openstack-keystone15:55
rodrigodsmarekd, me too15:55
dstanekthat should have read "it's not really burst"15:55
jsavakit enables burst - by allowing visibility to burst regions and services15:55
jorgewdstenk, it's burst, you're going to a different cloud :-)15:55
jorgewdstenk, though the user preceives it as simply bursting to another region.15:56
marekdlogically he is within one cloud, physically somewhere else.15:56
morganfainbergjorgew, hm. ok i see this as not k2k federation.15:56
morganfainbergjorgew, it really isn't "federation" - it's using some federation technology to do bursting.15:57
rodrigods++ to "Burst regions" title =)15:57
dstanekjorgew: ok, i can buy that. i think of bursting an a sort of automatic event based on load or some other factor15:57
jorgewmorganfainberg, that's fine.  I like "burst region" title"15:57
ayoungthe k2k part is where the "burting" requires a new token15:58
hrybackiayoung: I'm about to be tied up in fun-interny-events for a couple of hours -- shot you an email with a list of queries for when you're not busy :)15:58
morganfainbergayoung, yes.15:58
ayoungOK...had to resort to twitter to post images15:58
morganfainbergayoung, which also implies you could do the k2k part without "bursting"15:58
*** joesavak has quit IRC15:58
morganfainbergstrict identity providing15:58
ayounghttps://twitter.com/admiyoung/status/478929419889676288/photo/1  is the proxy driven, hidden from the user15:59
dstanekmorganfainberg: the bursting is just one of the use cases15:59
morganfainbergdstanek, ++ yes15:59
jorgewayoung, studying your picture16:00
ayoungI can't get the client one to post16:00
dstanekayoung: so you would rather increase the surface area my making all services understand federation?16:00
morganfainbergayoung, imgur?16:00
ayoungmorganfainberg, don't have it set up yet...16:00
morganfainbergayoung, can do anonymous upload16:00
morganfainbergayoung, no account needed.16:01
stevemar++ anonymous16:01
jorgewayoung,  so nova API is a proxy?16:01
jorgew…to nava burst?16:01
ayoungmorganfainberg, its the "get it off the phone" stage that is messing me up16:01
morganfainbergayoung, oh.16:01
* ayoung without a usb cable right now16:01
dstanekjorgew, ayoung: i think this is actually more what i envision when someone says burst16:01
morganfainbergayoung, yeah thats painful. email it to yourself!16:01
*** amerine has joined #openstack-keystone16:02
ayoungmorganfainberg, I did...and am waiting for delivery16:02
ayoungI need a better setup...but anyway, the colient one is similiar16:02
morganfainbergayoung, ++16:02
dstanekjorgew, ayoung: but i don't see how that can work. an app's architect will need to know where the nodes are provisioned16:02
morganfainbergayoung, install dropbox on the phone? *shrug* dunno.16:03
jorgewdstanek, can you ellaborate?16:04
*** sbfox has joined #openstack-keystone16:04
dstanekjorgew: the diagram looks to me like nova will decide that it need more capacity and use someone's cloud the automatically fulfill the request16:06
dstanekif that is the case something will have to happen for the app running in the remote cloud to talk to local datastores16:06
jorgewdstanek, I think you are thinking auto-scale…not bursting16:06
ayoungdstanek, that is one use case16:06
rodrigodsdstanek, the provisioning phase is before the first call to local nova, isn't?16:06
ayoungI have another ...if I can figure out the technolog16:07
*** htruta has joined #openstack-keystone16:07
dstanekjorgew: to me that is what ayoung's diagram implies16:07
rodrigodsi decide that i need more nodes, i ask my nova service, if 'no room' i seamless get a node from a burst cloud16:07
dstaneknova API talks directly to nova (burst)16:07
jorgewdstanek,  yea, I see what you mean.16:07
dstanekrodrigods: i don't think that can work16:08
dstanekas an architect i have decided how to partition my app/data into regions (or whatever) and if you start doing that automatically my app won't work16:08
rodrigodsdstanek, i think i missed the point, then...16:08
*** amerine_ has joined #openstack-keystone16:08
jorgewayoung, the idea is that user sees as just another region.   No need for nova api to be involved.16:08
dstanekfrom a openstack perspective this would work because i have a new instance, but from an end user perspective it's broken16:09
ayoungjorgew, hold on16:09
rodrigodsso the burst region would always be available?16:09
ayoungjorgew, thing is, you need to make the token translation explicit, so it can't just be another region16:10
ayounginstead, something has to decide "time to burst"16:10
marekdayoung: how do you 'switch between regions' today?16:10
dstanekayoung: i think that has to be the client and not the SP16:10
marekddstanek: ++16:10
morganfainbergmarekd, i'd ask jaypipes - but i think it's application  specific16:11
ayoungdstanek, it has to be whomever makes the decision16:11
morganfainbergmarekd, e.g. the consumer of the cloud chooses16:11
*** amerine_ has quit IRC16:11
jorgewayoung, hmm..so by token translation you mean token exchange?16:11
marekdmorganfainberg: beause i think this 'burst decision' should be done exactly like the dstanek says - by the client.16:11
*** jaosorior has quit IRC16:12
*** amerine has quit IRC16:12
dstaneki think that bursting anyware is client, but i don't think they need to know where the regions is physically16:12
morganfainbergmarekd, ++16:12
*** marcoemorais has joined #openstack-keystone16:12
*** amerine has joined #openstack-keystone16:12
rodrigodsso, in ayoung diagram, the client would be responsible for steps 6 and 7, right?16:12
marekdmorganfainberg: they are running out of resources, so they go to a public cloud provider and after some configuration they now have a new 'region' appearing in the service catalog ready to be used.16:12
morganfainbergdstanek, sure.16:12
jorgewmarked, you switch to a different region by simply calling another endpoint.16:13
morganfainbergmarekd, except the region should likely always be visible.16:13
marekdmorganfainberg: what do you mean?16:13
morganfainbergnot just conditionally16:13
marekdmorganfainberg: why?16:13
morganfainbergmarekd, if you can use that region, you can use it16:13
morganfainbergmarekd, how do you "know" resources are low16:13
rodrigodsmorganfainberg, but i can always use the burst cloud, even with space at my local region16:13
morganfainbergwe don't have centralized quota16:13
morganfainbergrodrigods, ++ thats what i'm saying.16:14
*** gokrokve has joined #openstack-keystone16:14
morganfainbergrodrigods, even if you're not low on space in the Local region, you could always use the burst region.16:14
morganfainbergrodrigods, the burst region doesn't "magically" appear16:14
dstanekmorganfainberg: it's no different that rackspace saying ORD is filling up and they setup ORD_alt a few blocks away16:14
marekdmorganfainberg: that's the matter of monitoring my resources? Anyway, this bp doesn't try to answer this question.16:14
dstanekORD_alt would eventually just pop up16:14
*** jsavak has quit IRC16:14
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421416:14
marekdmorganfainberg: I'd start 'a user want to have easily more resources, he wants to a new region appear suddently'16:15
rodrigodsmorganfainberg, but how the contract between clouds is done? the user would be paying to someone else, instead to my local service16:15
morganfainbergrodrigods, thats a billing issue, i can't solve that strictly in keystone16:15
morganfainbergrodrigods, that is a "when you negotiate the trust you figure out how billing works"16:15
rodrigodsmorganfainberg, but you agree that i can lost control of what's being using externally?16:16
dstanekrodrigods: yeah, that's cloud provider to cloud provider (part of the contract they sign)16:16
morganfainbergdstanek, ++16:16
*** marcoemorais1 has joined #openstack-keystone16:17
*** marcoemorais has quit IRC16:17
ayoungjorgew, how does a user find out that they are running out of resources?16:17
rodrigodsayoung, who is 'user'?16:18
jorgewayoung, you mean how does a cloud provider know it's having capacity problems?16:18
marekdjorgew: i think so16:18
morganfainbergoooh you know what... i think this becomes a lot more clear now16:19
dstanekwell is region1 is filling up and i should start using remote_region1, how do i know?16:19
morganfainbergayoung, it's not user specific, it is cloud specific16:19
morganfainbergayoung, if region A is full, you can use region B16:19
morganfainbergregion B is not local16:19
jorgewayoung:  That's very cloud specific:  here's a hint for us a region may involve multiple DCs, :-)16:19
marekdmorganfainberg: yes......16:19
*** afazekas_ has quit IRC16:19
*** richm has quit IRC16:20
morganfainbergthis means quota would need to be managed on both sides.16:20
*** gyee has joined #openstack-keystone16:20
ayoungmorganfainberg, quota is per cloud16:20
marekdmorganfainberg: what quota? for who?16:20
rodrigodsso the "burst decision" should be pluggable, right?16:20
jorgewI think capacity planning is a whole different issue though.16:20
marekdjorgew: ++16:20
jorgewNot something we can tackle from keystone.16:20
morganfainbergso. i'm now again confused16:20
dstanekmorganfainberg: ?16:21
morganfainbergjorgew, is this Capacity of region A is full and users who have resources available to them can use the non-local Region B (burst)?16:21
morganfainbergjorgew, or is this a user has hit their limit in the region and can "burst" to some non-local region?16:21
morganfainbergjorgew, or ... is this something totally different16:21
dstanekmorganfainberg: i think it's about the cloud not the user16:21
marekdmorganfainberg: why? What i see right now is: you can attach a region, physically from the remote cloud. And you can use this region as it was your region. It's up to you when you decide to use it..or if you decide yo use. With the moment you stop paying, this region should stop being usable for you16:21
morganfainbergdstanek, i think so too, but want to be 100% sure16:21
jorgewmorganfainberg:  We use regions for many different reasons.  One is for capacity planning…but another is HA..and another is to meet governmental restriction..and another is to have resources geographically close16:22
dstaneka cloud provider extending it's clound my using someone else's16:22
jorgewmarked:  exactl!16:22
morganfainbergmarekd, jorgew, still doesn't answer my question clearly16:22
jorgewThe user decides how to use regions.16:22
morganfainberglet me re-ask16:23
marekdmorganfainberg: sure.16:23
gyeeayoung, the test you taken out is for testing in a situation where only token_format is set, typical for an old config. https://review.openstack.org/#/c/98897/11/keystone/tests/test_token_provider.py16:23
morganfainbergis the allowance of the "non-local" region cloud deployer based, e.g. "i deploy a private cloud and want my users to burst to RAX"16:23
*** joesavak has joined #openstack-keystone16:23
gyeeayoung, that test should stay16:24
ayounggyee, token_format is set and token.Provider is None16:24
ayoungthat does not exist anymore16:24
morganfainbergis the allowance of the "non-local" region cloud a user decides to setup or for a specific subset of users?16:24
ayounggyee, token.Provider is now defaulted16:24
gyeeayoung, for old config, existing deployment16:24
*** raildo has quit IRC16:24
ayounggyee, if it iwas None before it will now be PKIZ16:24
morganfainberggyee, ayoung, i think we need to just put a stake in the ground and say X option overrides Y option, here is a warning16:24
morganfainberggyee, ayoung, in fact--- we should have done that to begin with16:25
ayounggyee, and if they do not agree  they get an error16:25
openstackgerritIlya Pekelny proposed a change to openstack/keystone: oslo.db implementation  https://review.openstack.org/7721016:25
*** thiagop has quit IRC16:25
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations.  https://review.openstack.org/8063016:25
gyeeayoung, that's not what that test is for, it is specially for only if token_format is set16:25
*** tellesnobrega has quit IRC16:25
gyeeit not for defualt provider16:25
jorgewmorganfainberg:  The allowance for a non-local region can be because capacity has exceeded the local cloud…but could also be because there are users in china and you want hosts close to your users…or you want better HA. or whatever.16:25
*** htruta has quit IRC16:26
morganfainbergjorgew, so what is the barrier for what users can use the region.16:26
*** jsavak has joined #openstack-keystone16:26
*** rodrigods has quit IRC16:26
morganfainbergjorgew, users/projects/whatever16:26
*** i159 has quit IRC16:26
gyeemorganfainberg, sure, has OpenStack as whole came to an agreement on the deprecation process yet. :)16:26
gyeemaybe I missed the official announcement16:26
morganfainberggyee, make the setting of the format override the provider, throw a big warning16:26
jorgewmorganfainberg,  good question.  You can have polices to decide what users can access what regions.   I believe that should be up to the cloud provider.16:27
ayoungjoesavak, jorgew, https://twitter.com/admiyoung/status/478936760337301505/photo/116:27
ayoungthat is the client driven use case16:27
ayoungI could draw one up for heat, but just change "client" to "heat" and you've got it16:27
morganfainberggyee, since we default the provider option now.16:27
marekdmorganfainberg: i think from the user/client perspective there is another region appearing. And how you, as an operator decide who and how can use this remote region.16:27
marekdis up to you16:27
gyeemorganfainberg, the  warning has always been there I think16:27
gyeequestion is when do we stop supporting token_format option16:27
marekdand probably you do this in a way you do with your real 'local' regions.16:28
dstanekjorgew: so with all three use cases everything really boils down to creating a local region that actually points to another cloud? how you use the region is what differentiates your use cases. e.g. knowing you are using another provider16:28
morganfainberggyee, set a timeline16:28
ayounggyee, lets "break" it for now16:28
jorgewayoung, client driven is not what we're interested in.  It would mean the business logic lives with the client and other clients would have to replicate it etc.16:28
ayoungand by break, I mean, let people know that things are changing16:28
morganfainberggyee, K?16:28
morganfainberggyee, it's been deprecated for a while.16:28
ayoungjorgew, that is irrelevant to keystone, though16:28
ayoungthat is my point16:28
*** joesavak has quit IRC16:28
jorgewdstenek, yes16:28
morganfainberggyee, it's reasonable to make the change in K, just make the token format option win until it is gone16:28
ayoungjorgew, whomever is making the decision converts a local token for a remote.16:29
ayoungremote keystone is in the local service catalog as the "burst" keystone16:29
morganfainberggyee, make the warning say "this option will be removed in K" it is purely an operator thing no other services need to care.16:29
gyeemorganfainberg, sure, would be nice if OpenStack as whole can formally endorse a deprecation process16:29
morganfainberggyee, so it falls outside the deprecation topic we had before16:29
jorgewayoung, okay fair enough.  So what if that code lives in middle ware :-)16:29
morganfainberggyee, which was deprecating something other services use.16:29
morganfainberggyee, not purely operator16:29
gyeemorganfainberg, no, that's an external facing option16:30
morganfainberggyee, where?16:30
jorgewayoung, keystone still needs to provide the sevice catalog bit right?16:30
dstanekjorgew: in the case of current federation the token is local - you hit keystone and it says go to X to auth - can this be constructed in the same way?16:30
*** 77CAADFPS is now known as jimbaker16:31
gyeeisn't everything in keystone.conf public? they are not APIs, but they are being used in the field16:31
dstanekkeystone1 would present SAML assertions (or something) to keystone2 and that would issue a token16:31
jorgewdstanek, yea, as long as the process is hidden by the user, the idea is to reuse those flows16:31
ayoungjorgew, I would say that the needs of different organizations are going to dictate different approaches.  I would say that "conver local token to remote token"  is a keystoneclient library call and can be made from a few different places depending on how you want bursting to work16:32
morganfainberggyee, this is a deprecated config option - not something other OpenStack services care about. (or really shouldn't). there is an alternative, so i think it's fine to set a timeline to remove it.16:32
marekdjorgew: but then you want a one keystone acting on behalf of the user himself?16:32
ayoungjorgew, I don't know if I would suggest doing it from middleware.  My kneejerk reaction is No.16:32
*** sbfox1 has joined #openstack-keystone16:33
*** richm has joined #openstack-keystone16:33
morganfainberggyee, the change i propose is 2 bits: 1) token_format wins if set., 2) plan to remove the option in K.16:33
morganfainberggyee, tell operators/deployers the new option should be used in the warning message (already done).16:33
ayounggyee, the issue I have with the current approach is that we are hiding the logic for what is the default token provider.  I'd rather make it explicit.16:33
*** sbfox has quit IRC16:33
morganfainberggyee, and when the old option will go away16:33
jorgewayoung,  in order to really allow burst endpoints to work easily then you'd need software to glue the pieces together.16:33
ayoungmorganfainberg, I can live with that.16:34
ayoungjorgew, right.16:34
ayoungjorgew, so the division of labor is "what does keystone provide" vs "who calls it"16:34
jorgewmorganfainberg, ayoung, dtanek….Hey guys,  I have to take run to a meeting.  Joe and I will rework the spec around "Burst Regions" concept.  Bring in some of the ideas presented here so far and we can continue the discussion there.16:34
ayoungjorgew, now...all the other issues I brought up before still apply16:34
gyeemorganfainberg, I have zero problem with deprecating stuff :) All I am saying is is there a way to make it less chaotic16:35
ayoungnamelyL  how do I map one token to another, and how do I not treak keystone tokens as authentuication.  And, most important, how tdo I limit the direction of token rescoping16:35
morganfainbergthis is def. a bit more clear now.16:35
morganfainberggyee, :) i think reducing the crazy logic down and saying when we remove the option will solve exactly that, waaay less chaotic16:35
marekdhaha, after we redefined 'what we do', we are again at the 'how we do that' point :)16:36
ayoungmorganfainberg, so if token_format is set, it just wins?  Ugh16:36
ayoungthat is probably wrong16:36
morganfainbergayoung, nope, principle of least surprise16:36
*** amerine has quit IRC16:36
morganfainbergayoung, and we make the warning message clear that the other option is ignored (same in the help text)16:36
ayoungmorganfainberg, that would surprise the heck out of someone that explicitly set both token_format and token.Provider16:37
*** leseb has quit IRC16:37
*** jorgew has left #openstack-keystone16:37
morganfainbergayoung, you're a developer.16:37
gyeeayoung, that's exactly what that test is for, token_format is set, but no token provider16:37
*** amerine has joined #openstack-keystone16:37
dstanekayoung: here is what i was thinking just now https://www.dropbox.com/s/lmkoswv67n0ggj8/2014-06-17%2012.34.41.jpg16:37
ayounggyee, BUT NOW THERE IS!16:37
*** leseb has joined #openstack-keystone16:37
ayoungdstanek, is this going to hurt my neck?16:37
ayoungdstanek, yeah, that is16:38
marekddstanek: what N2 says to the user?16:38
marekddstanek: "sorry....(?)"16:38
ayoungdstanek,  https://twitter.com/admiyoung/status/478936760337301505/photo/116:38
gyeeayoung, old config, per grenade, new code must work with old config16:38
dstanek"sorry need to federate (with a link to k2)"16:38
gyeeif we don't care about old configs, then sure, fuck it16:39
ayounggyee, we make it an explicit choice.16:39
morganfainberggyee, hence why i think otken_format wins16:39
marekddstanek: do we want to put this federation workflow into nova, glance etc?16:39
dstanekmarekd: not exactly that because i drew in a hurry, but think how federation works now16:39
morganfainberggyee, and probably should have won in the original code (with the warning message)16:39
marekddstanek: yes, except it's at the Keystone level16:39
dstanekmarekd: doesn't that happen now through authtoken?16:39
morganfainberggyee, vs. a config error raised if both were set.16:39
marekddstanek: authtoken is used in nova, glance etc, right (i don't know that)16:40
dstanekmarekd: maybe i need to learn a little more about our federation flow16:40
gyeemorganfainberg, that logic sounds reasonable16:40
marekddstanek: so, you always go to the keystone....remote keystone16:40
morganfainberggyee, lets go with that plan so we can get the compressed tokens in :)16:40
dstanekmarekd: in a client centric flow i think so16:41
ayoungmorganfainberg, this is what we do now http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/provider.py#n7816:41
dstaneknot saying that is what i would want, but that is what i saw from ayoung's diagram16:41
gyeemorganfainberg, oh yeah, +++++ for compressed tokens, just want to make sure we don't break backward compatibility16:41
dstanekmarekd: ^16:41
morganfainbergayoung, and i think that whole block of logic was wrong from the get-go16:41
*** leseb has quit IRC16:42
ayoungmorganfainberg, so...if we leave token_format...I'll drop making PKIZ the default provider in the conf file, and instead just hack this logic16:42
morganfainbergayoung, no.16:42
marekddstanek: whch picture? client driven?16:42
morganfainbergayoung, we make token_format win _if_set_ and only if set16:42
morganfainbergayoung, PKIZ is the default provider16:42
dstanekmarekd: yes16:42
ayoungmorganfainberg, new patch in a few16:42
morganfainbergayoung, if both are set, no error is raised16:42
*** Benj__ has quit IRC16:43
morganfainbergayoung, jsut token_format is the winner (and the test is changed to confirm that)16:43
*** harlowja_away is now known as harlowja16:43
marekddstanek: but it looks like nova client goes to a K216:43
marekdand gets a new token16:43
ayoungmarekd, there are a whole slew of questions around bursting, including "I don't want you to burst if its going to cost me money"16:44
morganfainbergayoung, might want to make that change a separate patch - or i could hack it up in a quick minute or two.16:44
morganfainbergayoung, then easy rebase of your patch on top.16:44
morganfainberghenrynash, ayoung, gyee, mind pressing go on https://review.openstack.org/#/c/100545/16:44
ayoungmorganfainberg, +A16:45
morganfainbergayoung, tyvm16:45
dstanekmarekd: yes, in my mind that was a result of presenting federation assertions from k116:45
marekddstanek: aaaa, i thought h wanted to present a OS token issued by K116:45
* gyee never going to get into a jeopardy with ayoung. He's got fast fingers. :)16:46
marekddstanek: but actually it looks more like OpenSTack token, not SAML assertion.16:46
marekdayoung: ^^ ?16:46
marekdayoung: in your "client driven" picture - what do you send to K-Burst-16:47
ayoungmarekd, T116:47
ayoungand get T216:47
*** beav has joined #openstack-keystone16:47
marekdan openstack token.16:47
ayoungthen send T2 to N216:47
*** erecio has quit IRC16:47
marekdok, that's my understanding.16:47
ayoungmarekd, this is completely sidestepping authentication issues16:47
ayoungfor client driven, use the smae authentication mechanism16:47
dstanekmarekd: that's what i want to do - i think the proposal is the have k2 handle tokens from k116:48
ayoungfor service driven, use trusts16:48
*** erecio has joined #openstack-keystone16:48
*** htruta has joined #openstack-keystone16:49
*** rodrigods has joined #openstack-keystone16:49
*** raildo has joined #openstack-keystone16:49
openstackgerritRoman Bodnarchuk proposed a change to openstack/keystone: Return 400 in case request body is JSON, but not a dictionary  https://review.openstack.org/9280916:49
marekddstanek: handle and issue a new token.16:49
marekddstanek: later to be used agains N216:49
*** hrybacki_ has joined #openstack-keystone16:52
*** tellesnobrega has joined #openstack-keystone16:52
marekdOk guys, that was a nice discussion. I need to run, otherwise they will close all the shops here and I will get to bed hungry :( I should be online later. Cheers!16:53
*** marekd is now known as marekd|away16:53
*** amerine_ has joined #openstack-keystone16:54
morganfainbergayoung, gyee, was thinking something like this: http://paste.openstack.org/show/84322/16:54
*** amerine__ has joined #openstack-keystone16:55
*** hrybacki has quit IRC16:56
*** hrybacki_ has quit IRC16:56
ayoungmorganfainberg, way ahead of you16:56
morganfainbergayoung, cool16:56
gyeemorgainfainberg, looks fine16:57
*** harlowja has quit IRC16:57
gyeemake sure the existing tests still works though16:57
morganfainberggyee, will need a minor change i think, but yes.16:57
*** amerine has quit IRC16:58
morganfainbergas soon as these land (today I hope) going to start work on getting the changes so we default to wsgi for gate with one test running eventlet (we support it, can't not gate on it)16:58
*** amerine_ has quit IRC16:59
*** erecio has quit IRC17:00
*** bklei has joined #openstack-keystone17:00
*** erecio has joined #openstack-keystone17:00
*** harlowja has joined #openstack-keystone17:01
*** nkinder_ has joined #openstack-keystone17:04
*** rodrigods has quit IRC17:04
*** nkinder has quit IRC17:04
*** sbfox1 has left #openstack-keystone17:06
morganfainberggyee, jamielennox, stevemar, henrynash, https://review.openstack.org/#/c/95973/ if you have a bit of time to look over this today, it would be great17:06
morganfainbergdolphm, ^ (ack, missed ya there)17:06
gyeek, looking17:06
stevemarhow is that not approved it17:07
dstanekare there any specific specs we'll be going over today in the meeting?17:07
*** leseb has joined #openstack-keystone17:08
openstackgerritChristoph Gysin proposed a change to openstack/keystone: fix flake8 issues  https://review.openstack.org/10062817:08
morganfainbergdstanek, the middleware one and the session token ones17:08
morganfainbergdstanek, other than that the others that are still open are open for discussion17:08
gyeestevemar, I am looking for extra space, typos, etc right now :)17:08
*** marcoemorais1 has quit IRC17:10
*** marcoemorais has joined #openstack-keystone17:10
*** tellesnobrega has quit IRC17:10
*** raildo has quit IRC17:11
dstanekmorganfainberg: looking that the v3 extensions spec now...what about json-home?17:12
*** htruta has quit IRC17:12
dstanekthere was talk of doing that. how does this compare/contrast/etc.17:12
morganfainbergdstanek, not mutually exclusive17:12
morganfainbergdstanek, json home could be implemneted later on17:12
*** leseb has quit IRC17:13
*** nsquare has joined #openstack-keystone17:13
dstanekmorganfainberg: would that change the structure of this data at all?17:13
morganfainbergdstanek, bknudson indicated JSON home could be implemeted with no impact to the v3 one17:14
dolphmmorganfainberg: more directly, is this not made redundant by json home?17:14
morganfainbergdolphm, it is. but json home was specifically stated as more up in the air17:14
morganfainbergdolphm if we would rather do JSON home, that's fine17:14
dolphmmorganfainberg: why is it more up in the air?17:15
morganfainbergdolphm, i'll defer to bknudson on the specifics, but as i recall (please correct me if i'm wrong) the JSON home was was viewed as something to work on in spare time? - because it's a departure from what we have now?17:16
dolphmmorganfainberg: i see json home as an improvement/standardization of what we have now, while GET /v3/extensions is just redundant with GET / - plus a bunch of metadata that no one uses17:17
morganfainbergdolphm, i'm perfectly fine squashing this one and saying lets do JSON home17:17
morganfainbergdolphm, i was going by the original discussion with bknudson that this one was an easy target.17:17
dolphmthe only real argument i've seen in favor of it is "that's how v2 did it" but there's no justification for it in v2 either17:18
morganfainbergdolphm, if we're def. going JSON home lets -2 this, squash it and say JSON home. I'd like to see either of these implemented.17:19
gyeeis openstack as a whole standardizing on JSON home?17:20
dstanekdolphm: morganfainberg: does json-home provide guidance for this sort of thing?17:20
dolphmmorganfainberg: the spec actually mentions JSON Home as an Alternative btw, and then goes on to say they're not mutually exclusive... but never compares them or justifies one or the otehr17:21
morganfainbergdstanek, http://tools.ietf.org/html/draft-nottingham-json-home-03 i need more coffee before i can comment on that17:21
dolphmgyee: there's not an alternative, other then the homegrown crap that we've all gotten wrong17:21
bknudsonI'm fine with JSON Home rather than advertise extensions in /v317:22
* morganfainberg defers to bknudson here.17:22
dolphmdstanek: is there some specific aspect of GET /v3/extensions you're looking for in json home?17:22
gyeedolphm, k, lets roll with JSON home then17:22
morganfainbergbknudson, if you're fine with JSON home, and it's better.. lets just go with that :)17:22
dolphmis there a jsonhome lib?17:23
bknudsondolphm: I didn't find a lib for jsonhome17:23
morganfainbergdolphm, dunno, i think json home isn't fully finalized yet - so17:23
dolphmmorganfainberg: ack, but the last 2 or 3 drafts have maintained backwards compat17:23
dolphmi never looked at draft 117:23
bknudsonmarconi doesn't use a lib for json home17:24
morganfainbergdolphm, right, my guess is it's pretty new. hence no lib yet17:24
gyee++ for standard, -- for homegrown crab (only if its inhalable :D)17:24
bknudsonreally it's just a JSON document, so it's just hardcoded17:24
dstanekdolphm: no, just trying to understand all of the things we want to do and how they tie together17:24
dolphmbknudson: it should be dynamic, given a dynamic pipeline17:25
dolphmbknudson: all i'm really thinking about is validation/jsonschema for it17:26
*** bklei has quit IRC17:28
bknudsondolphm: can't find anything for jsonschema for json home.17:28
dolphmbknudson: neither can i17:28
bknudsonhere's the marconi code: http://git.openstack.org/cgit/openstack/marconi/tree/marconi/queues/transport/wsgi/v1_1/homedoc.py?id=6f039e32bcd9897442d2a61bd9eae5c387eaea9c17:29
morganfainbergi need to go get coffee before meeting. be back shortly17:29
bknudsonthey apparently don't have much in the way of resources17:29
*** praneshp has joined #openstack-keystone17:33
*** joesavak has joined #openstack-keystone17:33
dstanekis there any guidance for dealing with images in specs?17:36
*** jsavak has quit IRC17:36
bknudsondstanek: ascii art17:36
dstanekbknudson: ha, i hope that's not it :-)17:36
bknudsondstanek: you mean a diagram?17:37
dstanekbknudson: yes, i want to attach a diagram to the pec i'm working on17:38
*** amerine__ is now known as amerine17:38
*** einarf has joined #openstack-keystone17:39
*** htruta has joined #openstack-keystone17:40
bknudsondstanek: there was a web tool for making ascii art diagrams... I didn't keep a link.17:40
gyeedstanek, bknudson, same as blueprint I suppose, have your diagram in openstack wiki and provide a link to it17:40
openstackgerritA change was merged to openstack/keystone: pkiz String conversion  https://review.openstack.org/10054517:41
*** joesavak has quit IRC17:44
*** browne has joined #openstack-keystone17:45
henrynashcan anyone shed any light on tox -e docs failing becuase kds.api.app is not found while processing /opt/stack/keystone/doc/source/api/keystone.contrib.kds.api.rst17:45
henrynashI’ve had this problem for a while….17:46
henrynash(locally that is)17:46
dolphmi read through the meeting notes from last week and about half the log... the idea behind voting in the meeting was just a reality check on whether a spec was attractive at first glance, correct? not a vote for final +A for specs with sufficient +2's? cc- morganfainberg17:47
dolphmhenrynash: you probably have stray pyc files in your tree17:48
dstanekhenrynash: you may have some garbage in your docs dir17:48
*** tellesnobrega has joined #openstack-keystone17:48
dolphmhenrynash: find . -name "*.pyc" -delete17:48
henrynashactually…not sure docs/api still is valid at all is it?17:48
dolphmhenrynash: i don't have that dir, actually17:49
henrynashhmm, yes, not sure how I come to have it…think that’s the source of my problmes!17:49
henrynashI’ll ditch it!17:49
*** einarf_ has joined #openstack-keystone17:49
dstanekwhen you build the docs it creates tmp files from crawling the code - they don't go away, only modified - so if the code goes away you'll see errors17:50
stevemarhenrynash, rm -rf docs/build17:50
dstanekalso the api direct that gets created - that's where the rst for the code goes17:51
stevemarbut yeah, dstanek summed it up17:51
stevemaroh yeah17:51
henrynashdtsanek: got it in one17:51
morganfainbergdolphm, correct.17:51
henrynashdtsanek: thx17:51
*** einarf has quit IRC17:51
*** einarf_ is now known as einarf17:51
dolphmhenrynash: you can also do $ git clean -nd # to see what is in your tree that's not in the repo17:51
henrynashdolphm: hmm, nice cmd!17:52
morganfainbergdolphm, the vote was a "no major issues with direction we like the approach" once that passed, then it was 2x+2 and +A17:52
dstanekhenrynash: does you latest multi-backend review contain the fixes i made in separate patches?17:52
dolphmmorganfainberg: other than meeting notes, were we tracking meeting-approved specs somewhere?17:52
morganfainbergdolphm, only meeting notes so far17:52
henrynashdstanek: no, didn’t weant to steal your thunder…but I am happy to pull those in if you like17:53
dolphmmorganfainberg: so then looking at the summary, which ones passed? http://eavesdrop.openstack.org/meetings/keystone/2014/keystone.2014-06-10-18.01.html17:53
morganfainbergservice token,, api-validation, V3 extennsion advertise,  Audit notifications,17:54
dolphmmorganfainberg: there aren't really any unclear votes, but take "JSON Home" for example: 3 yes, 3 table. what does that outcome mean?17:54
dstanekhenrynash: haha, i just did they as separate commits because we want to get your spec through, but now that we're waiting there is no reason to have all of the separate commits17:55
morganfainbergdolphm, and henrynash's multi user_id one (earlier)17:55
morganfainbergdolphm, the rest were tabled, session tokens and middleware didn't receive a vote17:55
henrynashdstanek: I’ll pull them in that case….17:55
dolphmmorganfainberg: session tokens is the last one on there17:55
henrynashdstanek: thanks for taking the time to do them in the first place17:56
morganfainbergdolphm, we didn't get a full vote, time17:56
morganfainbergdolphm, so we ended before the vote had really been logged17:56
*** bklei has joined #openstack-keystone17:56
dstanekhenrynash: no problem17:56
*** alligator has left #openstack-keystone17:57
dstanekhenrynash: https://review.openstack.org/#/c/99416/1/doc/source/developing.rst - there were a couple of things commented on there that i didn't see17:57
henrynashdstanek: yep, see them, I’ll fix them up17:58
dstanekhenrynash: thx17:58
*** marekd|away is now known as marekd17:59
*** bklei has quit IRC18:03
*** hrybacki has joined #openstack-keystone18:04
*** leseb has joined #openstack-keystone18:08
*** leseb has quit IRC18:13
stevemardstanek, i was going to advise the folks who made the comments to supply fixes :)18:17
dstanekstevemar: looks like henrynash already has it taken care of18:18
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889718:18
dstanekstevemar: but yeah it would be good to nudge people into being more proactive18:18
ayounggyee, think you will like ^^18:18
*** jkappert has quit IRC18:19
*** jkappert has joined #openstack-keystone18:19
morganfainbergayoung, i want that conflict exception gone personally.18:19
morganfainbergayoung, i still think it's wrong18:19
ayoungmorganfainberg, yeah, but it is what we do now18:20
stevemardoes anyone have an opinion on the new hacking rules / potential revert back to 0.8?18:20
stevemari threw up a patch for keystoneclient, but for keystone itself, would be a good chunk of work18:21
* dolphm has been staring at this channel for a good minute wondering how we got off the meeting topic.18:22
stevemardolphm, the channel seems to be eerily quiet18:24
dolphmwhich made me feel dumber18:24
stevemardolphm, bump?18:25
morganfainbergayoung, we'll talk about this logic after the meeting. i think we're doing it wrong and perpetuating the wrong because "it's how we do it now" isn't a good answer.18:30
dolphmmorganfainberg: logic of what?18:32
*** harlowja has quit IRC18:33
bknudsonstevemar: apparently the reason to not make hacking changes now was that the changes were clogging up the gate?18:36
dstanekstevemar: i haven't seen to new rules18:37
morganfainbergdolphm, the changes in https://review.openstack.org/#/c/98897/12/keystone/token/provider.py to make PKIZ the default. I was thinking something more like: http://paste.openstack.org/show/84322/ rather than doing all the "these options are in conflict"18:37
stevemarbknudson, but even if we were lazy about it, we could just ignore the rules that are being broken in tox.ini, and fix it slowly18:38
morganfainbergdolphm, and just make the token provider default = PKIZ, so signing.token_format simply wins if set, and we warn it's deprecated and stop using it18:38
stevemarbknudson, i dunno, didn't seem unreasonable to me18:38
bknudsonI think that's how you're supposed to do the hacking changes, first add a change with them all ignored18:39
bknudsonthen stop ignoring and fix each one18:39
bknudsonmight be on a wiki somewhere18:39
* stevemar shrugs, 18:39
stevemari figure its OK to fix a few in one patch too18:39
*** harlowja has joined #openstack-keystone18:40
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421418:41
*** joesavak has joined #openstack-keystone18:42
*** CaioBrentano has quit IRC18:48
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421418:53
ayounghenrynash, if the default salt is no salt, then adding salt can be a backwards compatible patch with not much effort18:59
henrynashayoung: although it would have to be off by default or teh IDs would change18:59
ayounghenrynash, if the default salt is no Salt, that works19:00
henrynashayoung: agreed….you just can’t change it once you’re up and running19:00
ayounghenrynash  not without sever pain19:01
ayoungsevere even19:01
henrynashayoung: agreed19:01
dstanekwhat are we salting?19:02
ayounghenrynash, so you think that the people that want salting will need it in the first revision19:02
morganfainbergdstanek, lunch?19:03
dstanekmorganfainberg: ++19:03
morganfainbergdstanek, i think we're salting lunch19:03
dstanekmorganfainberg: that's over here - onward toward dinner19:03
bknudsonthe hash of the ID19:03
henrynashdstanek: so some peopel raised a concern that if you are hashing, say, your LDAP ID attribute + domain ID then since the defautl domain has teh same ID in every OS installation, then you tour public ID would be the same when seen from two clouds…i.e. you coul dbe recognised as the same person19:04
henrynashdstanek: if you’re not in the default domain, there is no issue19:04
dstanekhenrynash: ah, i see. would the salt be a part of the resulting ID so that it would be recreated?19:04
henrynashdtsanek: yes, you’d have to pick something immuatble that is different for each OS installation (but would be teh same if you restored from backup etc.)19:05
henrynashmorganfainberg: hmm, tasty19:05
dstaneki was thinking the salt was for protecting against crypto-analysis - i'll keep my mouth shut now19:06
henrynash]morganfainberg: lunch, that is :-)19:06
ayoungjamielennox, I resubmitted the session-for-auth_token patch19:07
*** erecio has quit IRC19:07
ayounglet me know if what I submitted is sane19:07
henrynashayoung: if you are going to want it, then you really want it from the start….however, today their public IDs are teh same for every cloud anyway!!!  And that would not change by default sicne we don’t map teh default domain by default…and once you use a different domain, then you teh domain ID is as good as salt anyway19:08
*** erecio has joined #openstack-keystone19:08
ayounghenrynash, I'd say "no" then19:08
ayoungif you want "salt" you can get it by using a new domain id19:08
ayoungand that should have the same net effect19:08
henrynashayoung: yep19:09
*** leseb has joined #openstack-keystone19:09
ayounghenrynash, OK, so you are going to split the patch?  I assume the "centralize id generation" part first?19:09
henrynashayoung: I guess that was the concensus…so yes!19:09
jamielennoxayoung: it's broken -19:10
jamielennoxayoung: for whatever reason i can't remove the admin_token from trove, i think devstack builds from stable not master19:10
ayounghenrynash, please submit it with copious comments using British specific terms like Lorrie and Kippers19:10
jamielennoxayoung: so it supplies both an admin token and a user/pass - and it would be a patch to stable-maint to fix that19:10
morganfainbergayoung, gyee, sorry https://review.openstack.org/#/c/98897/ i don't think this is the right approach on the provider config detection, if someone wants to override me they can, but i really think we were doing it absolutly wrong before and we shouldn't have this crazy logic.19:11
jamielennoxso i need to redo the plugin there and make it do the proper fallback19:11
ayoungmorganfainberg, it was to make it through grenade19:11
morganfainbergayoung, if signing.token_format wins it should make it through grenade, right?19:11
ayoungjamielennox, cool.  Just so as you are aware, hrybacki is working on the revocation events patch, and is depending on that session work19:11
bknudsonjamielennox: isn't this a bug that you were fixing? (don't fallback to password if given a token?)19:11
ayoungmorganfainberg, yes.19:12
morganfainbergayoung, so why raise an exception?19:12
ayoungmorganfainberg, we just put an additional check if the token providerr is out of sync with it19:12
morganfainbergayoung, lets remove the "out of sync" part19:12
henrynashayoung: spiff-oh!19:12
morganfainbergthats what i think we're doing wrong19:12
ayoungmorganfainberg, it means that they edited their config file by hand and put in something that makes no sense19:12
jamielennoxbknudson: yes, but as i said trove seems to build from stable in devstack (or something) and so i couldn't get it to stop19:12
ayounghenrynash, Amoke me a kipper.  I'll be back for breakfast!19:13
bknudsonjamielennox: weird... so that change in behavior broke trove?19:13
jamielennoxyes, they ship with an admin_token in release, then add a user and pass in devstack19:14
gyeemorganfainberg, there are four scenarios: 1) only token_format is set (old config), 2) both token_format and provider are set (most likely accident), 3) only token_provide is set (new config), 4) neither token_format and provider are set (realy, really, really old config)19:14
morganfainbergayoung, i disagree with the previous choice to detect and raise on that19:14
jamielennoxi can't remember why i didn't just fix it in devstack...19:14
morganfainberggyee, option 4 nets us PKIZ in either case19:14
*** leseb has quit IRC19:14
ayoungmorganfainberg, look at it this way:  we had an old mechanism.  we are introducing a new mechanism.  you have to edit by hand to o from old to new19:14
ayoungthis is the handholding stage19:14
morganfainbergayoung, you're not going to convince me, sorry19:15
morganfainbergayoung, we did it wrong before, we're continuing to do it wrong, just make the old option, set by hand, win.19:15
gyeemorganfainberg, correct, option 4 nets pkiz19:15
morganfainbergit doesn't break the old configs it doesn't break anyone explicitly setting the provider19:15
ayoungmorganfainberg, meh.  I don't rally care that much19:15
gyeeoption 4 basically says gimme the default19:15
morganfainbergand it doesn't break new configs19:15
ayoungit will jsut be harder to debug when someone fat fingers it19:15
*** marekd is now known as marekd|away19:16
ayounggyee, do you really care?  I can drop the raise19:16
ayoungrasie the drop?19:16
ayoungdrop the beat.19:16
gyeedrop the beat! :D19:16
ayoungbeat the drop19:16
jamielennoxbknudson: yep, devstack uses icehouse stable - no idea why: git_clone git://git.openstack.org/openstack/trove.git /opt/stack/new/trove stable/icehouse19:16
ayounggyee, if you are OK with morganfainberg '19:16
ayoungs approach, I'll make it happen now19:17
jamielennoxso the patch would need to be backported - not sure if that's appropriate19:17
bknudsonjamielennox: the patch to have trove not set its own admin token?19:17
gyeemorgainfainberg, there was a bug on the explicit check I think19:17
jamielennoxbknudson: yes19:17
morganfainberggyee, we would need a minor change to the test i think19:17
gyeeto make sure token_format agrees with the provider19:17
morganfainberggyee, i'm saying drop the "make sure the provider matches token_format" check completely19:18
morganfainberggyee, always let token_format win if set (and log a nice fat warning like we do now)19:18
bknudsonjamielennox: I guess we should add a test for having auth_token fallback to password auth if the token fails19:19
morganfainberggyee, do we really care if they are out of sync? as long as token_format (old config style) works - we should be fine.19:19
gyeemorganfainberg, I see, yeah that's sounds fine too, as long as we have the warning19:19
* ayoung is caring less each passing minute19:19
ayoungok, I call that consensus19:20
dolphmthanks everyone for not coming to the identity program update webinar and not harassing me with terrible questions :)19:20
gyeeayoung, ++19:20
bknudsonit wasn't widely advertised19:20
morganfainbergayoung, and if for whatever reason this all makes grenade really unhappy i'll make the change back to this version so we can get the code in.19:20
morganfainbergdolphm, there was a webinar?19:21
gyeedolphm, like when do we support federation? :)19:21
dolphmmorganfainberg: yeah, they're all recorded anyway19:21
bknudsonI'm way behind on my mailing list reading19:21
morganfainbergdolphm, but... i wanted to ask inane questions!19:21
dolphmgyee: i covered that in the presentation if you were paying attention19:21
morganfainbergayoung, dolphm, what was the decision on priority of middleware split?19:22
dolphmmorganfainberg: that it's a priority :)19:22
morganfainbergdolphm, as in, we're doing it first? or j3?19:23
jamielennoxbknudson: yea, we had decided to break that compatability - but it might be easier to just do it19:23
morganfainbergdolphm, if we're doing it now, i'll get all the stuff going so it's ready for friday.19:23
morganfainbergif not, i'll work on other things :)19:23
dolphmmorganfainberg: non-persistent tokens!19:23
morganfainbergdolphm, get the spec approved! :)19:23
morganfainbergmod_wsgi gate is very close as well19:24
morganfainbergjust need the default PKIZ provider patch and i can change us over.19:24
dolphmmorganfainberg: link?19:24
dolphmi know i saw that today19:24
morganfainbergdolphm, https://review.openstack.org/#/c/9889719:24
bknudsonthere were complaints that the gate tests can't support postgres, so are they fine with adding keystone under wsgi?19:24
morganfainbergdolphm, the one i just was talking to gyee and ayoung about19:24
morganfainbergbknudson, the default will be mod_wsgi19:25
morganfainbergbknudson, and we'll make one of them run eventlet19:25
gyeebknudson, are they related?19:25
morganfainbergbknudson, no extra gate-jobs19:25
*** dims_ has quit IRC19:25
bknudsonmakes sense19:25
morganfainbergit's all driven by devstack and devstack-gate19:25
gyeehow's mod_wsgi and postgres related?19:25
bknudsonthis is great because we've got a team here runs keystone under mod_wsgi19:25
morganfainberggyee, it isn't19:25
morganfainbergbknudson, and this will make it so we can recommend mod_wsgi as the default deployment choice :)19:26
morganfainberggyee, the postgres thing was "it's expensive resource wise to run extra tempest runs just to test postgres"19:27
bknudsongyee: the discussion was dropping postgres testing because of gate issues... so I wouldn't expect them to take an extra keystone job for the same reason19:27
gyeei c19:27
morganfainberginstead they combined postgres w/ neutron and added a nova-specific test for nova-net+postgres19:27
*** hrybacki has quit IRC19:28
morganfainbergso except for nova patches, 1 lest tempest run19:28
gyeebkudson, I did setup Apache with mod_authnz_ldap enabled btw19:28
*** hrybacki has joined #openstack-keystone19:28
gyeein my local dev19:28
bknudsongyee: which external auth plugin?19:28
gyeeonly issue is it has to work in conjunction with basic auth19:28
gyeeI was investigating with mod_authnz_ldap performs any better than Keystone ldap code19:29
*** hrybacki has quit IRC19:30
bknudsonI can't imagine anything worse than keystone's ldap code efficiency-wise.19:30
gyeebknudson, you are right :)19:31
*** jsavak has joined #openstack-keystone19:31
*** joesavak has quit IRC19:34
*** beav has quit IRC19:34
morganfainbergdolphm, i don't know how to make keystoneclient (which provides CMS) depend on the middleware package without the middleware package depending on keystoneclient. do we need to split the ksc utility code (e.g. CMS) out to it's own package as well? does it move with the middleware?19:37
*** erecio has quit IRC19:37
bknudsonI don't think keystoneclient needs a hard requirement on middleware.19:37
dolphmmorganfainberg: oh - that's exactly what i was thinking when we talked about that at the summit - forgot about that19:37
jamielennoxbknudson: there is a backwards compatibility requirement19:37
morganfainbergbknudson, except that we want to provide the same location as a transition poiint?19:38
dolphmpython-keystoneclient, python-keystonemiddleware and keystone all depend on... python-keystonelib?19:38
bknudsony, import it but don't add the requirement19:38
bknudsonanybody wanting to use the optional feature will have to supply both of them19:38
morganfainbergbknudson, that doesn't really work for transition though, i don't think.19:39
morganfainbergdolphm, i think utility code should be external anyway (should it be oslo?)19:39
dolphmmorganfainberg: the cms module?19:39
morganfainbergdolphm, yeah.19:40
dolphmmorganfainberg: i don't think it should be oslo (it's not really cross-program)19:40
morganfainbergdolphm, works for me.19:40
bknudsonan application importing keystoneclient doesn't automatically import the middlware19:40
*** dims_ has joined #openstack-keystone19:40
morganfainbergbknudson, but right now applications getting the middleware expect it to be installed when you install the client19:40
bknudsonit would be nova, etc, that would have requirement on both19:40
morganfainbergcan we make that broken unless you install both packages?19:41
bknudsonone option is copy-paste the common parts for the transition period19:42
morganfainbergbknudson, options are: 1) copy-paste (ick), 2) split cms (etc) into keystonelib, 3) no hard-dep just the import in ksc19:42
bknudsonhow long is the transition period? a couple of weeks?19:42
morganfainbergbknudson, we went with a couple cycles when moving things from keystone to ksc19:43
jamielennoxmorganfainberg: right - but ksc shouldn't work like that19:43
*** gyee has quit IRC19:43
morganfainbergif we split cms out (not for or against) it does mean we don't need ksc for keystone to run. just the lighterweight lib19:43
dstanekmorganfainberg: do you want it to be broken if you don't explicitly install both?19:44
dstanekyou could have ksc depend on the new package for a transition period so that the other project can start explicitly depending on it19:44
morganfainbergdstanek, the only option i don't want is copy/pste19:44
jamielennoxmorganfainberg: i don't think this matters right - because CMS won't be the only dependency from auth_token -> ksc19:44
jamielennoxi think it is at the moment - but session etc are slowly coming across19:45
bknudsonauth_token is going to use session, too19:45
morganfainbergjamielennox, ah session eventually.19:45
bknudsonmaybe we need a keystone-session package?19:45
jamielennoxand auth plugins - and the idea was that auth_token should consume all this from ksc eventually so that users could replicate it19:45
jamielennoxstop having auth_token be such a special case19:45
morganfainbergi think that argues that we either do copy/paste or make it so a fail to import middleware says "hey go install X"19:46
bknudsonmy preference is skip the requirement on middleware in keystoneclient... seems like it's easy enough to install both.19:46
morganfainbergso both packages are explicitly installed to work19:46
bknudsonboth packages don't have to be installed to work...19:46
morganfainbergbknudson, maybe wrap a try/except with a nice message saying "keystonemiddleware package not installed" if you try and reference it from the old location?19:47
dstanekcan you have one without the other?19:47
bknudsononly to work when you're using keystoneclient middleware19:47
jamielennoxright the dependency should go middleware -> client, the problem is that will  break a lot of people on update19:47
bknudsondstanek: you can have keystoneclient without middleware19:47
bknudsonjamielennox: nova, etc, will have middleware added to requirements.txt19:48
*** leseb has joined #openstack-keystone19:48
morganfainbergjamielennox, so we get middleware in the global reqs and updated anywhere we can find and make the error very pleasant if you don't have it installed and try and source it from ksc.19:48
bknudsonmaybe we need a no-op middleware so that we can add it to nova, etc.19:48
jamielennoxso that will work for future, the problem is what if you have a icehouse or havana cloud and keystoneclient gets updated to this?19:49
bknudsony, it doesn't do anything. Then you can add it to nova requirements.txt19:49
morganfainbergor worse.. grizzly19:49
bknudsonthen change middleware to have auth_token19:49
bknudsonthen change nova,etc to use middleware.auth_token19:49
morganfainbergwe could update havana nad icehouse to have the new req19:49
bknudsonthen remove keystoneclient from nova,etc (if they don't use it)19:50
dstanekthe biggest problem is existing clouds will be broken if the client gets updated and the don't change their pipeline19:50
bknudsonwe could cap havana and icehouse19:50
morganfainberggrizzly is uncapped19:51
jamielennoxmy point was the current keystoneclient is tested and has compatibility hacks in place such that if you have essex or futher then you should be able to update auth_token and have it still work19:51
morganfainbergwe could break a lot of installs.19:51
bknudsongrizzly isn't supported19:51
morganfainbergbknudson, doesn't mean we should break it if we can avoid.19:51
morganfainbergmaybe we deprecate the current middleware and say "hey go use this new package"19:51
morganfainbergbut don't remove it for chunk of time19:51
dstanekwould id be bad to have ksc import the new package and wrap it in a deprecated warning?19:52
bknudsonseems like this is an issue for packagers.19:52
bknudsonas a packager, it's not going to affect us.19:52
morganfainbergdstanek, the new package needs code form ksc is the real core of the problem19:52
morganfainbergdstanek, circular deps19:52
bknudsonrpms can have circular dependencies19:52
dstanekmorganfainberg: haha, really? that's not good19:52
morganfainberghow does pip deal with them?19:52
dstaneki've never tried circular deps with pip19:53
morganfainbergless worried about rpm, don't think it's an issue with .deb19:53
*** leseb has quit IRC19:53
morganfainbergbknudson, ok that doesn't help me understand if this would work as a circular dep20:05
morganfainbergbknudson, it.. sounds like it would, but.. i'm not 100% sure20:05
*** marcoemorais has quit IRC20:07
*** marcoemorais has joined #openstack-keystone20:08
mfischI'm curious if anyone here monitors Keystone with Icinga20:15
mfischWe get seemingly random "requires authentication (401)" when trying to connect via the API20:15
mfischabout once every 2 hours20:15
ayoungmorganfainberg, if I put a log warning about using a deprecated value in get_token_provider  its going to spam the logs20:15
ayoungmfisch, token duration?  Are you reusing a token?20:16
mfischayoung: token duration is one hour, but the Icinga script does a user/pass auth with the python API20:16
mfischc = client.Client(username…)20:16
mfischthats whats failing20:16
ayoungmfisch, no clue, then20:16
mfischHey at least we're on the same page20:16
mfischI'll tell the monitoring guys they should be happy its not every time20:17
mfischThis is all the server says20:18
mfisch"keystone.common.wsgi [-] Authorization failed."20:18
*** praneshp has quit IRC20:19
*** jdennis has quit IRC20:19
*** rushiagr has quit IRC20:19
*** marcoemorais has quit IRC20:19
*** harlowja has quit IRC20:19
*** mgagne has quit IRC20:19
*** dolphm has quit IRC20:19
*** mhu has quit IRC20:19
*** zigo has quit IRC20:19
*** zhiyan_ has quit IRC20:19
*** chmouel has quit IRC20:19
*** shufflebot has quit IRC20:19
*** uvirtbot has quit IRC20:19
*** marcoemorais has joined #openstack-keystone20:20
*** harlowja has joined #openstack-keystone20:20
*** praneshp has joined #openstack-keystone20:20
*** mgagne has joined #openstack-keystone20:20
*** jdennis has joined #openstack-keystone20:20
*** rushiagr has joined #openstack-keystone20:20
*** dolphm has joined #openstack-keystone20:20
*** uvirtbot has joined #openstack-keystone20:20
*** chmouel has joined #openstack-keystone20:20
*** shufflebot has joined #openstack-keystone20:20
*** zigo has joined #openstack-keystone20:20
*** zhiyan_ has joined #openstack-keystone20:20
*** mhu has joined #openstack-keystone20:20
*** dickson.freenode.net sets mode: +o dolphm20:20
*** hrybacki has joined #openstack-keystone20:20
ayoungdolphm, so, I am unclear on your vision for the policy fetch.  Do we want to manage the default policy as a single file?20:22
*** daneyon_ has joined #openstack-keystone20:22
dolphmayoung: so, i'm first concerned about existing things in the policy backend (people have used the API for stuff already)20:22
dolphmayoung: but, yeah, i'm basically just thinking single blob20:23
ayoungdolphm, so we keep the existing code around which is "assign a new id when you upload"20:23
ayoungdolphm, OK, so what would happen with that single blob?  Would it be assumbled from fragments?20:23
ayounglive in oslo?20:24
mfischAfter corrlating the log files I have nothing but successful connections from the server side, perhaps python-keystoneclient is on crack20:24
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf  https://review.openstack.org/9501520:24
*** nkinder_ has quit IRC20:24
*** chandan_kumar has quit IRC20:24
*** thedodd has quit IRC20:24
*** andreaf has quit IRC20:24
*** xianghui has quit IRC20:24
*** gmurphy has quit IRC20:24
dolphmayoung: well, projects still need to document their own default policy expectations, right?20:24
dolphmayoung: so, what about a simple CLI tool to "compose one or more policy files together"20:25
dolphmayoung: like, keystone-manage combine-policies glance.policy.json nova.policy.json keystone.policy.json > single.policy.json20:26
ayoungdolphm, that is fine, and it can just explode if there are conflicts20:26
dolphmayoung: right20:26
ayoungdolphm, how are we going to fetch policy?20:26
ayoungsay, nova starts up,  and it does a GET 35357:v3/policy...what?20:27
ayoungfilter it based on the token that nova passes?20:27
*** dims_ has quit IRC20:28
ayoungdolphm, I don't think we want to have to update the policy ID anywhere20:30
*** dims_ has joined #openstack-keystone20:30
dolphmayoung: what if it just asked keystone for policies that applied to the current project context, and cached the result?20:31
ayoungdolphm, " current project context" definied how?  based on a users request?20:31
ayoungit means we'll have a lot of queries20:31
*** chandan_kumar has joined #openstack-keystone20:34
openstackgerritA change was merged to openstack/keystone: Add missing docstrings and 1 unittest for LDAP utf-8 fixes  https://review.openstack.org/9964620:34
dolphmayoung: yeah, we'll have a lot of queries until the cache is populated - not an elegant solution, but probably the simplest?20:36
*** gmurphy has joined #openstack-keystone20:36
*** andreaf_ has joined #openstack-keystone20:36
dstanekdolphm, ayoung: right now we have a policy file for each service that is stored on the service and completely managed there - what is the vision for where we should be? a centralized policy consumed by each service?20:36
*** nkinder_ has joined #openstack-keystone20:36
*** thedodd has joined #openstack-keystone20:36
*** andreaf has joined #openstack-keystone20:36
*** 17SAADOYF has joined #openstack-keystone20:36
*** xianghui has joined #openstack-keystone20:36
*** 17SAADOYF has quit IRC20:36
*** andreaf has quit IRC20:36
dolphmdstanek: well, "centralized policy management" is the foremost vision. but we've always stalled on how that should work20:37
*** marcoemorais has quit IRC20:37
dolphmdstanek: "how do i know which policy to ask for, or how do i ask for the right one?"20:37
dstanekdolphm: when ayoung and i were talking about it at the summit the biggest gap i had was how a real cloud operations team manages those files20:37
dolphmi think you can solve the "do i ask for the glance policy vs nova policy" by simply combining them into a single policy blob20:38
*** marcoemorais has joined #openstack-keystone20:38
dolphmdstanek: they use puppet/chef/etc20:38
*** marcoemorais has quit IRC20:38
dstanekdolphm: but are they managed by the same team typically or different?20:38
*** marcoemorais has joined #openstack-keystone20:38
dolphmso, the real use case here is when you complicate things with "this project should use a different policy file"20:38
dolphmwhich frankly i don't hear very often, but it has come up20:39
dstanekdolphm: is there a strong use case for that? seemed more like a "it would be cool if"20:40
dolphmdstanek: well, the sql policy backend will of course store a project_id if you hand it one, and then all you have to implement is a new bit of oslo.policy to ask for the right thing... i suspect people have already done it for themselves20:41
dolphmdstanek: but yes i agree - unless they speak up / demand first class support, i'd file it under "it would be cool if"20:41
dolphmit's also, possibly, an interesting alternative to the project-own-services-which-own-roles mess20:43
*** devlaps has joined #openstack-keystone20:46
*** hrybacki has quit IRC20:51
openstackgerritRyan Bak proposed a change to openstack/keystone: LDAP: Added documentation for debug_level option  https://review.openstack.org/9467920:55
*** leseb has joined #openstack-keystone20:59
*** juanmo1 has quit IRC20:59
*** hrybacki has joined #openstack-keystone21:00
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907621:00
*** radez is now known as radez_g0n321:02
*** nkinder_ has quit IRC21:03
*** hrybacki has quit IRC21:03
*** leseb has quit IRC21:04
*** gyee has joined #openstack-keystone21:04
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9626521:05
*** nkinder_ has joined #openstack-keystone21:07
*** amerine has quit IRC21:07
*** amerine has joined #openstack-keystone21:09
*** marcoemorais has quit IRC21:12
*** marcoemorais has joined #openstack-keystone21:12
*** marcoemorais has quit IRC21:13
*** marcoemorais has joined #openstack-keystone21:13
*** andreaf has joined #openstack-keystone21:16
dtroyer_zzdolphm, stevemar:  when you get a minute I'd like you guys' thoughts on https://review.openstack.org/#/c/69878/ and the 'xxx list' command bits we talked about in ATL.21:16
dtroyer_zz  I've re-worked the top of https://etherpad.openstack.org/p/openstackclient-commands to reflect where I think we are and what is in the queue today21:17
*** nkinder_ has quit IRC21:18
ayoungbknudson, morganfainberg so, I think I want to do something different on the "avoid tokenid in the log file patch"  I want to remove token_id from the token boy, and put in a different value:  call it tracking_id21:22
*** dstanek is now known as dstanek_zzz21:22
*** einarf has quit IRC21:24
bknudsonayoung: there's been some discussion on the mailing list of how to hide token_id, so that all projects do it the same way21:24
ayoungbknudson, so, lets not "hide" id21:25
bknudsonseems like the discussion should be there since it's not just keystone that's affected21:25
ayounglets provide a first class attribute for audit21:25
ayoungbknudson, I know, but I want the keystone team to chime in first21:25
bknudsonayoung: I think there was some work going on about a cross-project request ID21:25
bknudsonis that what you're thinking about?21:26
ayoungbknudson, I thought that was related but different, but I see how it could be the same thing.21:26
bknudsonI've thought that's something we should have21:27
ayoungit depends on if that is designed to tie together work done on multiple tokens, and whether it is OK if a token is reused and thus the request ID is used for two requests21:27
bknudsonat least have some way to connect the client's request with what's logged in the server log21:27
ayoungbut I think the sha1 approach is going to cause you pain21:27
ayoungbknudson, just like you had to remove MD5, you are going to have to remove SHA121:27
ayoungeven though there is no security implication21:27
ayoungits compliance21:27
bknudsonyes, the requirement is essentially don't use something < sha221:28
*** jsavak has quit IRC21:28
ayoungbknudson, so can you -2 that approach.  I'll be happy to dogpile on top of it21:28
bknudsonit's ok as long as it's configurable21:29
bknudsonand making it configurable can be a separate patch21:29
jamielennoxbknudson: let's not make a logging option like that configurable21:29
ayoungbknudson, nope21:29
ayoungit is not configurable21:29
bknudsony, it's pretty ridiculous21:29
ayoungbknudson, does the tracking ID make sense?21:30
bknudsonayoung: I haven't seen what it actually is21:30
ayoungbknudson, add an attribute to the token body21:30
ayoungits a uuid21:31
ayoungand it is used in audit logs21:31
jamielennoxayoung: so that becomes really horrible from an auth_plugin aspect21:31
ayoungjamielennox, nope21:31
*** andreaf has quit IRC21:31
jamielennoxthat's not a reason not to have it - just a pain21:31
jamielennoxclient side auth plugin21:31
ayoungjamielennox, auth_plugin can unpack the token to get it, but they alsio get it in the request to get a token in the first place21:31
ayoungthe body of the token is in the token request21:32
ayoungauthenticate response21:32
bknudsona lot of these tokens are logged by the clients21:32
bknudsonwhich don't have the token body21:32
bknudsone.g., nova calls glanceclient with a token21:32
jamielennoxso auth_plugins have a get_token method, we would need to add a get_token_tracker_id() as well i guess21:33
*** nkinder_ has joined #openstack-keystone21:33
bknudsonI always thought we should use part of the token21:34
bknudsonsince that's what I do when looking for tokens in logs anyways21:34
jamielennoxbknudson: yea, but we cant has it, we cant make it public...21:34
bknudsonwe cant has cheezburger?21:35
jamielennoxnot agreeing with ayoung necessarily about a tracking id21:35
bknudsonyea, that's a goofy one because you could potentially use the same hash algorithm21:36
bknudsonso logging the hash could potentially be the same as logging the token21:37
jamielennoxyep, morganfainberg and i were debating this the other day21:37
*** dims has joined #openstack-keystone21:37
jamielennoxhe was salting it but that appears to have disapeared21:39
*** dims_ has quit IRC21:39
bknudsonit really seems like the tracking ID is a really heavyweight solution to what seems like it should be pretty trivial21:39
bknudsonalthough we seem to have gotten a requirement that it has to be so obvious that no documentation is required21:39
bknudsonand it also needs to be a hash21:40
*** nsquare has quit IRC21:44
*** nsquare has joined #openstack-keystone21:46
*** morganfainberg has quit IRC21:50
*** morganfainberg has joined #openstack-keystone21:50
*** marcoemorais has quit IRC22:05
*** marcoemorais has joined #openstack-keystone22:06
ayoungtracking id can be put into the token before the singing/hashing.  Right now, the token_id in a PKI token is "placeholder"22:06
*** jamielennox is now known as jamielennox|away22:12
*** jamielennox|away is now known as jamielennox22:26
*** henrynash has quit IRC22:32
*** thedodd has quit IRC22:38
*** amerine has quit IRC22:41
*** nsquare has quit IRC22:44
*** amerine has joined #openstack-keystone22:44
*** nsquare has joined #openstack-keystone22:45
jamielennoxok, so keystoneclient review for people: https://review.openstack.org/#/c/95015/22:48
gyeejamielennox, do you have a patch that does version discovery and load auth plugin in session based on input?22:56
*** nikunj2512 has quit IRC22:58
*** gordc has quit IRC23:04
jamielennoxgyee: &^23:08
jamielennoxi think i have most of those components in review23:08
jamielennoxi don't know about the whole thing together23:08
*** gokrokve has quit IRC23:09
gyeejamielennox, sorry, was reviewing your code23:13
gyeejust a couple of minor suggestions23:13
jamielennoxgyee: then take all the time you need23:13
gyeejamielennox, https://review.openstack.org/#/c/96323/16/ceilometerclient/client.py23:14
gyeethe bug is reference here23:14
gyeebasically, for keystoneclient integration, we still need to do quite a bit of boilerplate stuff23:14
gyeelike version discovery, determining the correct auth plugin to use based on user input, etc23:15
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: JSON Home  https://review.openstack.org/9735923:15
gyeewould be nice if we can encapsulate all that in a utility method provided by keystoneclient23:15
gyeeI thought you were working on a patch23:15
gyeeif not, I can work on it23:15
jamielennoxgood to see people contributing here :023:16
*** nkinder_ has quit IRC23:16
gyeewell, I recruited a few amigos to help out :)23:16
gyeeok, maybe recruit is not the right word here23:17
jamielennoxok, so part of this is the Adapter you just looked at23:17
jamielennoxah - did you just look at23:17
jamielennoxlol, another client review for people: https://review.openstack.org/#/c/86237/23:18
gyeewait, Adapter does version discovery and all that?23:18
*** amerine has quit IRC23:18
jamielennoxthis is the core that i think most clients need23:18
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Catch AttributeError if no service catalog  https://review.openstack.org/10071423:18
ayoungjamielennox, there ya go^^23:18
jamielennoxno, it doesn't create the session for people23:18
gyeejamielennox, yeah, we need one that does all that boilerplate stuff23:18
jamielennoxayoung: return self.auth_ref and self.auth_ref.has_service_catalog()23:19
ayoungjamielennox, tomato tomaaahto23:19
ayoungjamielennox, it was that self.auth_ref  did have the attribute23:20
jamielennoxi did write that patch somewhere - i think i couldn't be bothered writing a test for it at the time so never put it up for review23:20
jamielennoxno auth_ref was None23:20
jamielennoxgyee: so who is creating the session23:20
jamielennoxayoung: from memory23:20
ayoungjamielennox, this catches it either way23:20
gyeejamielennox, all the client CLI does23:20
jamielennoxayoung: auth_ref should always be an AccessInfo if set23:20
*** amerine has joined #openstack-keystone23:20
jamielennoxgyee: https://review.openstack.org/#/c/95678/23:21
ayoungjamielennox, are you really going to make us change all of the config files for auth_token just to match heat?23:21
jamielennoxgyee: it's the v2/v3 auth plugin that's a problem23:21
jamielennoxayoung: that was the decision23:21
jamielennoxprobably people don't care23:22
jamielennoxcheck stevebaker and sdague on -dev23:22
gyeejamielennox, here's the problem, clients got a bunch of command line args, auth_url, user_id, username, tenant_id, etc23:22
jamielennoxconvince them and i'm good - i honestly don't care i just want them standard and to push this review along23:22
ayoungjamielennox, yeah, that ain't gonna fly23:22
ayoungbreaking every config everywhere == bad23:22
jamielennoxayoung: it'll still be deprecated23:23
gyeethey just need one utility method to do the following: 1) determine the right version to use based on the user  input; 2) determine the right auth plugin to use; and 3) return the session object23:23
ayoungjamielennox, deprecated == "must eventualyl change with not good reason"23:23
* ayoung looking for mailing list discussion23:23
jamielennoxgyee: so number 1 is kind of out of my control, 2 i hope to make an explicit flag --os-auht-plugin and 3 is the review above23:24
gyeeayoung, deprecated = "we are going to quietly pull the rug under you" :)23:24
ayounggyee, you agree with me on this, right?23:24
jamielennoxayoung:  [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object23:24
jamielennoxi probably should have put keystone on there - i was thinking it mostly unaffected23:25
jamielennoxit deteriorated a little on whether things should be called [nova] or [nova_client] which makes no difference at the moment, but heat wants it that way and sdague gave the nod on -dev, so i thought i was going the consensus way23:27
gyeejamielennox, where did you undeprecate the construct method? https://review.openstack.org/#/c/74599/723:27
jamielennoxgyee: oh, must be somewhere else - sorry23:28
jamielennoxgyee: i don't know - i can't keep all my reviews straight any more23:29
jamielennoxi agree it needs to come out23:29
gyeek, I'll +2 it23:29
gyeeeasy fix anyway23:29
jamielennoxis that Adapter or from_conf?23:30
gyeejamielennox, ah, you forgot DocImpact23:30
gyeeall those needs to be doc23:30
gyeejamielennox, if you can drop a TODO there for the auth_token change would be awesome23:30
jamielennoxgyee: so the from_conf i almost thing ayoung is right - we shouldn't change all those CONFs to match heat23:32
ayoung"almost" coming from you is high praise!23:32
gyeebut you have the deprecated param there right?23:32
gyeewe need to unify all these options anyway23:33
jamielennoxheh - yea, i can provide the deprecation - but we are talking about the default value throughout everywhere23:33
jamielennoxso it would mean transitioning auth_token in all CONF files from cafile -> ca_file and etc23:33
gyeecan't imagine we have to deal with cacert, cafile, ca-certfile23:33
jamielennoxi think it's probably better to enforce a lot of pain on one group (heat) than a little bit on everyone23:34
gyeeI think its worth the effort23:34
jamielennoxwhich one?23:35
gyeeunifying the config options across all openstack23:36
gyeesame way as common cli23:36
jamielennoxgyee: absolutely the choice is though to change auth_token or change heat23:36
ayoungjamielennox, auth_token means changing puppet23:37
ayoungand devstack23:37
gyeelets have a vote :)23:37
ayoungand chef23:37
ayoungand every deployment out there23:37
gyeedo it the democratic way23:37
ayounggyee, no23:37
jamielennoxgyee: the tree of us?23:37
ayoungwe just do it23:37
ayoungjust write it up and post the rationale23:37
ayoungdeprecate  the Heat options or support both23:38
jamielennoxgyee: which way are you going to vote?23:38
gyeeauth_token of course23:38
jamielennoxchange auth_token or keep auth_token23:38
gyeekeep the auth_token naming convention I mean23:38
jamielennoxok, that's 100% of my sample23:38
jamielennoxlet me change that back23:39
gyeegreat minds think alike23:39
gyeesorry ayoung23:39
ayounggyee, what are you sorry for23:40
gyeeayoung, nm, I was going to pull a great minds think alike joke23:41
*** gokrokve has joined #openstack-keystone23:43
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf  https://review.openstack.org/9501523:46
jamielennoxayoung, gyee: ^ looks like auth_token23:46
*** devlaps has quit IRC23:47
ayoungjamielennox, why does it show: Depedns on Changes exception raised by v3.trusts.update() (MERGED)23:47
jamielennoxayoung: no idea23:48
ayoungjamielennox, is there a "rebase" button on your ui?23:48
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf  https://review.openstack.org/9501523:49
ayoungthat's why23:49
jamielennoxayoung: did it in terminal - must have forgotten23:49
ayounglooks good23:49
ayoungjamielennox, so a better approach would be to pull the config section out of auth_token and use it in common to both locations.  I am not saying we should do that, though23:50
gyeejaimelennox, s/timeout/http_connection_timeout/23:50
gyeejamielennox, https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L23423:50
*** diegows has quit IRC23:51
morganfainbergayoung, i don't think the sha1 hashing is a compliance issue in that trackinid thing. misplaced -2, but that being said we can do something else/better but we need to do something soon.23:52
ayoungmorganfainberg, I confirmed with bknudson that it was23:52
ayoungit wasn't just "md5" but "all hashing < sha2"23:52
morganfainbergayoung, then we should also disable any hashing algorithms that aren't compliant23:52
gyeewtf? sha1 has compliance issue?23:52
morganfainbergayoung, unreleated23:52
jamielennoxmorganfainberg: i've heard suggestions of tjat23:53
gyeewhich industry? :)23:53
ayoungmorganfainberg, nah, we just should not hard code to  use any specific hashing algorithms for a specific purpose, so we can always move forward23:53
morganfainbergayoung, well we need some solution.23:53
gyeesorry, I mean SOX23:53
bknudsonit's a FIPS / NIST requirement23:53
ayoungmorganfainberg, put a tracking_id in the token23:53
morganfainbergayoung, sure.23:54
ayoungmorganfainberg, drop the token_id from it23:54
morganfainbergayoung, please remove the -2 i'll wIP it. rather keep the changeid23:54
bknudsonthe keystone server can now be configured to use a conforming hash algorithm so it's ok now23:54
morganfainbergor i'll -2 till we're good.23:54
morganfainbergayoung, ok i hit the -2 and WIP will update tonight or tomorrow with a plain tracking id or some sort23:55
jamielennoxmorganfainberg: i was waiting for that one to pass before i did the password logging one23:55
gyeemorganfainberg, just salt that sucker23:55
jamielennoxi might get in first with a conflict if yours is going to be an issue23:55
ayoungmorganfainberg, cool.  And we make that part of the official audit story, too.23:56
morganfainbergayoung, sure, works for me23:56
gyeegenerate a random salt and use it for the hash23:56
gyeeresult = <salt><hash>23:56
ayounggyee, no, no hashing, no salting lets do this right.  Make it such that the token tracking id is not a secret, and stays constant from start to finish23:56
ayoungno need23:57
jamielennoxhash.update('jamielennox :)')  # NOTE(jamielennox): IMMORTALITY !!23:57
morganfainbergayoung, yep works for me. and yeah no hashing.23:57
morganfainberggyee, hah23:58
morganfainberggyee, dry rub?23:58
ayoungok...what was I working on?23:58
morganfainbergayoung, not sure ;)23:58
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: JSON Home  https://review.openstack.org/9735923:58
ayounghttps://review.openstack.org/#/c/98897/  PKIZ23:58
morganfainbergayoung, ++23:59
ayoungmorganfainberg, gyee so I removed def test_token_format_provider_mismatch(self)23:59
jamielennoxgyee and ayoung: still don't have a vote on  https://review.openstack.org/#/c/86237/ and https://review.openstack.org/#/c/95015/23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!