| *** oomichi has quit IRC | 00:08 | |
| *** oomichi has joined #openstack-keystone | 00:16 | |
| openstackgerrit | Li Ma proposed a change to openstack/keystone: Fix the typo and reformat the comments for the added option https://review.openstack.org/98942 | 00:19 |
|---|---|---|
| *** richm has left #openstack-keystone | 00:20 | |
| *** ncoghlan has joined #openstack-keystone | 00:35 | |
| *** dims has joined #openstack-keystone | 00:38 | |
| openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Docstrings for usability. https://review.openstack.org/99755 | 00:39 |
| *** diegows has quit IRC | 00:39 | |
| *** dims has quit IRC | 00:43 | |
| *** rwsu has quit IRC | 00:52 | |
| ayoung | morganfainberg, if we -2 that spec can we just kill keystone to keystone federation? | 00:53 |
| morganfainberg | ayoung, no. it's a good idea. | 00:53 |
| morganfainberg | ayoung, but the spec needs ... work | 00:53 |
| ayoung | morganfainberg, I fear it | 00:53 |
| ayoung | I fear scope creep in Keystone | 00:53 |
| morganfainberg | ayoung, eh, lets see how it plays out. it might not work this cycle | 00:54 |
| ayoung | morganfainberg, 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 installs | 00:54 |
| ayoung | Authentication, sure | 00:54 |
| morganfainberg | ayoung, and that is what i'm pushing for. | 00:55 |
| ayoung | but Keystone tokens should not be used for Authentication | 00:55 |
| morganfainberg | ayoung, keystone providing identity only to an external keystone | 00:55 |
| morganfainberg | ayoung, via something like SAML2 or OpenID Coonnect | 00:55 |
| morganfainberg | ayoung, not authorization from a remote keystone | 00:55 |
| ayoung | morganfainberg, in which case, use SAML, and then this spec is not necessary | 00:55 |
| morganfainberg | ayoung, yep. working towards that (with a flexibility to do more than saml, e.g. pluggable for OpenID etc) | 00:56 |
| *** lbragstad has joined #openstack-keystone | 00:56 | |
| ayoung | morganfainberg, that is why I think we need to kill the spec | 00:56 |
| ayoung | it is not that keystone data shouldn't be shared | 00:56 |
| morganfainberg | ayoung, don't jump the gun. | 00:57 |
| ayoung | its that people don't understand what should not be in keystone data | 00:57 |
| morganfainberg | ayoung, it might morph into exactly what i described | 00:57 |
| ayoung | morganfainberg, In which case, it is "SAML from Keystone IdP" | 00:57 |
| ayoung | and this spec dies | 00:57 |
| ayoung | the 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 |
| morganfainberg | ayoung, no the spec wont die, the spec will be implementing SAML / OpenID from keystone | 00:58 |
| *** dstanek is now known as dstanek_zzz | 00:58 | |
| ayoung | morganfainberg, if Keystone is exporting SAML, then K2K is not a thing | 00:58 |
| morganfainberg | ayoung, 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 want | 00:58 |
| morganfainberg | lets use that. | 00:58 |
| ayoung | it is an instance of Samle 2Keystone | 00:58 |
| morganfainberg | ayoung, it _is_ it just is keystone provides SAML | 00:58 |
| morganfainberg | it's a different pronounciation of keystone 2 keystone | 00:59 |
| ayoung | morganfainberg, It just seems that they are following the famous lines from "The Boxer" | 00:59 |
| ayoung | I have squandered my resistance | 00:59 |
| ayoung | For a pocketful of mumbles, | 00:59 |
| ayoung | Such are promises | 00:59 |
| ayoung | All lies and jest | 00:59 |
| ayoung | Still, a man hears what he wants to hear | 00:59 |
| ayoung | And disregards the rest. | 00:59 |
| ayoung | anyways | 01:00 |
| ayoung | morganfainberg, 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 assumption | 01:03 |
| ayoung | morganfainberg, so it is going to be a mapping problem anyway: | 01:04 |
| morganfainberg | yes. | 01:04 |
| ayoung | if a user comes in with role X on P from K1, that needs to become role R on P2 from K2 | 01:04 |
| morganfainberg | ayoung, yep | 01:04 |
| ayoung | morganfainberg, which, I think means either flattening the role assignments to something like R_P | 01:05 |
| ayoung | as the group name | 01:05 |
| ayoung | or some more flexible mapping | 01:05 |
| ayoung | R1 from K1 becomes R2 from K2 across the board | 01:05 |
| ayoung | and P1 from K1 becomes P2 from K2 | 01:05 |
| ayoung | so then R1P1 maps to R2P2 implicitly | 01:06 |
| morganfainberg | ayoung, isn't this already covered by mapping - when you setup something like accepting SAML from a source? | 01:06 |
| openstackgerrit | A change was merged to openstack/keystone: Add instructions for removing pyc files to docs https://review.openstack.org/97140 | 01:06 |
| ayoung | morganfainberg, nope | 01:07 |
| ayoung | the mapping does not allow for breaking something like a role assignment apart | 01:08 |
| ayoung | so you could say | 01:08 |
| ayoung | R1 in P1 maps to the group R1_P1 | 01:08 |
| ayoung | but then you would need a separate rule for R2_P1 | 01:08 |
| ayoung | and R3_P1 | 01:09 |
| ayoung | but also an explicit rule for | 01:09 |
| ayoung | R1_P2 R2_P2 etc | 01:09 |
| ayoung | but 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 domains | 01:09 |
| ayoung | and I've written this up in the past. | 01:10 |
| ayoung | https://blueprints.launchpad.net/keystone/+spec/distributed-signing | 01:10 |
| ayoung | morganfainberg, more tactically: is https://review.openstack.org/#/c/98897/ OK? | 01:12 |
| *** dims has joined #openstack-keystone | 01:12 | |
| *** mberlin1 has joined #openstack-keystone | 01:12 | |
| morganfainberg | ayoung, let me look it over, but it's close if not there. | 01:13 |
| morganfainberg | and we need to figure out the issues w/ the apache deployment tempest even w/ compression | 01:13 |
| morganfainberg | http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/console.html | 01:13 |
| morganfainberg | did a local run of apache + UUID tokens here, passed w/o errors. | 01:13 |
| *** marcoemorais has quit IRC | 01:13 | |
| morganfainberg | so PKI under apache is still causing issues. | 01:14 |
| *** mberlin has quit IRC | 01:15 | |
| morganfainberg | and 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 log | 01:15 |
| *** sbfox has joined #openstack-keystone | 01:16 | |
| *** dstanek_zzz is now known as dstanek | 01:19 | |
| ayoung | morganfainberg pki under apache is not running with compression, and won't until ^^ passes | 01:23 |
| morganfainberg | ayoung, that log is from your patchset | 01:23 |
| morganfainberg | ayoung, it should be using PKIZ there | 01:23 |
| ayoung | ah...interesting... | 01:23 |
| *** hrybacki has joined #openstack-keystone | 01:23 | |
| morganfainberg | ayoung, i think we're still dropping errors with apache somewhere, i need to go digging into that | 01:24 |
| morganfainberg | oh interesting... we aren't capturing apache logs :P | 01:25 |
| morganfainberg | doh | 01:25 |
| ayoung | not other than Horizon | 01:25 |
| ayoung | http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/screen-key.txt.gz | 01:25 |
| morganfainberg | yeah let me propose a fix to infra to capture the root apache errorlog. how much you want to bet we have more info in that | 01:26 |
| morganfainberg | yeah i don't see the 500 errors in that log | 01:26 |
| morganfainberg | and we clearly have at least 1 500 generated from keystone if not more | 01:26 |
| ayoung | morganfainberg, what is that log at all? | 01:26 |
| ayoung | There should be no keystone screen for a local wsgi app | 01:26 |
| ayoung | it should be kicked off from HTTPD | 01:27 |
| morganfainberg | it is, it's tailing an apache log | 01:27 |
| morganfainberg | thats all the screen does, same as horizon | 01:27 |
| ayoung | exec /bin/bash -c 'cd /opt/stack/new/keystone && sudo tail -f /var/log/apache2/keystone' | 01:27 |
| ayoung | so that is the log we need | 01:27 |
| morganfainberg | which is what that screen log is | 01:28 |
| ayoung | morganfainberg, if it is the header issue, it won't show up in the keystone log | 01:28 |
| morganfainberg | ayoung, exactly | 01:28 |
| morganfainberg | ayoung, which is why we need to capture the root debug log. | 01:28 |
| morganfainberg | erm error log | 01:28 |
| morganfainberg | same way we capture localrc and the configs | 01:28 |
| morganfainberg | just another log to upload | 01:28 |
| ayoung | wait... | 01:28 |
| ayoung | there is the wsgi app ,and httpd error logf | 01:29 |
| ayoung | I guess ^^ is the wsgi app | 01:29 |
| ayoung | so, yeah, we need httpd/error_log | 01:29 |
| morganfainberg | yep | 01:29 |
| morganfainberg | ayoung, ++ | 01:29 |
| morganfainberg | ayoung, and if it's the same header issue / request length issue w/ compressed tokens | 01:29 |
| ayoung | OK, it looks like [token] provider is left with the default value | 01:29 |
| morganfainberg | ayoung, ... what is the next step? | 01:30 |
| ayoung | morganfainberg, debugging this was a PITA as I recall | 01:30 |
| morganfainberg | yep. | 01:30 |
| ayoung | I suspect all we will see in the HTTP log is "invalid header" or something like that | 01:30 |
| morganfainberg | wait you're seeing the provider as non PKIZ? | 01:30 |
| morganfainberg | oh oh right | 01:30 |
| morganfainberg | nvm. | 01:30 |
| ayoung | No, provider is pkiz | 01:30 |
| ayoung | http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/etc/keystone/keystone.conf.txt.gz | 01:30 |
| ayoung | grep provider= | 01:30 |
| *** dstanek is now known as dstanek_zzz | 01:30 | |
| morganfainberg | yeah | 01:31 |
| morganfainberg | see it now | 01:31 |
| ayoung | #provider=keystone.token.providers.pkiz.Provider but not overridden | 01:31 |
| morganfainberg | yep. | 01:31 |
| ayoung | morganfainberg, my guess is that somehow we are skipping the PKIZ code path | 01:33 |
| morganfainberg | ayoung, well i have a VM here that i can do a PKIZ run on and see what happens. | 01:34 |
| morganfainberg | ayoung, will be quicker than getting changes merged for config (for now) | 01:34 |
| ayoung | morganfainberg, yeah, that is what I was going to suggest | 01:34 |
| morganfainberg | i'll review the default PKIZ patch while i'm running tempest | 01:34 |
| ayoung | morganfainberg, I might be able to tell if they are PKIZ tokens from the logs | 01:35 |
| morganfainberg | though i don't see anything wrong with it. | 01:35 |
| ayoung | morganfainberg, do we log any tokens? | 01:35 |
| morganfainberg | uhm... | 01:35 |
| *** ncoghlan is now known as ncoghlan_afk | 01:35 | |
| *** nsquare has quit IRC | 01:37 | |
| morganfainberg | ayoung,http://paste.openstack.org/show/84231/ | 01:37 |
| morganfainberg | ayoung, looks like it claims to be PKIZ | 01:38 |
| morganfainberg | ayoung, also... doesn't look like it's compressing much | 01:38 |
| ayoung | "X-Auth-Token: PKIZ_ | 01:38 |
| *** ncoghlan_afk is now known as ncoghlan | 01:38 | |
| morganfainberg | ayoung, 3.4k with compression | 01:39 |
| morganfainberg | ayoung, i think... compression isn't going to solve the catalog problem. | 01:39 |
| ayoung | that should be small enough to fit through the headers | 01:39 |
| morganfainberg | ayoung, is it aggregate headers size or per header | 01:40 |
| morganfainberg | ayoung, it might be hitting an aggregrate size limit | 01:40 |
| *** xianghui has joined #openstack-keystone | 01:40 | |
| ayoung | no, just header | 01:40 |
| morganfainberg | well give me a few restoring my VM so i can do a clean run. | 01:40 |
| ayoung | there wasn't a problem until the headers hit 8k | 01:41 |
| ayoung | morganfainberg, WHERE'd you find that token? | 01:41 |
| morganfainberg | ayoung, http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/horizon_error.txt.gz | 01:42 |
| morganfainberg | it's not an error, but it shows we are hitting PKIZ code | 01:42 |
| ayoung | REQ: curl -i http://127.0.0.1:8776/v1/ae7b577c70ba4b3f917c0d1e78e1c0c0/limits | 01:42 |
| ayoung | what is 8776? | 01:42 |
| ayoung | its not keystone | 01:42 |
| ayoung | RESP: [200] | 01:42 |
| morganfainberg | right. | 01:43 |
| morganfainberg | it's nova | 01:43 |
| morganfainberg | but it shows we are issuing PKIZ tokens | 01:43 |
| morganfainberg | that is X-AUTH-TOKEN | 01:43 |
| ayoung | this is not the same problem... | 01:43 |
| ayoung | not the header size issue, I think | 01:43 |
| morganfainberg | well, let me get my VM up and running | 01:43 |
| ayoung | tempest/services/identity/v3/xml/identity_client.py | 01:44 |
| morganfainberg | oh ... i wonder | 01:45 |
| morganfainberg | have we exploded beyond XML capabilities? | 01:45 |
| ayoung | hmmm | 01:45 |
| ayoung | "tempest/services/identity/v3/xml/identity_client.py", line 522, in auth | 01:46 |
| ayoung | but | 01:46 |
| ayoung | https://github.com/openstack/tempest/blob/master/tempest/services/identity/xml/identity_client.py#L522 | 01:46 |
| *** topol has joined #openstack-keystone | 01:47 | |
| ayoung | there is no line 521. File "tempest/services/identity/v3/json/identity_client.py", line 521, in auth | 01:48 |
| morganfainberg | xml not json? | 01:48 |
| ayoung | neither | 01:49 |
| morganfainberg | hmm | 01:49 |
| ayoung | morganfainberg, and it is not a repo thing, either | 01:49 |
| ayoung | as the github and openstack repos agree | 01:49 |
| ayoung | I wonder if that error is in Keystone? | 01:49 |
| morganfainberg | well i'll get the tempest run going ... ~30more seconds | 01:52 |
| *** dstanek_zzz is now known as dstanek | 01:54 | |
| ayoung | morganfainberg, is it possible tempest is checked out from a branch? | 01:59 |
| morganfainberg | ayoung, uhm shouldn't be for master | 01:59 |
| morganfainberg | ayoung, i'm looking at the devstack gate code | 01:59 |
| ayoung | and there is only stable/havana | 01:59 |
| morganfainberg | yeah | 01:59 |
| ayoung | morganfainberg, ok, last stack trace startshere | 02:01 |
| ayoung | File "tempest/services/orchestration/json/orchestration_client.py", line 60, in create_stack | 02:01 |
| ayoung | http://git.openstack.org/cgit/openstack/tempest/tree/tempest/services/orchestration/json/orchestration_client.py#n60 | 02:01 |
| hrybacki | ayoung: if there were no complaints after rebasing does that mean there were no conflicts? | 02:01 |
| ayoung | uri = 'stacks' | 02:02 |
| morganfainberg | ayoung, running tempest now, as soon as I have a traceback i'll let you know | 02:02 |
| ayoung | hrybacki, yes | 02:02 |
| hrybacki | ayoung: huh. I thought for sure there would be something. | 02:02 |
| morganfainberg | hrybacki, git is pretty smart | 02:02 |
| ayoung | hrybacki, I'm kinda heads down, and about to head to bed | 02:02 |
| ayoung | morganfainberg, so that looks like it is calling heat, right? | 02:03 |
| hrybacki | ayoung: nods, take care | 02:03 |
| hrybacki | morganfainberg: apparently :) | 02:03 |
| morganfainberg | ayoung, yeah that looks like a heat thing | 02:03 |
| morganfainberg | orchestration | 02:03 |
| ayoung | morganfainberg, I wonder if somehow they missed the auth_token middleware update? | 02:03 |
| ayoung | Or...if they are doing something wonky with the tokens? | 02:04 |
| morganfainberg | ayoung, how? it uses the latest release of ksc | 02:04 |
| ayoung | morganfainberg, yeah, just ruminating | 02:04 |
| morganfainberg | ayoung, remember we are also seeing direct failures in the identity scenarios | 02:04 |
| morganfainberg | even though we can't figure out from where | 02:04 |
| ayoung | might be in the heat log | 02:04 |
| morganfainberg | in fact, the first failure is an identity scenario failure | 02:05 |
| *** ncoghlan is now known as ncoghlan_afk | 02: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 |
| ayoung | from http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/screen-h-api.txt.gz | 02:05 |
| ayoung | so the problem seems to be in keystone | 02:05 |
| *** sbfox has quit IRC | 02:06 | |
| morganfainberg | ayoung, yeah, that doesn't surprise me | 02:06 |
| *** sbfox has joined #openstack-keystone | 02:06 | |
| ayoung | Auth token not in the request header. Will not build auth context. process_request /opt/stack/new/keystone/keystone/middleware/core.py:271 | 02:06 |
| *** sbfox has quit IRC | 02:07 | |
| morganfainberg | is that the ISE? | 02:07 |
| ayoung | http://logs.openstack.org/97/98897/7/check/check-tempest-dsvm-full-apache-services/e40581d/logs/screen-key.txt.gz | 02:08 |
| ayoung | morganfainberg, time on that one was: [Mon Jun 16 22:36:08 2014] | 02:08 |
| morganfainberg | ayoung, don't think that's it | 02:09 |
| morganfainberg | i se 2800 of those log lines | 02:09 |
| morganfainberg | see* | 02:09 |
| morganfainberg | in that log | 02:09 |
| *** gordc has joined #openstack-keystone | 02:10 | |
| morganfainberg | i thnk we print that anytime we don't have a token (including POST) | 02:10 |
| morganfainberg | for auth | 02:10 |
| *** ncoghlan_afk is now known as ncoghlan | 02:10 | |
| morganfainberg | ayoung, seeing this http://paste.openstack.org/show/84232/ | 02:21 |
| *** browne has quit IRC | 02:21 | |
| morganfainberg | ayoung, that is ceiliometer. | 02:21 |
| ayoung | morganfainberg, hmmm, doesn't smell right | 02:22 |
| ayoung | morganfainberg, is the system accessable? | 02:22 |
| morganfainberg | ayoung, ? | 02:22 |
| ayoung | morganfainberg, is it something I could log in to? | 02:22 |
| ayoung | if not, then | 02:23 |
| morganfainberg | this is a VM on my laptop | 02:23 |
| morganfainberg | negative. | 02:23 |
| ayoung | http://adam.younglogic.com/2013/07/troubleshooting-pki-middleware/ | 02:23 |
| ayoung | specifically | 02:23 |
| ayoung | curl http://localhost:35357/v2.0/certificates/signing | 02:23 |
| *** marcoemorais has joined #openstack-keystone | 02:23 | |
| morganfainberg | ayoung, works fine | 02:24 |
| ayoung | morganfainberg, are the files in /etc/keystone/ssl.... the same as the ones cached for ceilometer? | 02:24 |
| ayoung | morganfainberg, what is signing_dir set to for ceilometer? | 02:25 |
| morganfainberg | ayoung, they are the same | 02:25 |
| morganfainberg | ayoung /var/cache/celiometer | 02:25 |
| ayoung | morganfainberg, permissions? | 02:25 |
| morganfainberg | stack/stack 600 | 02:26 |
| morganfainberg | it is fine | 02:26 |
| morganfainberg | and i think i didn't see the same error as the gate run | 02:27 |
| *** ncoghlan is now known as ncoghlan_afk | 02:27 | |
| morganfainberg | crap | 02:27 |
| morganfainberg | ... | 02:27 |
| morganfainberg | i forgot to set apache to debug. | 02:28 |
| ayoung | morganfainberg, I have to crash.... | 02:28 |
| ayoung | I'll look into it tomorrow if you don't find a smoking guy | 02:28 |
| ayoung | gun | 02:28 |
| morganfainberg | ayoung, yeah | 02:28 |
| morganfainberg | ayoung, ssee ya later | 02:28 |
| ayoung | watchout for the smoking man | 02:28 |
| ayoung | morganfainberg, btw | 02:29 |
| ayoung | File "/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py", line 1309, in _fetch_cert_file is not what I have from master | 02:29 |
| ayoung | _fetch_cert_file is line 1461 in master | 02:29 |
| *** ayoung is now known as ayoung_ZZZzzz | 02:30 | |
| morganfainberg | ayoung_ZZZzzz, i think if found it. | 02:32 |
| morganfainberg | maybe. | 02:33 |
| *** lbragstad has quit IRC | 02:35 | |
| *** marcoemorais1 has joined #openstack-keystone | 02:35 | |
| *** marcoemorais has quit IRC | 02:37 | |
| *** praneshp has quit IRC | 02:41 | |
| morganfainberg | ayoung_ZZZzzz, [Mon Jun 16 18:41:21 2014] [error] [client 127.0.0.1] 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 127.0.0.1] TypeError: expected byte string object for header value, value of type unicode found | 02:42 |
| *** leseb has joined #openstack-keystone | 02:42 | |
| *** ncoghlan_afk is now known as ncoghlan | 02:46 | |
| *** dstanek is now known as dstanek_zzz | 02:46 | |
| *** leseb has quit IRC | 02:46 | |
| *** sbfox has joined #openstack-keystone | 02:49 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Default to PKIZ tokens https://review.openstack.org/98897 | 02:54 |
| morganfainberg | ayoung_ZZZzzz, ^ added the str() coersion from the token cms call. unicode biting us again | 02:55 |
| *** hrybacki has quit IRC | 02:56 | |
| *** ncoghlan is now known as ncoghlan_afk | 02:57 | |
| *** gordc has quit IRC | 03:00 | |
| *** ayoung_ZZZzzz has quit IRC | 03:00 | |
| *** hrybacki has joined #openstack-keystone | 03:00 | |
| *** stevemar has joined #openstack-keystone | 03:08 | |
| *** lbragstad has joined #openstack-keystone | 03:09 | |
| *** gordc has joined #openstack-keystone | 03:16 | |
| *** praneshp has joined #openstack-keystone | 03:19 | |
| *** praneshp_ has joined #openstack-keystone | 03:20 | |
| *** praneshp has quit IRC | 03:24 | |
| *** praneshp_ is now known as praneshp | 03:24 | |
| *** zhiyan_ is now known as zhiyan | 03:28 | |
| *** harlowja is now known as harlowja_away | 03:37 | |
| *** harlowja_away is now known as harlowja | 03:39 | |
| *** leseb has joined #openstack-keystone | 03:43 | |
| *** leseb has quit IRC | 03:47 | |
| *** dstanek_zzz is now known as dstanek | 03:47 | |
| *** daneyon has joined #openstack-keystone | 03:50 | |
| *** daneyon has quit IRC | 03:50 | |
| *** daneyon has joined #openstack-keystone | 03:51 | |
| *** dstanek is now known as dstanek_zzz | 03:57 | |
| *** sbfox has quit IRC | 04:04 | |
| *** hrybacki has quit IRC | 04:07 | |
| *** henrynash has joined #openstack-keystone | 04:17 | |
| *** sbfox has joined #openstack-keystone | 04:20 | |
| *** leseb has joined #openstack-keystone | 04:44 | |
| *** leseb has quit IRC | 04:48 | |
| *** gyee has quit IRC | 04:51 | |
| *** gordc has quit IRC | 04:53 | |
| *** dims has quit IRC | 04:58 | |
| *** stevemar has quit IRC | 04:58 | |
| *** stevemar has joined #openstack-keystone | 05:03 | |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Using six.u('') instead of u'' https://review.openstack.org/100082 | 05:04 |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Added help text for the debug option https://review.openstack.org/99312 | 05:06 |
| *** ajayaa has joined #openstack-keystone | 05:06 | |
| *** ajayaa has quit IRC | 05:11 | |
| *** zhiyan is now known as zhiyan_ | 05:20 | |
| *** ajayaa has joined #openstack-keystone | 05:24 | |
| *** stevemar has quit IRC | 05:25 | |
| *** stevemar has joined #openstack-keystone | 05:26 | |
| *** henrynash has quit IRC | 05:29 | |
| *** gmurphy has joined #openstack-keystone | 05:30 | |
| *** leseb has joined #openstack-keystone | 05:44 | |
| *** harlowja is now known as harlowja_away | 05:48 | |
| *** leseb has quit IRC | 05:49 | |
| *** ajayaa has quit IRC | 05:49 | |
| *** daneyon has quit IRC | 05:54 | |
| *** stevemar has quit IRC | 06:00 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/97005 | 06:00 |
| *** ajayaa has joined #openstack-keystone | 06:00 | |
| *** zhiyan_ is now known as zhiyan | 06:02 | |
| *** oomichi has quit IRC | 06:07 | |
| *** oomichi has joined #openstack-keystone | 06:17 | |
| *** sbfox has quit IRC | 06:26 | |
| *** topol has quit IRC | 06:31 | |
| *** afazekas_ has joined #openstack-keystone | 06:32 | |
| *** marcoemorais1 has quit IRC | 06:36 | |
| *** chandan_kumar has quit IRC | 06:38 | |
| *** leseb has joined #openstack-keystone | 06:45 | |
| *** tomoiaga has joined #openstack-keystone | 06:49 | |
| *** leseb has quit IRC | 06:50 | |
| *** BAKfr has joined #openstack-keystone | 07:04 | |
| tomoiaga | I 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 token | 07:05 |
| *** leseb has joined #openstack-keystone | 07:06 | |
| *** leseb_ has joined #openstack-keystone | 07:08 | |
| *** leseb has quit IRC | 07:11 | |
| *** ncoghlan_afk is now known as ncoghlan | 07:16 | |
| *** henrynash has joined #openstack-keystone | 07: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 |
| jamielennox | tomoiaga: another way to do it would be to take the session object and pass that in next time | 07:52 |
| jamielennox | or better yet construct the session first, then create multiple clients with that session | 07:52 |
| tomoiaga | jamielennox: 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 session | 07:53 |
| tomoiaga | jamielennox: it's a good thing you post new stuff on your blog, it helps a lot, thanks! :) | 07:54 |
| jamielennox | tomoiaga: it's a good thing i started posting that stuff at all - it's getting it out that's the issue | 07:54 |
| jamielennox | interesting - so i was expecting this to come up at some point but i wasn't aware anyone was using it yet | 07:55 |
| jamielennox | so you are serializing the auth_ref? | 07:55 |
| jamielennox | i've always expected that i need to provide a way to serialize an auth_plugin | 07:56 |
| tomoiaga | jamielennox: 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 |
| jamielennox | yea, it will - but i consider that the 'old way', i just don't necessarily have a 'new way' yet | 07:58 |
| jamielennox | tomoiaga: it would be fairly trivial to write your own plugin that just accepted an existing auth_ref, handle the serialization yourself | 07:59 |
| tomoiaga | jamielennox: 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 that | 08:00 |
| jamielennox | if you pass session there won't be an initial auth post | 08:00 |
| tomoiaga | jamielennox: 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 |
| jamielennox | tomoiaga: look at https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/identity/base.py#L48 | 08:05 |
| jamielennox | if you override that the only function you need to provide is get_auth_ref | 08: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 IRC | 08:16 | |
| *** gmurphy has quit IRC | 08:16 | |
| *** _elmiko has quit IRC | 08:16 | |
| *** amerine has quit IRC | 08:16 | |
| *** mfisch has quit IRC | 08:16 | |
| *** raildo has quit IRC | 08:16 | |
| *** tomoiaga has quit IRC | 08:16 | |
| *** Chicago has quit IRC | 08:16 | |
| *** thiagop has quit IRC | 08:16 | |
| *** d0ugal has quit IRC | 08:16 | |
| *** jdennis has quit IRC | 08:16 | |
| *** rushiagr has quit IRC | 08:16 | |
| *** morganfainberg has quit IRC | 08:16 | |
| *** harlowja_away has quit IRC | 08:16 | |
| *** mgagne has quit IRC | 08:16 | |
| *** dolphm has quit IRC | 08:16 | |
| *** mhu has quit IRC | 08:16 | |
| *** zigo has quit IRC | 08:16 | |
| *** zhiyan has quit IRC | 08:16 | |
| *** chmouel has quit IRC | 08:16 | |
| *** shufflebot has quit IRC | 08:16 | |
| *** uvirtbot has quit IRC | 08:16 | |
| *** boris-42 has quit IRC | 08:16 | |
| *** vhoward has quit IRC | 08:16 | |
| *** openstackgerrit has quit IRC | 08:16 | |
| *** jimbaker has quit IRC | 08:16 | |
| *** oomichi has quit IRC | 08:16 | |
| *** ajayaa has quit IRC | 08:16 | |
| *** lbragstad has quit IRC | 08:16 | |
| *** jamielennox has quit IRC | 08:16 | |
| *** henrynash has quit IRC | 08:16 | |
| *** afazekas_ has quit IRC | 08:16 | |
| *** praneshp has quit IRC | 08:16 | |
| *** mberlin1 has quit IRC | 08:16 | |
| *** dhellmann has quit IRC | 08:16 | |
| *** bobt has quit IRC | 08:16 | |
| *** rodrigods has quit IRC | 08:16 | |
| *** afazekas has quit IRC | 08:16 | |
| *** htruta has quit IRC | 08:16 | |
| *** tellesnobrega has quit IRC | 08:16 | |
| *** jkappert has quit IRC | 08:16 | |
| *** anteaya has quit IRC | 08:16 | |
| *** leseb_ has quit IRC | 08:16 | |
| *** BAKfr has quit IRC | 08:16 | |
| *** dtroyer_zz has quit IRC | 08:16 | |
| *** ekarlso has quit IRC | 08:16 | |
| *** arunkant has quit IRC | 08:16 | |
| *** ctracey has quit IRC | 08:16 | |
| *** baffle has quit IRC | 08:16 | |
| *** serverascode has quit IRC | 08:16 | |
| *** ChanServ has quit IRC | 08:16 | |
| *** toddnni_ has quit IRC | 08:16 | |
| *** ncoghlan has quit IRC | 08:17 | |
| *** huats has quit IRC | 08:17 | |
| *** dstanek_zzz has quit IRC | 08:17 | |
| *** gpocentek has quit IRC | 08:17 | |
| *** Mikalv has quit IRC | 08:17 | |
| *** comstud has quit IRC | 08:17 | |
| *** ByteSore has quit IRC | 08:17 | |
| *** esmute has quit IRC | 08:17 | |
| *** radez_g0n3 has quit IRC | 08:17 | |
| *** Daviey has quit IRC | 08:17 | |
| *** jaosorior has joined #openstack-keystone | 08:21 | |
| *** leseb_ has joined #openstack-keystone | 08:21 | |
| *** BAKfr has joined #openstack-keystone | 08:21 | |
| *** afazekas_ has joined #openstack-keystone | 08:21 | |
| *** oomichi has joined #openstack-keystone | 08:21 | |
| *** ajayaa has joined #openstack-keystone | 08:21 | |
| *** praneshp has joined #openstack-keystone | 08:21 | |
| *** lbragstad has joined #openstack-keystone | 08:21 | |
| *** mberlin1 has joined #openstack-keystone | 08:21 | |
| *** ncoghlan has joined #openstack-keystone | 08:21 | |
| *** dhellmann has joined #openstack-keystone | 08:21 | |
| *** vhoward has joined #openstack-keystone | 08:21 | |
| *** bobt has joined #openstack-keystone | 08:21 | |
| *** rodrigods has joined #openstack-keystone | 08:21 | |
| *** openstackgerrit has joined #openstack-keystone | 08:21 | |
| *** gpocentek has joined #openstack-keystone | 08:21 | |
| *** afazekas has joined #openstack-keystone | 08:21 | |
| *** huats has joined #openstack-keystone | 08:21 | |
| *** jimbaker has joined #openstack-keystone | 08:21 | |
| *** htruta has joined #openstack-keystone | 08:21 | |
| *** jamielennox has joined #openstack-keystone | 08:21 | |
| *** boris-42 has joined #openstack-keystone | 08:21 | |
| *** tellesnobrega has joined #openstack-keystone | 08:21 | |
| *** jkappert has joined #openstack-keystone | 08:21 | |
| *** anteaya has joined #openstack-keystone | 08:21 | |
| *** dtroyer_zz has joined #openstack-keystone | 08:21 | |
| *** arunkant has joined #openstack-keystone | 08:21 | |
| *** esmute has joined #openstack-keystone | 08:21 | |
| *** ekarlso has joined #openstack-keystone | 08:21 | |
| *** radez_g0n3 has joined #openstack-keystone | 08:21 | |
| *** Daviey has joined #openstack-keystone | 08:21 | |
| *** toddnni_ has joined #openstack-keystone | 08:21 | |
| *** ctracey has joined #openstack-keystone | 08:21 | |
| *** dstanek_zzz has joined #openstack-keystone | 08:21 | |
| *** baffle has joined #openstack-keystone | 08:21 | |
| *** comstud has joined #openstack-keystone | 08:21 | |
| *** serverascode has joined #openstack-keystone | 08:21 | |
| *** Mikalv has joined #openstack-keystone | 08:21 | |
| *** ByteSore has joined #openstack-keystone | 08:21 | |
| *** ChanServ has joined #openstack-keystone | 08:21 | |
| *** dickson.freenode.net sets mode: +o ChanServ | 08:21 | |
| *** tomoiaga has joined #openstack-keystone | 08:22 | |
| *** gmurphy has joined #openstack-keystone | 08:22 | |
| *** xianghui has joined #openstack-keystone | 08:22 | |
| *** _elmiko has joined #openstack-keystone | 08:22 | |
| *** harlowja_away has joined #openstack-keystone | 08:22 | |
| *** raildo has joined #openstack-keystone | 08:22 | |
| *** Chicago has joined #openstack-keystone | 08:22 | |
| *** amerine has joined #openstack-keystone | 08:22 | |
| *** mgagne has joined #openstack-keystone | 08:22 | |
| *** mfisch has joined #openstack-keystone | 08:22 | |
| *** thiagop has joined #openstack-keystone | 08:22 | |
| *** d0ugal has joined #openstack-keystone | 08:22 | |
| *** jdennis has joined #openstack-keystone | 08:22 | |
| *** rushiagr has joined #openstack-keystone | 08:22 | |
| *** dolphm has joined #openstack-keystone | 08:22 | |
| *** mhu has joined #openstack-keystone | 08:22 | |
| *** zhiyan has joined #openstack-keystone | 08:22 | |
| *** zigo has joined #openstack-keystone | 08:22 | |
| *** shufflebot has joined #openstack-keystone | 08:22 | |
| *** chmouel has joined #openstack-keystone | 08:22 | |
| *** uvirtbot has joined #openstack-keystone | 08:22 | |
| *** dickson.freenode.net sets mode: +o dolphm | 08:22 | |
| *** morganfainberg has joined #openstack-keystone | 08:22 | |
| *** dickson.freenode.net sets mode: +o morganfainberg | 08:22 | |
| *** d0ugal has quit IRC | 08:24 | |
| *** d0ugal_ has joined #openstack-keystone | 08:24 | |
| *** d0ugal_ is now known as d0ugal | 08:25 | |
| *** d0ugal has quit IRC | 08:25 | |
| *** d0ugal has joined #openstack-keystone | 08:25 | |
| tomoiaga | jamielennox: it seems to be working like a charm, thank you again :) | 08:26 |
| jamielennox | tomoiaga: excellent - no problem | 08:27 |
| *** mfisch` has joined #openstack-keystone | 08:27 | |
| *** mfisch has quit IRC | 08:27 | |
| *** _elmiko has quit IRC | 08:27 | |
| *** _elmiko has joined #openstack-keystone | 08:31 | |
| *** xianghui has quit IRC | 08:33 | |
| *** gmurphy has quit IRC | 08:33 | |
| *** amerine has quit IRC | 08:33 | |
| *** raildo has quit IRC | 08:33 | |
| *** tomoiaga has quit IRC | 08:33 | |
| *** Chicago has quit IRC | 08:33 | |
| *** thiagop has quit IRC | 08:33 | |
| *** jdennis has quit IRC | 08:33 | |
| *** rushiagr has quit IRC | 08:33 | |
| *** harlowja_away has quit IRC | 08:33 | |
| *** mgagne has quit IRC | 08:33 | |
| *** dolphm has quit IRC | 08:33 | |
| *** mhu has quit IRC | 08:33 | |
| *** zigo has quit IRC | 08:33 | |
| *** zhiyan has quit IRC | 08:33 | |
| *** chmouel has quit IRC | 08:33 | |
| *** shufflebot has quit IRC | 08:33 | |
| *** uvirtbot has quit IRC | 08:33 | |
| *** mfisch` has quit IRC | 08:35 | |
| *** mfisch has joined #openstack-keystone | 08:35 | |
| *** mfisch has quit IRC | 08:35 | |
| *** mfisch has joined #openstack-keystone | 08:35 | |
| *** praneshp has quit IRC | 08:37 | |
| *** jimbaker has quit IRC | 08:38 | |
| *** tomoiaga has joined #openstack-keystone | 08:43 | |
| *** gmurphy has joined #openstack-keystone | 08:43 | |
| *** xianghui has joined #openstack-keystone | 08:43 | |
| *** harlowja_away has joined #openstack-keystone | 08:43 | |
| *** raildo has joined #openstack-keystone | 08:43 | |
| *** Chicago has joined #openstack-keystone | 08:43 | |
| *** amerine has joined #openstack-keystone | 08:43 | |
| *** mgagne has joined #openstack-keystone | 08:43 | |
| *** thiagop has joined #openstack-keystone | 08:43 | |
| *** jdennis has joined #openstack-keystone | 08:43 | |
| *** mhu has joined #openstack-keystone | 08:43 | |
| *** zhiyan has joined #openstack-keystone | 08:43 | |
| *** zigo has joined #openstack-keystone | 08:43 | |
| *** shufflebot has joined #openstack-keystone | 08:43 | |
| *** chmouel has joined #openstack-keystone | 08:43 | |
| *** uvirtbot has joined #openstack-keystone | 08:43 | |
| *** dolphm has joined #openstack-keystone | 08:43 | |
| *** rushiagr has joined #openstack-keystone | 08:43 | |
| *** dickson.freenode.net sets mode: +o dolphm | 08:43 | |
| *** jimbaker has joined #openstack-keystone | 08:47 | |
| *** jimbaker has quit IRC | 08:47 | |
| *** jimbaker has joined #openstack-keystone | 08:47 | |
| *** leseb has joined #openstack-keystone | 08:49 | |
| *** leseb_ has quit IRC | 08:52 | |
| *** andreaf has joined #openstack-keystone | 08:55 | |
| *** jimbaker is now known as 77CAADFPS | 08:55 | |
| *** leseb_ has joined #openstack-keystone | 08:57 | |
| *** henrynash has joined #openstack-keystone | 09:01 | |
| *** leseb has quit IRC | 09:01 | |
| *** openstackgerrit_ has joined #openstack-keystone | 09:08 | |
| *** leseb_ has quit IRC | 09:11 | |
| *** leseb has joined #openstack-keystone | 09:15 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Document authentication plugins https://review.openstack.org/84071 | 09:17 |
| *** leseb has quit IRC | 09:18 | |
| *** ncoghlan has quit IRC | 09:21 | |
| *** leseb has joined #openstack-keystone | 09:25 | |
| *** dims_ has joined #openstack-keystone | 09:27 | |
| openstackgerrit | Steven Hardy proposed a change to openstack/keystone-specs: Spec for trusts redelegation https://review.openstack.org/99908 | 09:27 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session Adapters https://review.openstack.org/86237 | 09:27 |
| openstackgerrit | Steven Hardy proposed a change to openstack/keystone-specs: Spec for trusts redelegation https://review.openstack.org/99908 | 09:29 |
| *** dims_ has quit IRC | 09:32 | |
| *** Gippa has joined #openstack-keystone | 09:34 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Add oslo-incubator fixtures https://review.openstack.org/100470 | 09:51 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session Adapters https://review.openstack.org/86237 | 10:10 |
| openstackgerrit | Marek Denis proposed a change to openstack/python-keystoneclient: Implement SAML2 ECP authentication https://review.openstack.org/92166 | 10:11 |
| *** openstackgerrit_ has joined #openstack-keystone | 10:15 | |
| *** leseb has quit IRC | 10:17 | |
| *** leseb has joined #openstack-keystone | 10:17 | |
| *** leseb has quit IRC | 10:22 | |
| *** Gippa has quit IRC | 10:27 | |
| *** topol has joined #openstack-keystone | 10:32 | |
| *** Chicago has quit IRC | 10:56 | |
| *** dims_ has joined #openstack-keystone | 11:09 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone-specs: Always use sha1 for cross backend unique identifiers https://review.openstack.org/100497 | 11:13 |
| openstackgerrit | henry-nash proposed a change to openstack/keystone-specs: Always use sha1 for cross backend unique identifiers https://review.openstack.org/100497 | 11:18 |
| openstackgerrit | henry-nash proposed a change to openstack/keystone-specs: Always use sha1 for cross backend unique identifiers https://review.openstack.org/100497 | 11:19 |
| *** diegows has joined #openstack-keystone | 11:38 | |
| *** nikunj2512 has joined #openstack-keystone | 11:47 | |
| nikunj2512 | Hi | 11:55 |
| nikunj2512 | I need some help regarding keystone api | 11:55 |
| *** nikunj2512 has quit IRC | 12:00 | |
| *** AndChat|89889 has joined #openstack-keystone | 12:00 | |
| AndChat|89889 | Hi.. I need some help with Keystone api.. | 12:01 |
| AndChat|89889 | I am implementing email update in the horizon UI and need help with Keystone V2 api | 12:03 |
| *** juanmo has joined #openstack-keystone | 12:07 | |
| *** dims_ has quit IRC | 12:13 | |
| *** leseb has joined #openstack-keystone | 12:40 | |
| *** leseb has quit IRC | 12:43 | |
| *** leseb has joined #openstack-keystone | 12:43 | |
| *** Gippa has joined #openstack-keystone | 12:44 | |
| Gippa | ls | 12:45 |
| *** joesavak has joined #openstack-keystone | 12:51 | |
| *** gordc has joined #openstack-keystone | 12:54 | |
| *** _elmiko is now known as elmiko | 12:56 | |
| *** bknudson has joined #openstack-keystone | 12:57 | |
| *** bknudson has left #openstack-keystone | 12:58 | |
| *** bknudson has joined #openstack-keystone | 12:58 | |
| *** radez_g0n3 is now known as radez | 13:06 | |
| *** dstanek_zzz is now known as dstanek | 13:09 | |
| marekd | morganfainberg: hello. As long you guys are not meeting at my 3am I should be able to join :-) | 13:11 |
| *** richm has joined #openstack-keystone | 13:11 | |
| *** ayoung has joined #openstack-keystone | 13:15 | |
| *** erecio has joined #openstack-keystone | 13:17 | |
| *** zhiyan is now known as zhiyan_ | 13:17 | |
| *** AndChat|89889 has quit IRC | 13:19 | |
| joesavak | yo marekd! | 13:23 |
| marekd | joesavak: hey! | 13:23 |
| joesavak | we're meeting in about 90 minutes (10a central) to discuss federation again | 13:23 |
| marekd | joesavak: that's great, I will be online :-) | 13:24 |
| joesavak | sweet! | 13:24 |
| marekd | joesavak: i did see yesterday's convo. | 13:24 |
| joesavak | Yeah, sorry about the bad formatting. | 13:24 |
| marekd | joesavak: no worries, I just scrolled up my IRC client :-) | 13:24 |
| joesavak | It didn't resolve much but after speaking to Jorge, we think we know where the concern is | 13:24 |
| marekd | joesavak: cool. | 13:26 |
| *** jcromer has joined #openstack-keystone | 13:26 | |
| *** nkinder has joined #openstack-keystone | 13:30 | |
| openstackgerrit | ayoung proposed a change to openstack/keystone: Default to PKIZ tokens https://review.openstack.org/98897 | 13:30 |
| openstackgerrit | ayoung proposed a change to openstack/keystone: pkiz String conversion https://review.openstack.org/100545 | 13:30 |
| ayoung | joesavak, marekd please include me in these discussions. It will save you much grief in the long term | 13:31 |
| ayoung | I've kindof been working through the issues on Federation since I started on this project, and I think there are aspects you have not considered | 13:31 |
| marekd | ayoung: sure | 13:31 |
| joesavak | ayoung - sweet! All convo, including next meetings is being captured in the review. Anyone and everyone welcome. | 13:32 |
| marekd | joesavak: ++ | 13:32 |
| ayoung | joesavak, I've been reading through it. | 13:33 |
| ayoung | joesavak, #openstack-meeting? | 13:33 |
| joesavak | #openstack-keystone | 13:33 |
| joesavak | right here. ;) | 13:33 |
| marekd | #openstack-federation :D | 13:34 |
| joesavak | y'all want to do that? may make sense to not create much noise in here | 13:34 |
| marekd | joesavak: i was kidding, but have no issue with a different channel. | 13:34 |
| ayoung | No, keep it here | 13:34 |
| ayoung | Federation is core to Keystone | 13:35 |
| joesavak | cool. Here it is. | 13:35 |
| ayoung | morganfainberg, when you wake up...I split out your change for the str conversion in the PKIZ token provider to its own patch. | 13:37 |
| ayoung | jamielennox, if you are still awake: https://review.openstack.org/#/c/100545/1 is pretty trivial in scope | 13:40 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/99076 | 13:52 |
| *** nikunj2512 has joined #openstack-keystone | 13:55 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/96265 | 13:56 |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: multi-backend support for identity https://review.openstack.org/74214 | 13:58 |
| *** dims has joined #openstack-keystone | 13:58 | |
| *** hrybacki has joined #openstack-keystone | 13:59 | |
| *** dims has quit IRC | 13:59 | |
| *** ajayaa has quit IRC | 13:59 | |
| *** stevemar has joined #openstack-keystone | 14:02 | |
| *** dims has joined #openstack-keystone | 14:07 | |
| *** tomoiaga has quit IRC | 14:09 | |
| openstackgerrit | A change was merged to openstack/keystone-specs: Remove template from juno approved specs https://review.openstack.org/100310 | 14:09 |
| openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Convert auth_token to use session https://review.openstack.org/74908 | 14:11 |
| *** juanmo1 has joined #openstack-keystone | 14:13 | |
| *** juanmo has quit IRC | 14:15 | |
| *** erecio has quit IRC | 14:15 | |
| *** Gippa has left #openstack-keystone | 14:15 | |
| hrybacki | ayoung: just to clarify, you want me to rebase my commit with https://review.openstack.org/#/c/74908/ yes? | 14:15 |
| ayoung | hrybacki, yeah. here's the deal | 14:16 |
| *** erecio has joined #openstack-keystone | 14:16 | |
| ayoung | the auth_token code is doing too much | 14:16 |
| ayoung | the "Session" that jamie wrote handles much of the common logic for anything tlaking to keystone | 14:16 |
| *** zhiyan_ is now known as zhiyan | 14:16 | |
| ayoung | in this case, you need it to provide some access to the 'client' | 14:16 |
| ayoung | once you have the client object, you can call on the API | 14:17 |
| ayoung | hrybacki, I rebased his changes, and will beat the other devs up about getting it merged | 14:17 |
| hrybacki | okay | 14:17 |
| ayoung | as you can see, there is a lot in motion here, so it is a tough to stay on top of what goes where | 14:18 |
| hrybacki | makes sense, auth_token was kind of a gorilla | 14:18 |
| hrybacki | indeed | 14:18 |
| baffle | How 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 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: pkiz String conversion https://review.openstack.org/100545 | 14:21 |
| morganfainberg | ayoung, that was a painful debug btw | 14:22 |
| ayoung | morganfainberg, thanks for slogging through it | 14:23 |
| ayoung | morganfainberg, please +1 the patch I submitted in your name | 14:23 |
| henrynash | joesavak: is there a draft spec for k2k federation? | 14:24 |
| *** ericvw has joined #openstack-keystone | 14:24 | |
| *** rwsu has joined #openstack-keystone | 14:24 | |
| hrybacki | ayoung: simplest way to rebase against 74908 simply to git review it, checkout my feature branch and 'git rebase <74908 branch>'? | 14:25 |
| joesavak | yup! https://review.openstack.org/#/c/100023/ | 14:25 |
| joesavak | henrynash ^^ | 14:25 |
| henrynash | joesavak: ta | 14:25 |
| morganfainberg | ayoung, ++ | 14:25 |
| ayoung | henrynash, oh, come on | 14:25 |
| ayoung | https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs,n,z | 14:25 |
| ayoung | should be in your bookmarks by now! | 14:25 |
| * ayoung admits he just added it | 14:25 | |
| * joesavak just added it too | 14:26 | |
| henrynash | ayoung: :-) but I didn’t see Joe’s there.... | 14:26 |
| *** elmiko has left #openstack-keystone | 14:26 | |
| ayoung | ITS THE FIRST ONE! | 14:27 |
| ayoung | henrynash, BTW...do you have a new version of your patch anywhere ready to go> | 14:27 |
| ayoung | the multip backend patch | 14:27 |
| henrynash | ayoung: just posted | 14:27 |
| ayoung | AWESOME! | 14:27 |
| * ayoung needs to cut back on caffeine | 14:27 | |
| henrynash | ayoung: 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 whole | 14:28 |
| ayoung | henrynash, +2223, -1147that is hefty. Whew | 14:28 |
| ayoung | henrynash, looking nowe | 14:28 |
| henrynash | ayoung: yep, that’s all the unit test changes (all mechanical, but lots of them) | 14:29 |
| ayoung | nkinder, BTW ^^ is the single most important patch for us. Please spend some time on it as well. | 14:29 |
| ayoung | henrynash, 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 |
| ayoung | and I think you meant to remove to top line | 14:30 |
| morganfainberg | ayoung, ... | 14:30 |
| ayoung | https://review.openstack.org/#/c/74214/29/keystone/tests/test_auth.py,cm | 14:30 |
| morganfainberg | how.. did you get gerrit wedged up and in a circular dependency? | 14:30 |
| ayoung | ah... | 14:30 |
| ayoung | Did I...hmm, did it not give your change a new changeid | 14:31 |
| henrynash | ayoung: no…it’s ‘caue the manager now generates the ID | 14:31 |
| ayoung | Ic932240fbbe5bd9da6197b37cf86092bde510f40 | 14:31 |
| ayoung | Idf14ab6c6dd3a3cab42c35771416d9096ea4d900 | 14:31 |
| henrynash | ayoung:? | 14:31 |
| ayoung | morganfainberg, what is the circular? | 14:31 |
| ayoung | henrynash, sorry, two convos at once | 14:32 |
| ayoung | henrynash, I see what you are doing, | 14:32 |
| morganfainberg | ayoung, oh nvm | 14:32 |
| henrynash | ayoung: ah… | 14:32 |
| morganfainberg | ayoung, was mis-reading sorry. | 14:32 |
| ayoung | morganfainberg, are you using the new view? It does report it differently | 14:33 |
| ayoung | "Related reviewas" which shows itself | 14:33 |
| morganfainberg | ayoung, yeah it got into the new view somehow. | 14:33 |
| morganfainberg | ayoung, i fixed it by going back to the old veiw (cookie issue or something) | 14:33 |
| morganfainberg | https://review.openstack.org/#/c/98897/ please click rebase | 14:33 |
| ayoung | I kind prefer the new | 14:33 |
| ayoung | morganfainberg, no rebase available | 14:34 |
| *** juanmo1 has quit IRC | 14:34 | |
| morganfainberg | uh. | 14:34 |
| morganfainberg | says it depends on an outdated patchset | 14:34 |
| openstackgerrit | ayoung proposed a change to openstack/keystone: Default to PKIZ tokens https://review.openstack.org/98897 | 14:34 |
| morganfainberg | there we go | 14:34 |
| ayoung | morganfainberg, yeah...again an old-new view thing | 14:34 |
| ayoung | there was no rebase button on the new view. went to the old and saw it | 14:35 |
| morganfainberg | never thought gerrit could have a worse ux than it already had | 14:35 |
| morganfainberg | then i saw the new view | 14:35 |
| morganfainberg | :P | 14:35 |
| *** zhiyan is now known as zhiyan_ | 14:35 | |
| morganfainberg | ayoung, thanks for splitting the str thing out | 14:35 |
| *** zhiyan_ is now known as zhiyan | 14:36 | |
| *** BAKfr has quit IRC | 14:36 | |
| ayoung | henrynash, can you do a quickie code review? https://review.openstack.org/#/c/100545/2 | 14:36 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Default to PKIZ tokens https://review.openstack.org/98897 | 14:36 |
| henrynash | ayoung: yep, looking | 14:36 |
| morganfainberg | ayoung, ^ fixed a couple typos in your commit message | 14:36 |
| morganfainberg | ayoung, (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-keystone | 14:37 | |
| *** zhiyan_ is now known as zhiyan | 14:37 | |
| ayoung | morganfainberg, ++ | 14:38 |
| morganfainberg | ayoung, as soon as your compress token change default lands... | 14:38 |
| morganfainberg | i get to propose making one of the gate jobs use apache!! :) | 14:38 |
| ayoung | morganfainberg, and then the screaming commences | 14:39 |
| *** juanmo has joined #openstack-keystone | 14:39 | |
| *** Benj__ has joined #openstack-keystone | 14:39 | |
| morganfainberg | ayoung, haha, i'm hoping it'll be clean and solid enough to switch the default in devstack by the end of J | 14:39 |
| *** CptE has joined #openstack-keystone | 14:39 | |
| morganfainberg | bobt, 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 |
| ayoung | Benj__, you are a brave brave man | 14:43 |
| ayoung | or owman | 14:43 |
| ayoung | or woman | 14:43 |
| ayoung | don't want to prejudge | 14:43 |
| morganfainberg | Benj__, awesome! welcome on board :) and yes, ask away | 14:44 |
| Benj__ | brave for being here or brave for looking at Keystone CLI? | 14:44 |
| ayoung | Benj__, BTW, hrybacki is pretty much in the same boat | 14:44 |
| ayoung | Benj__, there is no CLI | 14:44 |
| ayoung | the CLI is a figment | 14:44 |
| ayoung | heh | 14:44 |
| morganfainberg | ayoung, shush. :P | 14:44 |
| ayoung | OK, the CLI is going away, and we are trying to get people to focus on the common CLI | 14:44 |
| morganfainberg | Benj__, you'll also want to talk with stevemar and dtroyer_zz for openstack common cli | 14:45 |
| ayoung | the keystoneclient code is going to stay around as a library | 14:45 |
| bknudson | there's also a push to get a common SDK -- openstack-sdk | 14:45 |
| ayoung | Benj__, so... yeah, brave for wading out into a rushing river, but welcome. And please, ask away. | 14:46 |
| bknudson | http://git.openstack.org/cgit/stackforge/python-openstacksdk/ | 14:46 |
| ayoung | bknudson, think that is ever going to happen? | 14:46 |
| morganfainberg | bknudson, 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 are | 14:46 |
| bknudson | ayoung: I doubt it's ever going to happen | 14:46 |
| ayoung | bknudson, that is my take, too | 14:46 |
| bknudson | morganfainberg: their goals seem to change. | 14:46 |
| morganfainberg | ayoung, if it supplants the clients completely, i hope it does | 14:46 |
| morganfainberg | ayoung, but i'm with bknudson, i don't think it's going to in the near term (dunno about any term) | 14:47 |
| ayoung | Benj__, so, what specifically are you looking at? | 14:47 |
| bknudson | I would be fine if it did happen, but it's a big project if they want to really reimplement all the clients | 14:47 |
| Benj__ | so is the python-keystoneclient on GitHub going away? https://github.com/openstack/python-keystoneclient | 14:47 |
| bknudson | and that seems to be all they're doing | 14:47 |
| ayoung | Benj__, no | 14:47 |
| ayoung | Benj__, that is going to stay as the keystone library | 14:47 |
| ayoung | just eh CLI aspect will get rolled into the common CLI | 14:47 |
| ayoung | THe Common SDK is a pipedream | 14:48 |
| ayoung | and that pipe is stuffed with something very potent | 14:48 |
| Benj__ | oh, man... pandora's box or what | 14:48 |
| Benj__ | ! | 14:48 |
| bknudson | maybe with Benj__'s help it'll get done | 14:48 |
| ayoung | Benj__, so...what are you looking at? Just getting involved, or something specific? | 14:48 |
| jcromer | i just had to use the common client to create domain and domain admin user for use with heat | 14:49 |
| ayoung | jcromer, HEat is making CLI calls, or was that for a setup script? | 14:49 |
| *** alligator has joined #openstack-keystone | 14:49 | |
| ayoung | jcromer, I'm a bash guy, but I've started to switch over to using python calls for that kind of stuff | 14:49 |
| Benj__ | please don't hold your breath! Anyway, I'm implementing federated login using an API written by the university here | 14:49 |
| ayoung | https://github.com/admiyo/keystone-examples | 14:50 |
| ayoung | Benj__, AH...Fedration | 14:50 |
| Benj__ | yes... MIGHTY federation | 14:50 |
| ayoung | OK, so there is a lot of sturm-unt-drang about that right now. There is a spec ... | 14:50 |
| ayoung | https://review.openstack.org/#/c/96867/ | 14:51 |
| ayoung | Benj__, 2 things | 14: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 gitHub | 14:51 |
| hrybacki | Benj__: welcome, heh. Hope you bought coffee and headache meds. | 14:51 |
| *** thedodd has joined #openstack-keystone | 14:51 | |
| jcromer | ayoung, in icehouse heat auth model changed and requires keystone domain which i couldn't create with the pythonclient | 14:51 |
| morganfainberg | marekd, glad you're going to be around for the convo. | 14:51 |
| jcromer | ayoung, http://hardysteven.blogspot.com/2014/04/heat-auth-model-updates-part-2-stack.html | 14:52 |
| ayoung | 1. 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 that | 14:52 |
| Benj__ | young yeah, that's SAML. Kent's API uses modules for protocol independence, so a little different. | 14:52 |
| marekd | morganfainberg: sure. | 14:52 |
| Benj__ | http://sec.cs.kent.ac.uk/demos/keystone.html | 14:52 |
| ayoung | Benj__, heh | 14:52 |
| morganfainberg | marekd, 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 |
| nikunj2512 | How can I use the Keystone V2 api to change the email address for non admin users? | 14:53 |
| ayoung | I 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-concept | 14:53 |
| morganfainberg | nikunj2512, i believe V2 requires an admin to make that change | 14:54 |
| morganfainberg | nikunj2512, so an admin would need to update the user's email. | 14:54 |
| ayoung | Benj__, what protocol do you need? SAML, or openid connect? Something else? | 14:54 |
| nikunj2512 | Ok.. Because I am able to do this using v3 api | 14:54 |
| nikunj2512 | Ok.. | 14:54 |
| morganfainberg | nikunj2512, v2 api is more restrictive, it only has the concept of is_admin and is_not_admin really | 14:55 |
| dstanek | just 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 repo | 14:55 |
| morganfainberg | dstanek, yes it is | 14:55 |
| marekd | morganfainberg: the time chosen is not that bad :P | 14:55 |
| marekd | dstanek: happening in few minutes. | 14:55 |
| marekd | dstanek: but it's the joesavak who chairs here. | 14:55 |
| nikunj2512 | Ok.. The k | 14:55 |
| nikunj2512 | Ok.. Thank You morganfainberg | 14:56 |
| morganfainberg | nikunj2512, happy to help | 14:56 |
| morganfainberg | dstanek, marekd, i also asked nkinder to take a look at it when he had some time. | 14:56 |
| marekd | morganfainberg: saw it, it's great! | 14:56 |
| dstanek | pre question then - it mentions that we already have a keystone->service_provider trust relationship. that's just implicit right? | 14:57 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/99076 | 14:57 |
| *** dims_ has joined #openstack-keystone | 14:57 | |
| morganfainberg | dstanek, that is explicitly setup | 14:57 |
| morganfainberg | dstanek, it isn't clear in the current spec. | 14:58 |
| dstanek | morganfainberg: the spec says we already have that | 14:58 |
| morganfainberg | dstanek, it's part of why we're having a deeper conversation so the spec can be made more clear | 14:58 |
| ayoung | Benj__, there is also https://review.openstack.org/#/c/92166/ for the ECP extension, which I think is essential to the non-GUI use cases | 14:58 |
| morganfainberg | dstanek, yeah it's supposed to be afaict (from the convo yesterday) explicitly configured as part of the setup with this spec | 14:59 |
| morganfainberg | line 164 - "resister the SP" | 14:59 |
| joesavak | howdy howdy - | 14:59 |
| *** jorgew has joined #openstack-keystone | 14:59 | |
| marekd | joesavak: hi! | 14:59 |
| morganfainberg | joesavak, allo there | 14:59 |
| *** htruta has quit IRC | 14:59 | |
| ayoung | Benj__, 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 things | 14:59 |
| morganfainberg | jorgew, welcome welcome | 14:59 |
| jorgew | Hey guys! | 15:00 |
| ayoung | so, if you want to work with SAML, or OpenID connect, there are other people looking at that now that you can work with | 15:00 |
| Benj__ | ayoung, thanks I'll take a look | 15:00 |
| joesavak | alrighty - so continuing from yesterday - same kind of concerns | 15:00 |
| morganfainberg | ayoung, about to talk about that spec. fyi | 15:00 |
| ayoung | Benj__, there is also some discussion of Keystone to Keystone | 15:00 |
| morganfainberg | Benj__, ayoung, actually... going to start that now ;) | 15:00 |
| marekd | morganfainberg: ++ | 15:00 |
| ayoung | and that is a whole new canball of wax-worms | 15:00 |
| joesavak | #link: http://paste.openstack.org/show/84236/ | 15:00 |
| joesavak | #link: https://review.openstack.org/#/c/100023/3 | 15:01 |
| dstanek | joesavak: 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 IRC | 15:01 | |
| joesavak | gotcha. So let's discuss that first | 15:01 |
| ayoung | joesavak, just to be clear, are we focusing on Keystone to Keystone? | 15:01 |
| joesavak | ayoung - yes | 15:01 |
| morganfainberg | joesavak, dstanek's point is my big concern. | 15:01 |
| ayoung | joesavak, OK, I move we abbreviate that to K2K | 15:01 |
| rodrigods | joesavak, 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 |
| rodrigods | ayoung, ++ | 15:01 |
| marekd | rodrigods: ++ | 15:02 |
| jorgew | joesavak, Do you mind if I talk about the token flow? | 15:02 |
| joesavak | jorgew - go for it. | 15:02 |
| ayoung | jorgew, first, we need a use case. | 15:02 |
| joesavak | Let's focus on use case 1 first | 15:02 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/96265 | 15:02 |
| morganfainberg | stevemar, ping ^^ | 15:02 |
| joesavak | line 45 of the spec | 15:02 |
| joesavak | https://review.openstack.org/#/c/100023/3/specs/juno/keystone-to-keystone-federation.rst | 15:02 |
| stevemar | morganfainberg, thanks for the heads up | 15:02 |
| joesavak | ayoung ++ for k2k | 15:03 |
| morganfainberg | stevemar, yeah didn't want ya to miss out on the convo | 15:03 |
| joesavak | rodrigods, yes - meetings and commenting on the spec/reviews would be good too! | 15:03 |
| ayoung | joesavak, OK, so The goal of this usecase is to enable one organization to have a common set of authorization decisions across multiple clouds | 15:03 |
| joesavak | ayoung, yes | 15:04 |
| jorgew | joesavak, 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 |
| rodrigods | joesavak, great | 15:04 |
| ayoung | joesavak, OK, a couple things to keep in mind | 15:04 |
| *** chandan_kumar has joined #openstack-keystone | 15:04 | |
| ayoung | policy is going to vary from cloud to cloud. Not today, but eventually | 15:04 |
| ayoung | which means that roles will have to be remapped | 15:04 |
| marekd | ayoung: ++ | 15:04 |
| joesavak | jorgew - good point. I'll add it in there. It's implied but not explicit | 15:04 |
| ayoung | so what is "_member_" in cloud 1 might be "user" in cloud 2 | 15:04 |
| ayoung | joesavak, but... | 15:04 |
| ayoung | you don't want to have to redefine that mapping for each project | 15:05 |
| jorgew | ayoung, correct role mapping should occur. | 15:05 |
| ayoung | and that means we need to extend the mapping mechanism to "split and join" | 15:05 |
| marekd | please, let jorgew talk about the workflow. | 15:05 |
| ayoung | My shorthand is | 15:05 |
| ayoung | R1P1 means Role 1 on Project 1 | 15:05 |
| rodrigods | ayoung, jorgew who would define this mapping? what if cloud 2 changes from 'user' to 'dev', would be something manual? | 15:05 |
| *** CptE has quit IRC | 15:05 | |
| ayoung | so R1P1 in cloud 1 needs to be mapped to R2P2 in cloud 2 | 15:05 |
| joesavak | #topic: overall flow | 15:06 |
| ayoung | rodrigods, yes, manual, but should be small impact | 15:06 |
| joesavak | I'd like to table mapping right now | 15:06 |
| joesavak | just to set a baseline of the flow | 15:06 |
| morganfainberg | ayoung, yep, lets circle up on that once we have the basic workflow discussed | 15:06 |
| ayoung | joesavak, fair enough | 15:06 |
| joesavak | go for it jorgew. : ) | 15:06 |
| jorgew | Okay, there are two keystone one provides the identity (IDP keystone) one provides services (SP keystone) | 15:07 |
| ayoung | services meaning tokens? | 15:07 |
| jorgew | Out of band there is a relationship established between both keystone…keys are exchange…roles (and possibly tenants, and domains) are mapped. | 15:07 |
| ayoung | IE: assigned users to roles? | 15:07 |
| ayoung | jorgew, BTW, are you assuming that we've split Keystone into these two pieces, as we discussed at the summit? | 15:08 |
| jorgew | ayong, well let me reword. One cloud provides identity…the other cloud provides services like compute or object store. | 15:08 |
| jorgew | The keystone that belongs to that cloud is the SP keystone | 15:09 |
| jorgew | ayoung, Not assuming that now | 15:09 |
| ayoung | jorgew, just to be clear, you are still planning on using tokens for identity. I think that might be a fatal flaw | 15:09 |
| ayoung | jorgew, I would prefer to say that tokens are authorization data only | 15:09 |
| ayoung | and identity is carried on some cryptographically secure mechanism | 15:09 |
| dstanek | jorgew: when you say provides services you mean does authz for the services in that cloud right? | 15:09 |
| jorgew | ayound, okay tokens == authorization data. | 15:10 |
| morganfainberg | jorgew, ayoung, ++ tokens being authz data only is how i always viewed it | 15:10 |
| jorgew | dstanek, when I say a cloud provides services to another cloud I mean services like compute or object store. | 15:10 |
| ayoung | jorgew, so if Keystone tokens are authorization data, then Fedration is built on coupling SAML or X509 with A Keystone token | 15:11 |
| ayoung | I don't know if Kerberos is a viable solution there or not, but I'd like it to be | 15:11 |
| jorgew | morganfainberg, 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 |
| dstanek | jorgew: so a client would talk to the keystone directly for compute instead of going to that cloud's nova? | 15:12 |
| ayoung | So, 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 K2 | 15:12 |
| jorgew | Okay hold on guys…let me describe the flow and then you can throw rocks at it :-) | 15:12 |
| stevemar | ++ | 15:12 |
| rodrigods | ++ | 15:12 |
| marekd | +100 | 15:12 |
| henrynash | order, order... | 15:12 |
| morganfainberg | jorgew, please continue | 15:12 |
| stevemar | save questions for 5 minutes from now | 15:13 |
| ayoung | jorgew, 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 do | 15:13 |
| morganfainberg | ayoung, hold up. | 15:13 |
| jorgew | …So anyway, through some magic a relationship is established between IDP keystone and SP keystone. | 15:13 |
| morganfainberg | ayoung, let jorgew continue with the current proposal | 15:13 |
| jorgew | …and mapping occurs. | 15:13 |
| jorgew | User logs in to IDP keystone. | 15:14 |
| jorgew | Bear with me here: the user gets a token (which may be PKI or not) and gets a service catalog | 15:14 |
| jorgew | That catalog will contain endpoints in IDP cloud…but can also contain endpoints in SP cloud | 15:14 |
| jorgew | The user can send a request to SP cloud endpoint | 15:15 |
| jorgew | Through some yet to be defined magic, SP middleware can detect that token is not local | 15:15 |
| jorgew | sends validate token request to SP keystone | 15:15 |
| ayoung | jorgew, to be clear, the must go to SP keystone to get a token? | 15:16 |
| jorgew | SP keystone is aware of mappings nessesary so sends response to middle ware with appropriate roles, tenant, domain etc | 15:16 |
| ayoung | or direct to nova? | 15:16 |
| jorgew | ayoung, no token comes from IDP keystone…is validated by SP keystone based on mapping | 15:16 |
| jorgew | ayong, so the same token is used. | 15:16 |
| joesavak | continue to gather rocks for a bit. : ) | 15:17 |
| jorgew | ayoung, but the response to validate token may vary form one cloud to another. | 15:17 |
| jorgew | The idea is that the bursting is transparent to the client..she just sees another endpoint | 15:17 |
| jorgew | The 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 |
| jorgew | We can cache tokens to avoid going back to IDP keystone for every request. | 15:18 |
| jorgew | okay…that's it.. | 15:18 |
| marekd | jorgew: 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 scaling | 15:19 |
| marekd | joesavak: thank you | 15:19 |
| ayoung | jorgew, hold on | 15:19 |
| ayoung | scaling can wait | 15:19 |
| ayoung | lets talk correctness first | 15:19 |
| jorgew | ayong, okay shoot. | 15:19 |
| joesavak | #topic correctness(sp)? | 15:19 |
| ayoung | there are a couple ways we could make this happebn | 15:20 |
| ayoung | the first question is "can Nova trust multiple keystones" | 15:20 |
| ayoung | if the answer is yes, then the question is "how do we divvy up responsibility" | 15:20 |
| marekd | ayoung: i think it shouldn't. | 15:20 |
| marekd | in that case. | 15:20 |
| ayoung | marekd, hold on | 15:20 |
| ayoung | Lets say that Keystone Service is the arbiter | 15:20 |
| jorgew | ayoung, I see it slightly differently. Nova trusts it's local keystone and the question is can that keystone trust other keystones. | 15:20 |
| morganfainberg | marekd, i am in the same boat, but waiting for the whole set of questions | 15:20 |
| ayoung | and it can make a decision that KIdP is allowed to sign for tokens from domain X | 15:21 |
| ayoung | and only domain X | 15:21 |
| ayoung | now, when a token comes in for something for domain X, look at who signed it | 15:21 |
| ayoung | if it was KIdP, then it is OK | 15:21 |
| ayoung | no need to go back to Keystone for each validation | 15:21 |
| ayoung | only the first time a decision about a foreign token is made | 15:22 |
| ayoung | so, the question is, what Keystone can sign for what data | 15:22 |
| ayoung | we can inspect the token and pull out the signing data | 15:22 |
| marekd | ayoung: 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 |
| ayoung | and based on that, deduce which keystone signed it | 15:23 |
| ayoung | marekd, there is no Foreverm, there is only "cache window" | 15:23 |
| ayoung | forever | 15:23 |
| ayoung | marekd, The local Keystone is still the arbiter | 15:23 |
| marekd | ayoung: OK! | 15:23 |
| ayoung | it says which beds are available | 15:24 |
| morganfainberg | marekd, this is more of a "you can sleep on my guest bed, but not mine" if i read it correctly | 15:24 |
| dstanek | hmmm...i need to draw this out | 15:24 |
| ayoung | marekd, there are other issues: what if the token talks a bout a project that does not exist | 15: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 |
| ayoung | jorgew, right. | 15:24 |
| marekd | ayoung: 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 |
| ayoung | jorgew, so the question there is where should the mapping happen | 15:25 |
| jorgew | ayoung, projects need to be mapped…possibly prefixed by service provider id to avoid clashes. | 15:25 |
| ayoung | jorgew, so I kindof think that the user needs to go to keystone, get a token, hand that to another keystone, and get an appropriate token | 15:25 |
| jorgew | ayoung, my thought on mapping is that it happens when the relationship is first built…and it occurs at the SP keystone. | 15:26 |
| marekd | ayoung: that's how i see it! | 15:26 |
| ayoung | instead of handing off tokens to nova and making keystone | 15:26 |
| ayoung | making nova contact keystone each time | 15:26 |
| marekd | ayoung: i think all the burden of trusts, relationships, mapping(!) should be on the Keystone. | 15:26 |
| morganfainberg | marekd, 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 |
| ayoung | Nova should not be requesting tokens on behalf of a foreign user | 15:26 |
| ayoung | jorgew, so, some other things we need to keep in mind | 15:27 |
| ayoung | currently, any token can be handed in for any other token for the same user | 15:27 |
| jorgew | ayoung, 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 |
| ayoung | thuis means the the trust would implicity be two directional, and this is a security nightmare | 15:27 |
| ayoung | we need to lock down the "direction" of token2token exchanges | 15:27 |
| ayoung | jorgew, who is making the bursting decision? | 15:28 |
| jorgew | ayoung, 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 |
| ayoung | I would think nova | 15:28 |
| dstanek | jorgew: here's the way i heard you: https://www.dropbox.com/s/lya8koxc6puc4ui/IMG_20140617_112436.jpg | 15:28 |
| dstanek | blarg...sideways | 15:28 |
| jorgew | ayoung, The service provider decides that the bursting can occur. The user bursts by simply making a call to the endpoint. | 15:28 |
| henrynash | jorgew: 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 |
| ayoung | jorgew, yes. Just be aware that "locking it down" involves changeing some pretty serious asumptions on the part of Horizon | 15:28 |
| morganfainberg | henrynash, ++ | 15:29 |
| morganfainberg | henrynash, that is a very good question. | 15:29 |
| joesavak | dstanek - that's right on | 15:29 |
| ayoung | hence: https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens | 15:29 |
| morganfainberg | dstanek, i think my neck dislikes your diagram >.> :P | 15:30 |
| dstanek | joesavak: my diagram is a bit off and messy, but that clears up many of my questions | 15:30 |
| dstanek | morganfainberg: serry :-( | 15:30 |
| morganfainberg | dstanek, thanks for posting it :) | 15:30 |
| dstanek | so are you envisioning the remote keystone will not issue it's own token for the client? | 15:30 |
| jorgew | henrynash, 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 IRC | 15:31 | |
| *** amerine has joined #openstack-keystone | 15:31 | |
| morganfainberg | jorgew, i see one small problem, there are sometimes local resources (trove?) that may not be available and you'd need to know that | 15:31 |
| morganfainberg | jorgew, 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-keystone | 15:32 | |
| joesavak | morgan - you touch on another step there. Let's talk about that. How to get a single service catalog | 15:32 |
| ayoung | jorgew, I would do bursting as a service in front of Nova. THe burst decision is going to require a lot of orchestration | 15:32 |
| *** zhiyan is now known as zhiyan_ | 15:32 | |
| ayoung | in that case, the orchestrator (nova or Heat or whatever) can do the token2token request as part of the burst operation | 15:33 |
| rodrigods | dstanek, morganfainberg neck safe version https://www.dropbox.com/s/tkhu4vbg6z099a0/IMG_20140617_112436.jpg | 15:33 |
| *** erecio has quit IRC | 15:33 | |
| jorgew | ayoung, that can work as long as the process is hidden from the user. You'd still want a single catalog etc. | 15:33 |
| ayoung | jorgew, the endpoints would all have to be "burst proxy" | 15:34 |
| *** erecio has joined #openstack-keystone | 15:34 | |
| ayoung | jorgew, you could make it a little more explict by doing this: | 15:34 |
| ayoung | create a "burst" proejct | 15:34 |
| jorgew | morganfainberg, wouldn't that still be an issue if you are dealing with multiple regions in the service catalog, how is that different? | 15:34 |
| dstanek | rodrigods: thx! | 15:34 |
| *** juanmo has quit IRC | 15:34 | |
| joesavak | dstanek - see see line 103: https://review.openstack.org/#/c/100023/3/specs/juno/keystone-to-keystone-federation.rst regarding service broadcasting of remote clouds | 15:34 |
| ayoung | and everything in that project is a remote endpoint | 15:34 |
| ayoung | so if the local context is "full" use the "burst" context | 15:34 |
| *** topol has quit IRC | 15:34 | |
| ayoung | http://younglogic.com/images/k2k_fed_flow.jpg for people that don't want to strain their necks | 15:35 |
| jorgew | ayoung, does that mean that all remote users use the same project? | 15:35 |
| ayoung | jorgew, no way | 15:35 |
| jorgew | okay whew… | 15:36 |
| jorgew | Then, I'm not sure I follow. | 15:36 |
| ayoung | jorgew, I'm just thinking outloud quietly here, but I would think the service catalog would be in some...swappable template thingy | 15:36 |
| ayoung | make it a property of the project: | 15:36 |
| ayoung | and this is horrible, just brainstorming | 15:36 |
| ayoung | say the region is different | 15:37 |
| jorgew | okay got it. Correct, users will see these endpoints as a different region. | 15:37 |
| ayoung | and so a given project is associated with R1. R2 is the burst region in a remote cloud | 15:37 |
| jorgew | exactly! | 15:37 |
| joesavak | Ok - gut check - everyone "get" the flow? | 15:37 |
| ayoung | then the question is how do you generate a Burst Project for every project that needs it...and I say you don't | 15:38 |
| jorgew | I like the name..maybe that's what we should call the proposal "Burst Regions" | 15:38 |
| ayoung | you do it as a query parameter on the service catalog | 15:38 |
| ayoung | ....hmmmm | 15:38 |
| ayoung | jorgew, what if | 15:38 |
| marekd | joesavak: we rely on the classic regions ? | 15:38 |
| ayoung | for a give project, we give it an ordered list of regions | 15:38 |
| ayoung | the first is the default, and then each is used as a burst region in turn | 15:38 |
| dstanek | joesavak: the only thing i'm wondering now regarding flow is morganfainberg's comments about who issues the token | 15:39 |
| ayoung | so when you get a token for P1, you get the service catalog for R1 | 15:39 |
| ayoung | dstanek, whomever makes the burst decision | 15:39 |
| ayoung | dstanek, if it is Nova1, then it does the token2token request | 15:39 |
| joesavak | typically a client in the "local cloud" realm who's identity is accessible by k1 in the flow pic | 15:40 |
| ayoung | if it is heat, | 15:40 |
| jorgew | ayoung, like it, but keep in mind that the local cloud may have several local (non-burst) regions. | 15:40 |
| ayoung | joesavak, and we can build that logic into the keystone client, but it really only makes sense in the "unified CLI" approach to work across clouds | 15:40 |
| ayoung | jorgew, yep...and that is why I am not going to implement it until we run it past jaypipes | 15:41 |
| ayoung | :) | 15:41 |
| jorgew | ayoung, I like the idea of using a query parameter to narrow what regions you get back in general (burst or local) | 15:41 |
| ayoung | actually, I am not going to implement it anyway...just provide guidance | 15:41 |
| *** amerine has quit IRC | 15:41 | |
| joesavak | marekd - i don't get your question re: classic regions - | 15:42 |
| ayoung | jorgew, OK, I don't think you would want the whole service catalog in there, just the burst Keystone | 15:42 |
| marekd | joesavak: regions we now have in openstack. | 15:42 |
| ayoung | then, 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 catalog | 15:43 |
| joesavak | marekd - those will still work - what i believe ayoung and jorew are talking about is limiting service catalog response to local or bursted regions | 15:43 |
| ayoung | jorgew, and then you just get a ranked list of Keystone endpoints instead of the whole burst catalog | 15:43 |
| marekd | ayoung: and the burst keystone can properly scope it to an existsing project/domain | 15:43 |
| ayoung | marekd, yeah | 15:43 |
| dstanek | marekd: 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 |
| morganfainberg | so... we need to keep the bursting region's service catalog in sync with the idp's region? | 15:43 |
| joesavak | dstanek - right, other regions and other endpoints/services | 15:44 |
| ayoung | morganfainberg, that is why we just keep the keystone endpoint, not the whole burst catalog | 15:44 |
| ayoung | as I said, I was brainstorming | 15:44 |
| morganfainberg | if that is the case... i still think the right answer is go get a token from the burst region's keystone | 15:44 |
| jorgew | ayoung, no…wait. The burst region should look like any other region. User should not nessesary know the difference. | 15:44 |
| morganfainberg | ayoung, ++ yes, if it's just the endpoint, | 15:44 |
| marekd | ayoung: and this is configured as per 'federation', so registered SPs | 15:44 |
| ayoung | jorgew, the end use does not | 15:44 |
| ayoung | jorgew, only the "burst decider" does | 15:45 |
| jorgew | ayoung, oh I get it. | 15:45 |
| jorgew | ayoung, …and we decided the "burst decider" was ___?? | 15:45 |
| morganfainberg | ayoung, 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 |
| ayoung | jorgew, 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...etc | 15:45 |
| rodrigods | morganfainberg, ++ | 15:45 |
| ayoung | morganfainberg, you too slow | 15:45 |
| ayoung | I rejected that idea already | 15:46 |
| morganfainberg | ayoung, thanks sorry carrying on 2 convos :P | 15:46 |
| ayoung | it was just an idea to generate another idea | 15:46 |
| marekd | morganfainberg: you already have enough problems with token size, right? :P | 15:46 |
| morganfainberg | marekd, yep | 15:46 |
| ayoung | morganfainberg, the real question is "who makes the bursting decision" | 15:46 |
| jorgew | ayoung, don't think it should be the client. | 15:46 |
| dstanek | i was seeing a catalog with r1, r2 and br1 - r1 and r2 are exactly as the are today - br1 get bolted on | 15:46 |
| ayoung | jorgew, I think we can punt on where it happens. It is going to be a multi-approach thing. We just need to specify the mechanism | 15:47 |
| morganfainberg | this sounds like we're somehow mixing heat logic and keystone logic into keystone. | 15:47 |
| ayoung | morganfainberg, nah | 15:47 |
| jorgew | ayoung, 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 |
| ayoung | morganfainberg, let me try to diagram it out... | 15:47 |
| * ayoung goes to white board...carry on | 15:47 | |
| morganfainberg | ayoung, depends on how bursting logic is done | 15:47 |
| dstanek | jorgew: if now the client then who will use the bursting endpoint? | 15:48 |
| jorgew | dstanek, to the client the bursting endpoint just looks like a regular endpoint, the bursting happens under the hood. | 15:48 |
| dstanek | today we can have r1 and r2 all locally - if r1 is full the client needs to go to r2 right? | 15:48 |
| rodrigods | dstanek, good question =) | 15:49 |
| dstanek | jorgew: but there is no magic right? the client actually creates a VM on the bursted region | 15:49 |
| dstanek | to me the "under the hood" is getting the "burst regions" setup | 15:49 |
| rodrigods | i don't get the steps between the burst decision and the k2 token request | 15:50 |
| jorgew | dstanek, yea no magic. Right under the hood means whatever it takes to setup the burst regions etc. | 15:50 |
| marekd | jorgew: burst regions are handled by a remote cloud, with k2 sitting there, right? | 15:51 |
| marekd | whereas k1 is my 'local' keystone. | 15:52 |
| dstanek | morganfainberg: 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 cloud | 15:52 |
| ayoung | OK...I have puictures..let me post | 15:52 |
| jorgew | marekd, yup | 15:52 |
| joesavak | burst regions in a remote cloud are local regions for that remote cloud. What makes them burst regions is another cloud accessing them? | 15:52 |
| marekd | dstanek: i think so. still better than all the remote services. | 15:53 |
| dstanek | joesavak: i think so; it's really burst though it's just a fake local region that point to a remote cloud's local region | 15:53 |
| joesavak | +1 | 15:53 |
| marekd | does anybody have a good resource regarding regions? me must educate :( | 15:55 |
| *** jsavak has joined #openstack-keystone | 15:55 | |
| rodrigods | marekd, me too | 15:55 |
| dstanek | that should have read "it's not really burst" | 15:55 |
| jsavak | it enables burst - by allowing visibility to burst regions and services | 15:55 |
| jorgew | dstenk, it's burst, you're going to a different cloud :-) | 15:55 |
| jorgew | dstenk, though the user preceives it as simply bursting to another region. | 15:56 |
| marekd | logically he is within one cloud, physically somewhere else. | 15:56 |
| morganfainberg | jorgew, hm. ok i see this as not k2k federation. | 15:56 |
| morganfainberg | jorgew, it really isn't "federation" - it's using some federation technology to do bursting. | 15:57 |
| rodrigods | ++ to "Burst regions" title =) | 15:57 |
| dstanek | jorgew: ok, i can buy that. i think of bursting an a sort of automatic event based on load or some other factor | 15:57 |
| jorgew | morganfainberg, that's fine. I like "burst region" title" | 15:57 |
| marekd | ++ | 15:58 |
| ayoung | the k2k part is where the "burting" requires a new token | 15:58 |
| hrybacki | ayoung: 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 |
| ayoung | bursting | 15:58 |
| morganfainberg | ayoung, yes. | 15:58 |
| ayoung | OK...had to resort to twitter to post images | 15:58 |
| morganfainberg | ayoung, which also implies you could do the k2k part without "bursting" | 15:58 |
| *** joesavak has quit IRC | 15:58 | |
| morganfainberg | strict identity providing | 15:58 |
| ayoung | https://twitter.com/admiyoung/status/478929419889676288/photo/1 is the proxy driven, hidden from the user | 15:59 |
| dstanek | morganfainberg: the bursting is just one of the use cases | 15:59 |
| morganfainberg | dstanek, ++ yes | 15:59 |
| jorgew | ayoung, studying your picture | 16:00 |
| ayoung | I can't get the client one to post | 16:00 |
| dstanek | ayoung: so you would rather increase the surface area my making all services understand federation? | 16:00 |
| morganfainberg | ayoung, imgur? | 16:00 |
| ayoung | morganfainberg, don't have it set up yet... | 16:00 |
| morganfainberg | ayoung, can do anonymous upload | 16:00 |
| morganfainberg | ayoung, no account needed. | 16:01 |
| stevemar | ++ anonymous | 16:01 |
| jorgew | ayoung, so nova API is a proxy? | 16:01 |
| jorgew | …to nava burst? | 16:01 |
| ayoung | morganfainberg, its the "get it off the phone" stage that is messing me up | 16:01 |
| morganfainberg | ayoung, oh. | 16:01 |
| * ayoung without a usb cable right now | 16:01 | |
| dstanek | jorgew, ayoung: i think this is actually more what i envision when someone says burst | 16:01 |
| morganfainberg | ayoung, yeah thats painful. email it to yourself! | 16:01 |
| *** amerine has joined #openstack-keystone | 16:02 | |
| ayoung | morganfainberg, I did...and am waiting for delivery | 16:02 |
| ayoung | I need a better setup...but anyway, the colient one is similiar | 16:02 |
| morganfainberg | ayoung, ++ | 16:02 |
| dstanek | jorgew, ayoung: but i don't see how that can work. an app's architect will need to know where the nodes are provisioned | 16:02 |
| morganfainberg | ayoung, install dropbox on the phone? *shrug* dunno. | 16:03 |
| jorgew | dstanek, can you ellaborate? | 16:04 |
| *** sbfox has joined #openstack-keystone | 16:04 | |
| dstanek | jorgew: the diagram looks to me like nova will decide that it need more capacity and use someone's cloud the automatically fulfill the request | 16:06 |
| dstanek | if that is the case something will have to happen for the app running in the remote cloud to talk to local datastores | 16:06 |
| jorgew | dstanek, I think you are thinking auto-scale…not bursting | 16:06 |
| ayoung | dstanek, that is one use case | 16:06 |
| rodrigods | dstanek, the provisioning phase is before the first call to local nova, isn't? | 16:06 |
| ayoung | I have another ...if I can figure out the technolog | 16:07 |
| *** htruta has joined #openstack-keystone | 16:07 | |
| dstanek | jorgew: to me that is what ayoung's diagram implies | 16:07 |
| rodrigods | i decide that i need more nodes, i ask my nova service, if 'no room' i seamless get a node from a burst cloud | 16:07 |
| dstanek | nova API talks directly to nova (burst) | 16:07 |
| jorgew | dstanek, yea, I see what you mean. | 16:07 |
| dstanek | rodrigods: i don't think that can work | 16:08 |
| dstanek | as 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 work | 16:08 |
| rodrigods | dstanek, i think i missed the point, then... | 16:08 |
| *** amerine_ has joined #openstack-keystone | 16:08 | |
| jorgew | ayoung, the idea is that user sees as just another region. No need for nova api to be involved. | 16:08 |
| dstanek | from a openstack perspective this would work because i have a new instance, but from an end user perspective it's broken | 16:09 |
| ayoung | jorgew, hold on | 16:09 |
| rodrigods | so the burst region would always be available? | 16:09 |
| ayoung | jorgew, thing is, you need to make the token translation explicit, so it can't just be another region | 16:10 |
| ayoung | instead, something has to decide "time to burst" | 16:10 |
| marekd | ayoung: how do you 'switch between regions' today? | 16:10 |
| dstanek | ayoung: i think that has to be the client and not the SP | 16:10 |
| marekd | dstanek: ++ | 16:10 |
| morganfainberg | marekd, i'd ask jaypipes - but i think it's application specific | 16:11 |
| ayoung | dstanek, it has to be whomever makes the decision | 16:11 |
| morganfainberg | marekd, e.g. the consumer of the cloud chooses | 16:11 |
| *** amerine_ has quit IRC | 16:11 | |
| jorgew | ayoung, hmm..so by token translation you mean token exchange? | 16:11 |
| marekd | morganfainberg: beause i think this 'burst decision' should be done exactly like the dstanek says - by the client. | 16:11 |
| *** jaosorior has quit IRC | 16:12 | |
| *** amerine has quit IRC | 16:12 | |
| dstanek | i think that bursting anyware is client, but i don't think they need to know where the regions is physically | 16:12 |
| morganfainberg | marekd, ++ | 16:12 |
| *** marcoemorais has joined #openstack-keystone | 16:12 | |
| *** amerine has joined #openstack-keystone | 16:12 | |
| rodrigods | so, in ayoung diagram, the client would be responsible for steps 6 and 7, right? | 16:12 |
| marekd | morganfainberg: 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 |
| morganfainberg | dstanek, sure. | 16:12 |
| jorgew | marked, you switch to a different region by simply calling another endpoint. | 16:13 |
| morganfainberg | marekd, except the region should likely always be visible. | 16:13 |
| marekd | morganfainberg: what do you mean? | 16:13 |
| morganfainberg | not just conditionally | 16:13 |
| marekd | morganfainberg: why? | 16:13 |
| morganfainberg | marekd, if you can use that region, you can use it | 16:13 |
| morganfainberg | marekd, how do you "know" resources are low | 16:13 |
| rodrigods | morganfainberg, but i can always use the burst cloud, even with space at my local region | 16:13 |
| morganfainberg | we don't have centralized quota | 16:13 |
| morganfainberg | rodrigods, ++ thats what i'm saying. | 16:14 |
| *** gokrokve has joined #openstack-keystone | 16:14 | |
| morganfainberg | rodrigods, even if you're not low on space in the Local region, you could always use the burst region. | 16:14 |
| morganfainberg | rodrigods, the burst region doesn't "magically" appear | 16:14 |
| dstanek | morganfainberg: it's no different that rackspace saying ORD is filling up and they setup ORD_alt a few blocks away | 16:14 |
| marekd | morganfainberg: that's the matter of monitoring my resources? Anyway, this bp doesn't try to answer this question. | 16:14 |
| dstanek | ORD_alt would eventually just pop up | 16:14 |
| *** jsavak has quit IRC | 16:14 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: multi-backend support for identity https://review.openstack.org/74214 | 16:14 |
| marekd | morganfainberg: I'd start 'a user want to have easily more resources, he wants to a new region appear suddently' | 16:15 |
| rodrigods | morganfainberg, but how the contract between clouds is done? the user would be paying to someone else, instead to my local service | 16:15 |
| morganfainberg | rodrigods, thats a billing issue, i can't solve that strictly in keystone | 16:15 |
| morganfainberg | rodrigods, that is a "when you negotiate the trust you figure out how billing works" | 16:15 |
| rodrigods | morganfainberg, but you agree that i can lost control of what's being using externally? | 16:16 |
| dstanek | rodrigods: yeah, that's cloud provider to cloud provider (part of the contract they sign) | 16:16 |
| morganfainberg | dstanek, ++ | 16:16 |
| *** marcoemorais1 has joined #openstack-keystone | 16:17 | |
| *** marcoemorais has quit IRC | 16:17 | |
| ayoung | jorgew, how does a user find out that they are running out of resources? | 16:17 |
| rodrigods | ayoung, who is 'user'? | 16:18 |
| jorgew | ayoung, you mean how does a cloud provider know it's having capacity problems? | 16:18 |
| marekd | jorgew: i think so | 16:18 |
| morganfainberg | oooh you know what... i think this becomes a lot more clear now | 16:19 |
| dstanek | well is region1 is filling up and i should start using remote_region1, how do i know? | 16:19 |
| morganfainberg | ayoung, it's not user specific, it is cloud specific | 16:19 |
| morganfainberg | ayoung, if region A is full, you can use region B | 16:19 |
| morganfainberg | region B is not local | 16:19 |
| jorgew | ayoung: That's very cloud specific: here's a hint for us a region may involve multiple DCs, :-) | 16:19 |
| marekd | morganfainberg: yes...... | 16:19 |
| *** afazekas_ has quit IRC | 16:19 | |
| *** richm has quit IRC | 16:20 | |
| morganfainberg | this means quota would need to be managed on both sides. | 16:20 |
| morganfainberg | somehow | 16:20 |
| *** gyee has joined #openstack-keystone | 16:20 | |
| ayoung | morganfainberg, quota is per cloud | 16:20 |
| marekd | morganfainberg: what quota? for who? | 16:20 |
| rodrigods | so the "burst decision" should be pluggable, right? | 16:20 |
| jorgew | I think capacity planning is a whole different issue though. | 16:20 |
| marekd | jorgew: ++ | 16:20 |
| jorgew | Not something we can tackle from keystone. | 16:20 |
| morganfainberg | so. i'm now again confused | 16:20 |
| dstanek | morganfainberg: ? | 16:21 |
| morganfainberg | jorgew, 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 |
| morganfainberg | jorgew, or is this a user has hit their limit in the region and can "burst" to some non-local region? | 16:21 |
| morganfainberg | jorgew, or ... is this something totally different | 16:21 |
| dstanek | morganfainberg: i think it's about the cloud not the user | 16:21 |
| marekd | morganfainberg: 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 you | 16:21 |
| morganfainberg | dstanek, i think so too, but want to be 100% sure | 16:21 |
| jorgew | morganfainberg: 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 close | 16:22 |
| dstanek | a cloud provider extending it's clound my using someone else's | 16:22 |
| jorgew | marked: exactl! | 16:22 |
| morganfainberg | marekd, jorgew, still doesn't answer my question clearly | 16:22 |
| jorgew | The user decides how to use regions. | 16:22 |
| morganfainberg | let me re-ask | 16:23 |
| marekd | morganfainberg: sure. | 16:23 |
| gyee | ayoung, 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.py | 16:23 |
| morganfainberg | is 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 |
| morganfainberg | or | 16:23 |
| *** joesavak has joined #openstack-keystone | 16:23 | |
| gyee | ayoung, that test should stay | 16:24 |
| ayoung | gyee, token_format is set and token.Provider is None | 16:24 |
| ayoung | that does not exist anymore | 16:24 |
| morganfainberg | is the allowance of the "non-local" region cloud a user decides to setup or for a specific subset of users? | 16:24 |
| ayoung | gyee, token.Provider is now defaulted | 16:24 |
| gyee | ayoung, for old config, existing deployment | 16:24 |
| *** raildo has quit IRC | 16:24 | |
| ayoung | gyee, if it iwas None before it will now be PKIZ | 16:24 |
| morganfainberg | gyee, ayoung, i think we need to just put a stake in the ground and say X option overrides Y option, here is a warning | 16:24 |
| morganfainberg | gyee, ayoung, in fact--- we should have done that to begin with | 16:25 |
| ayoung | gyee, and if they do not agree they get an error | 16:25 |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: oslo.db implementation https://review.openstack.org/77210 | 16:25 |
| *** thiagop has quit IRC | 16:25 | |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 16:25 |
| gyee | ayoung, that's not what that test is for, it is specially for only if token_format is set | 16:25 |
| *** tellesnobrega has quit IRC | 16:25 | |
| gyee | it not for defualt provider | 16:25 |
| jorgew | morganfainberg: 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 IRC | 16:26 | |
| morganfainberg | jorgew, so what is the barrier for what users can use the region. | 16:26 |
| *** jsavak has joined #openstack-keystone | 16:26 | |
| *** rodrigods has quit IRC | 16:26 | |
| morganfainberg | jorgew, users/projects/whatever | 16:26 |
| *** i159 has quit IRC | 16:26 | |
| gyee | morganfainberg, sure, has OpenStack as whole came to an agreement on the deprecation process yet. :) | 16:26 |
| gyee | maybe I missed the official announcement | 16:26 |
| morganfainberg | gyee, make the setting of the format override the provider, throw a big warning | 16:26 |
| jorgew | morganfainberg, 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 |
| ayoung | joesavak, jorgew, https://twitter.com/admiyoung/status/478936760337301505/photo/1 | 16:27 |
| ayoung | that is the client driven use case | 16:27 |
| ayoung | I could draw one up for heat, but just change "client" to "heat" and you've got it | 16:27 |
| morganfainberg | gyee, since we default the provider option now. | 16:27 |
| marekd | morganfainberg: 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 |
| marekd | is up to you | 16:27 |
| gyee | morganfainberg, the warning has always been there I think | 16:27 |
| gyee | question is when do we stop supporting token_format option | 16:27 |
| marekd | and probably you do this in a way you do with your real 'local' regions. | 16:28 |
| dstanek | jorgew: 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 provider | 16:28 |
| morganfainberg | gyee, set a timeline | 16:28 |
| ayoung | gyee, lets "break" it for now | 16:28 |
| jorgew | ayoung, 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 |
| ayoung | and by break, I mean, let people know that things are changing | 16:28 |
| morganfainberg | gyee, K? | 16:28 |
| morganfainberg | gyee, it's been deprecated for a while. | 16:28 |
| ayoung | jorgew, that is irrelevant to keystone, though | 16:28 |
| ayoung | that is my point | 16:28 |
| *** joesavak has quit IRC | 16:28 | |
| jorgew | dstenek, yes | 16:28 |
| morganfainberg | gyee, it's reasonable to make the change in K, just make the token format option win until it is gone | 16:28 |
| ayoung | jorgew, whomever is making the decision converts a local token for a remote. | 16:29 |
| ayoung | remote keystone is in the local service catalog as the "burst" keystone | 16:29 |
| morganfainberg | gyee, 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 |
| gyee | morganfainberg, sure, would be nice if OpenStack as whole can formally endorse a deprecation process | 16:29 |
| morganfainberg | gyee, so it falls outside the deprecation topic we had before | 16:29 |
| jorgew | ayoung, okay fair enough. So what if that code lives in middle ware :-) | 16:29 |
| morganfainberg | gyee, which was deprecating something other services use. | 16:29 |
| morganfainberg | gyee, not purely operator | 16:29 |
| gyee | morganfainberg, no, that's an external facing option | 16:30 |
| morganfainberg | gyee, where? | 16:30 |
| jorgew | ayoung, keystone still needs to provide the sevice catalog bit right? | 16:30 |
| dstanek | jorgew: 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 jimbaker | 16:31 | |
| gyee | isn't everything in keystone.conf public? they are not APIs, but they are being used in the field | 16:31 |
| dstanek | keystone1 would present SAML assertions (or something) to keystone2 and that would issue a token | 16:31 |
| jorgew | dstanek, yea, as long as the process is hidden by the user, the idea is to reuse those flows | 16:31 |
| ayoung | jorgew, 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 work | 16:32 |
| morganfainberg | gyee, 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 |
| marekd | jorgew: but then you want a one keystone acting on behalf of the user himself? | 16:32 |
| ayoung | jorgew, I don't know if I would suggest doing it from middleware. My kneejerk reaction is No. | 16:32 |
| *** sbfox1 has joined #openstack-keystone | 16:33 | |
| *** richm has joined #openstack-keystone | 16:33 | |
| morganfainberg | gyee, the change i propose is 2 bits: 1) token_format wins if set., 2) plan to remove the option in K. | 16:33 |
| morganfainberg | gyee, tell operators/deployers the new option should be used in the warning message (already done). | 16:33 |
| ayoung | gyee, 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 IRC | 16:33 | |
| morganfainberg | gyee, and when the old option will go away | 16:33 |
| jorgew | ayoung, in order to really allow burst endpoints to work easily then you'd need software to glue the pieces together. | 16:33 |
| ayoung | morganfainberg, I can live with that. | 16:34 |
| ayoung | jorgew, right. | 16:34 |
| ayoung | jorgew, so the division of labor is "what does keystone provide" vs "who calls it" | 16:34 |
| jorgew | morganfainberg, 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 |
| ayoung | jorgew, now...all the other issues I brought up before still apply | 16:34 |
| gyee | morganfainberg, I have zero problem with deprecating stuff :) All I am saying is is there a way to make it less chaotic | 16:35 |
| ayoung | namelyL 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 rescoping | 16:35 |
| morganfainberg | this is def. a bit more clear now. | 16:35 |
| morganfainberg | gyee, :) i think reducing the crazy logic down and saying when we remove the option will solve exactly that, waaay less chaotic | 16:35 |
| marekd | haha, after we redefined 'what we do', we are again at the 'how we do that' point :) | 16:36 |
| ayoung | morganfainberg, so if token_format is set, it just wins? Ugh | 16:36 |
| ayoung | that is probably wrong | 16:36 |
| morganfainberg | ayoung, nope, principle of least surprise | 16:36 |
| *** amerine has quit IRC | 16:36 | |
| morganfainberg | ayoung, and we make the warning message clear that the other option is ignored (same in the help text) | 16:36 |
| ayoung | morganfainberg, that would surprise the heck out of someone that explicitly set both token_format and token.Provider | 16:37 |
| *** leseb has quit IRC | 16:37 | |
| *** jorgew has left #openstack-keystone | 16:37 | |
| morganfainberg | ayoung, you're a developer. | 16:37 |
| gyee | ayoung, that's exactly what that test is for, token_format is set, but no token provider | 16:37 |
| *** amerine has joined #openstack-keystone | 16:37 | |
| dstanek | ayoung: here is what i was thinking just now https://www.dropbox.com/s/lmkoswv67n0ggj8/2014-06-17%2012.34.41.jpg | 16:37 |
| ayoung | gyee, BUT NOW THERE IS! | 16:37 |
| *** leseb has joined #openstack-keystone | 16:37 | |
| ayoung | dstanek, is this going to hurt my neck? | 16:37 |
| ayoung | dstanek, yeah, that is | 16:38 |
| marekd | dstanek: what N2 says to the user? | 16:38 |
| marekd | dstanek: "sorry....(?)" | 16:38 |
| ayoung | dstanek, https://twitter.com/admiyoung/status/478936760337301505/photo/1 | 16:38 |
| gyee | ayoung, old config, per grenade, new code must work with old config | 16:38 |
| dstanek | "sorry need to federate (with a link to k2)" | 16:38 |
| gyee | if we don't care about old configs, then sure, fuck it | 16:39 |
| ayoung | gyee, we make it an explicit choice. | 16:39 |
| morganfainberg | gyee, hence why i think otken_format wins | 16:39 |
| marekd | dstanek: do we want to put this federation workflow into nova, glance etc? | 16:39 |
| dstanek | marekd: not exactly that because i drew in a hurry, but think how federation works now | 16:39 |
| morganfainberg | gyee, and probably should have won in the original code (with the warning message) | 16:39 |
| marekd | dstanek: yes, except it's at the Keystone level | 16:39 |
| dstanek | marekd: doesn't that happen now through authtoken? | 16:39 |
| morganfainberg | gyee, vs. a config error raised if both were set. | 16:39 |
| marekd | dstanek: authtoken is used in nova, glance etc, right (i don't know that) | 16:40 |
| marekd | ? | 16:40 |
| dstanek | marekd: maybe i need to learn a little more about our federation flow | 16:40 |
| gyee | morganfainberg, that logic sounds reasonable | 16:40 |
| marekd | dstanek: so, you always go to the keystone....remote keystone | 16:40 |
| morganfainberg | gyee, lets go with that plan so we can get the compressed tokens in :) | 16:40 |
| dstanek | marekd: in a client centric flow i think so | 16:41 |
| ayoung | morganfainberg, this is what we do now http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/provider.py#n78 | 16:41 |
| dstanek | not saying that is what i would want, but that is what i saw from ayoung's diagram | 16:41 |
| gyee | morganfainberg, oh yeah, +++++ for compressed tokens, just want to make sure we don't break backward compatibility | 16:41 |
| dstanek | marekd: ^ | 16:41 |
| morganfainberg | ayoung, and i think that whole block of logic was wrong from the get-go | 16:41 |
| *** leseb has quit IRC | 16:42 | |
| ayoung | morganfainberg, so...if we leave token_format...I'll drop making PKIZ the default provider in the conf file, and instead just hack this logic | 16:42 |
| morganfainberg | ayoung, no. | 16:42 |
| marekd | dstanek: whch picture? client driven? | 16:42 |
| morganfainberg | ayoung, we make token_format win _if_set_ and only if set | 16:42 |
| marekd | which | 16:42 |
| morganfainberg | ayoung, PKIZ is the default provider | 16:42 |
| dstanek | marekd: yes | 16:42 |
| ayoung | morganfainberg, new patch in a few | 16:42 |
| morganfainberg | ayoung, if both are set, no error is raised | 16:42 |
| *** Benj__ has quit IRC | 16:43 | |
| morganfainberg | ayoung, jsut token_format is the winner (and the test is changed to confirm that) | 16:43 |
| *** harlowja_away is now known as harlowja | 16:43 | |
| marekd | dstanek: but it looks like nova client goes to a K2 | 16:43 |
| marekd | and gets a new token | 16:43 |
| ayoung | marekd, 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 |
| morganfainberg | ayoung, might want to make that change a separate patch - or i could hack it up in a quick minute or two. | 16:44 |
| morganfainberg | ayoung, then easy rebase of your patch on top. | 16:44 |
| morganfainberg | henrynash, ayoung, gyee, mind pressing go on https://review.openstack.org/#/c/100545/ | 16:44 |
| ayoung | morganfainberg, +A | 16:45 |
| morganfainberg | ayoung, tyvm | 16:45 |
| dstanek | marekd: yes, in my mind that was a result of presenting federation assertions from k1 | 16:45 |
| marekd | dstanek: aaaa, i thought h wanted to present a OS token issued by K1 | 16:45 |
| * gyee never going to get into a jeopardy with ayoung. He's got fast fingers. :) | 16:46 | |
| marekd | dstanek: but actually it looks more like OpenSTack token, not SAML assertion. | 16:46 |
| marekd | ayoung: ^^ ? | 16:46 |
| marekd | ayoung: in your "client driven" picture - what do you send to K-Burst- | 16:47 |
| ayoung | marekd, T1 | 16:47 |
| ayoung | and get T2 | 16:47 |
| *** beav has joined #openstack-keystone | 16:47 | |
| marekd | an openstack token. | 16:47 |
| ayoung | then send T2 to N2 | 16:47 |
| ayoung | yes | 16:47 |
| *** erecio has quit IRC | 16:47 | |
| marekd | ok, that's my understanding. | 16:47 |
| ayoung | marekd, this is completely sidestepping authentication issues | 16:47 |
| ayoung | for client driven, use the smae authentication mechanism | 16:47 |
| dstanek | marekd: that's what i want to do - i think the proposal is the have k2 handle tokens from k1 | 16:48 |
| ayoung | for service driven, use trusts | 16:48 |
| *** erecio has joined #openstack-keystone | 16:48 | |
| *** htruta has joined #openstack-keystone | 16:49 | |
| *** rodrigods has joined #openstack-keystone | 16:49 | |
| *** raildo has joined #openstack-keystone | 16:49 | |
| openstackgerrit | Roman Bodnarchuk proposed a change to openstack/keystone: Return 400 in case request body is JSON, but not a dictionary https://review.openstack.org/92809 | 16:49 |
| marekd | dstanek: handle and issue a new token. | 16:49 |
| marekd | dstanek: later to be used agains N2 | 16:49 |
| *** hrybacki_ has joined #openstack-keystone | 16:52 | |
| *** tellesnobrega has joined #openstack-keystone | 16:52 | |
| marekd | Ok 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|away | 16:53 | |
| *** amerine_ has joined #openstack-keystone | 16:54 | |
| morganfainberg | ayoung, gyee, was thinking something like this: http://paste.openstack.org/show/84322/ | 16:54 |
| *** amerine__ has joined #openstack-keystone | 16:55 | |
| *** hrybacki has quit IRC | 16:56 | |
| *** hrybacki_ has quit IRC | 16:56 | |
| ayoung | morganfainberg, way ahead of you | 16:56 |
| morganfainberg | ayoung, cool | 16:56 |
| gyee | morgainfainberg, looks fine | 16:57 |
| *** harlowja has quit IRC | 16:57 | |
| gyee | make sure the existing tests still works though | 16:57 |
| morganfainberg | gyee, will need a minor change i think, but yes. | 16:57 |
| *** amerine has quit IRC | 16:58 | |
| morganfainberg | as 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 IRC | 16:59 | |
| *** erecio has quit IRC | 17:00 | |
| *** bklei has joined #openstack-keystone | 17:00 | |
| *** erecio has joined #openstack-keystone | 17:00 | |
| *** harlowja has joined #openstack-keystone | 17:01 | |
| *** nkinder_ has joined #openstack-keystone | 17:04 | |
| *** rodrigods has quit IRC | 17:04 | |
| *** nkinder has quit IRC | 17:04 | |
| *** sbfox1 has left #openstack-keystone | 17:06 | |
| morganfainberg | gyee, jamielennox, stevemar, henrynash, https://review.openstack.org/#/c/95973/ if you have a bit of time to look over this today, it would be great | 17:06 |
| morganfainberg | dolphm, ^ (ack, missed ya there) | 17:06 |
| gyee | k, looking | 17:06 |
| stevemar | how is that not approved it | 17:07 |
| dstanek | are there any specific specs we'll be going over today in the meeting? | 17:07 |
| *** leseb has joined #openstack-keystone | 17:08 | |
| openstackgerrit | Christoph Gysin proposed a change to openstack/keystone: fix flake8 issues https://review.openstack.org/100628 | 17:08 |
| morganfainberg | dstanek, the middleware one and the session token ones | 17:08 |
| morganfainberg | dstanek, other than that the others that are still open are open for discussion | 17:08 |
| gyee | stevemar, I am looking for extra space, typos, etc right now :) | 17:08 |
| *** marcoemorais1 has quit IRC | 17:10 | |
| *** marcoemorais has joined #openstack-keystone | 17:10 | |
| *** tellesnobrega has quit IRC | 17:10 | |
| *** raildo has quit IRC | 17:11 | |
| dstanek | morganfainberg: looking that the v3 extensions spec now...what about json-home? | 17:12 |
| *** htruta has quit IRC | 17:12 | |
| dstanek | there was talk of doing that. how does this compare/contrast/etc. | 17:12 |
| dstanek | ? | 17:12 |
| morganfainberg | dstanek, not mutually exclusive | 17:12 |
| morganfainberg | dstanek, json home could be implemneted later on | 17:12 |
| *** leseb has quit IRC | 17:13 | |
| *** nsquare has joined #openstack-keystone | 17:13 | |
| dstanek | morganfainberg: would that change the structure of this data at all? | 17:13 |
| morganfainberg | dstanek, bknudson indicated JSON home could be implemeted with no impact to the v3 one | 17:14 |
| dolphm | morganfainberg: more directly, is this not made redundant by json home? | 17:14 |
| morganfainberg | dolphm, it is. but json home was specifically stated as more up in the air | 17:14 |
| morganfainberg | dolphm if we would rather do JSON home, that's fine | 17:14 |
| dolphm | morganfainberg: why is it more up in the air? | 17:15 |
| morganfainberg | dolphm, 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 |
| dolphm | morganfainberg: 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 uses | 17:17 |
| morganfainberg | dolphm, i'm perfectly fine squashing this one and saying lets do JSON home | 17:17 |
| morganfainberg | dolphm, i was going by the original discussion with bknudson that this one was an easy target. | 17:17 |
| dolphm | the 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 either | 17:18 |
| morganfainberg | dolphm, 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 |
| gyee | is openstack as a whole standardizing on JSON home? | 17:20 |
| dstanek | dolphm: morganfainberg: does json-home provide guidance for this sort of thing? | 17:20 |
| dolphm | morganfainberg: 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 otehr | 17:21 |
| morganfainberg | dstanek, http://tools.ietf.org/html/draft-nottingham-json-home-03 i need more coffee before i can comment on that | 17:21 |
| dolphm | gyee: there's not an alternative, other then the homegrown crap that we've all gotten wrong | 17:21 |
| bknudson | I'm fine with JSON Home rather than advertise extensions in /v3 | 17:22 |
| * morganfainberg defers to bknudson here. | 17:22 | |
| dolphm | dstanek: is there some specific aspect of GET /v3/extensions you're looking for in json home? | 17:22 |
| gyee | dolphm, k, lets roll with JSON home then | 17:22 |
| morganfainberg | bknudson, if you're fine with JSON home, and it's better.. lets just go with that :) | 17:22 |
| dolphm | is there a jsonhome lib? | 17:23 |
| bknudson | dolphm: I didn't find a lib for jsonhome | 17:23 |
| morganfainberg | dolphm, dunno, i think json home isn't fully finalized yet - so | 17:23 |
| dolphm | morganfainberg: ack, but the last 2 or 3 drafts have maintained backwards compat | 17:23 |
| dolphm | i never looked at draft 1 | 17:23 |
| bknudson | marconi doesn't use a lib for json home | 17:24 |
| morganfainberg | dolphm, right, my guess is it's pretty new. hence no lib yet | 17:24 |
| gyee | ++ for standard, -- for homegrown crab (only if its inhalable :D) | 17:24 |
| bknudson | really it's just a JSON document, so it's just hardcoded | 17:24 |
| dstanek | dolphm: no, just trying to understand all of the things we want to do and how they tie together | 17:24 |
| dolphm | bknudson: it should be dynamic, given a dynamic pipeline | 17:25 |
| dolphm | bknudson: all i'm really thinking about is validation/jsonschema for it | 17:26 |
| *** bklei has quit IRC | 17:28 | |
| bknudson | dolphm: can't find anything for jsonschema for json home. | 17:28 |
| dolphm | bknudson: neither can i | 17:28 |
| bknudson | here's the marconi code: http://git.openstack.org/cgit/openstack/marconi/tree/marconi/queues/transport/wsgi/v1_1/homedoc.py?id=6f039e32bcd9897442d2a61bd9eae5c387eaea9c | 17:29 |
| morganfainberg | i need to go get coffee before meeting. be back shortly | 17:29 |
| bknudson | they apparently don't have much in the way of resources | 17:29 |
| *** praneshp has joined #openstack-keystone | 17:33 | |
| *** joesavak has joined #openstack-keystone | 17:33 | |
| dstanek | is there any guidance for dealing with images in specs? | 17:36 |
| *** jsavak has quit IRC | 17:36 | |
| bknudson | dstanek: ascii art | 17:36 |
| dstanek | bknudson: ha, i hope that's not it :-) | 17:36 |
| bknudson | dstanek: you mean a diagram? | 17:37 |
| dstanek | bknudson: yes, i want to attach a diagram to the pec i'm working on | 17:38 |
| *** amerine__ is now known as amerine | 17:38 | |
| *** einarf has joined #openstack-keystone | 17:39 | |
| *** htruta has joined #openstack-keystone | 17:40 | |
| bknudson | dstanek: there was a web tool for making ascii art diagrams... I didn't keep a link. | 17:40 |
| gyee | dstanek, bknudson, same as blueprint I suppose, have your diagram in openstack wiki and provide a link to it | 17:40 |
| bknudson | asciiflow.com | 17:40 |
| openstackgerrit | A change was merged to openstack/keystone: pkiz String conversion https://review.openstack.org/100545 | 17:41 |
| *** joesavak has quit IRC | 17:44 | |
| *** browne has joined #openstack-keystone | 17:45 | |
| henrynash | can 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.rst | 17:45 |
| henrynash | I’ve had this problem for a while…. | 17:46 |
| henrynash | (locally that is) | 17:46 |
| dolphm | i 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- morganfainberg | 17:47 |
| dolphm | henrynash: you probably have stray pyc files in your tree | 17:48 |
| dstanek | henrynash: you may have some garbage in your docs dir | 17:48 |
| *** tellesnobrega has joined #openstack-keystone | 17:48 | |
| dolphm | henrynash: find . -name "*.pyc" -delete | 17:48 |
| henrynash | actually…not sure docs/api still is valid at all is it? | 17:48 |
| dolphm | henrynash: i don't have that dir, actually | 17:49 |
| henrynash | hmm, yes, not sure how I come to have it…think that’s the source of my problmes! | 17:49 |
| henrynash | I’ll ditch it! | 17:49 |
| henrynash | thx | 17:49 |
| *** einarf_ has joined #openstack-keystone | 17:49 | |
| dstanek | when 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 errors | 17:50 |
| stevemar | henrynash, rm -rf docs/build | 17:50 |
| dstanek | also the api direct that gets created - that's where the rst for the code goes | 17:51 |
| stevemar | but yeah, dstanek summed it up | 17:51 |
| stevemar | oh yeah | 17:51 |
| henrynash | dtsanek: got it in one | 17:51 |
| morganfainberg | dolphm, correct. | 17:51 |
| henrynash | dtsanek: thx | 17:51 |
| *** einarf has quit IRC | 17:51 | |
| *** einarf_ is now known as einarf | 17:51 | |
| dolphm | henrynash: you can also do $ git clean -nd # to see what is in your tree that's not in the repo | 17:51 |
| henrynash | dolphm: hmm, nice cmd! | 17:52 |
| morganfainberg | dolphm, the vote was a "no major issues with direction we like the approach" once that passed, then it was 2x+2 and +A | 17:52 |
| dstanek | henrynash: does you latest multi-backend review contain the fixes i made in separate patches? | 17:52 |
| dolphm | morganfainberg: other than meeting notes, were we tracking meeting-approved specs somewhere? | 17:52 |
| morganfainberg | dolphm, only meeting notes so far | 17:52 |
| henrynash | dstanek: no, didn’t weant to steal your thunder…but I am happy to pull those in if you like | 17:53 |
| dolphm | morganfainberg: so then looking at the summary, which ones passed? http://eavesdrop.openstack.org/meetings/keystone/2014/keystone.2014-06-10-18.01.html | 17:53 |
| morganfainberg | service token,, api-validation, V3 extennsion advertise, Audit notifications, | 17:54 |
| dolphm | morganfainberg: there aren't really any unclear votes, but take "JSON Home" for example: 3 yes, 3 table. what does that outcome mean? | 17:54 |
| dstanek | henrynash: 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 commits | 17:55 |
| morganfainberg | dolphm, and henrynash's multi user_id one (earlier) | 17:55 |
| morganfainberg | dolphm, the rest were tabled, session tokens and middleware didn't receive a vote | 17:55 |
| henrynash | dstanek: I’ll pull them in that case…. | 17:55 |
| dolphm | morganfainberg: session tokens is the last one on there | 17:55 |
| henrynash | dstanek: thanks for taking the time to do them in the first place | 17:56 |
| morganfainberg | dolphm, we didn't get a full vote, time | 17:56 |
| dolphm | ah | 17:56 |
| morganfainberg | dolphm, so we ended before the vote had really been logged | 17:56 |
| *** bklei has joined #openstack-keystone | 17:56 | |
| dstanek | henrynash: no problem | 17:56 |
| *** alligator has left #openstack-keystone | 17:57 | |
| dstanek | henrynash: https://review.openstack.org/#/c/99416/1/doc/source/developing.rst - there were a couple of things commented on there that i didn't see | 17:57 |
| henrynash | dstanek: yep, see them, I’ll fix them up | 17:58 |
| dstanek | henrynash: thx | 17:58 |
| *** marekd|away is now known as marekd | 17:59 | |
| *** bklei has quit IRC | 18:03 | |
| *** hrybacki has joined #openstack-keystone | 18:04 | |
| *** leseb has joined #openstack-keystone | 18:08 | |
| *** leseb has quit IRC | 18:13 | |
| stevemar | dstanek, i was going to advise the folks who made the comments to supply fixes :) | 18:17 |
| dstanek | stevemar: looks like henrynash already has it taken care of | 18:18 |
| openstackgerrit | ayoung proposed a change to openstack/keystone: Default to PKIZ tokens https://review.openstack.org/98897 | 18:18 |
| dstanek | stevemar: but yeah it would be good to nudge people into being more proactive | 18:18 |
| ayoung | gyee, think you will like ^^ | 18:18 |
| *** jkappert has quit IRC | 18:19 | |
| *** jkappert has joined #openstack-keystone | 18:19 | |
| morganfainberg | ayoung, i want that conflict exception gone personally. | 18:19 |
| morganfainberg | ayoung, i still think it's wrong | 18:19 |
| ayoung | morganfainberg, yeah, but it is what we do now | 18:20 |
| stevemar | does anyone have an opinion on the new hacking rules / potential revert back to 0.8? | 18:20 |
| stevemar | i threw up a patch for keystoneclient, but for keystone itself, would be a good chunk of work | 18:21 |
| * dolphm has been staring at this channel for a good minute wondering how we got off the meeting topic. | 18:22 | |
| stevemar | dolphm, the channel seems to be eerily quiet | 18:24 |
| dolphm | which made me feel dumber | 18:24 |
| stevemar | dolphm, bump? | 18:25 |
| morganfainberg | ayoung, 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 |
| dolphm | morganfainberg: logic of what? | 18:32 |
| *** harlowja has quit IRC | 18:33 | |
| bknudson | stevemar: apparently the reason to not make hacking changes now was that the changes were clogging up the gate? | 18:36 |
| dstanek | stevemar: i haven't seen to new rules | 18:37 |
| morganfainberg | dolphm, 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 |
| stevemar | bknudson, but even if we were lazy about it, we could just ignore the rules that are being broken in tox.ini, and fix it slowly | 18:38 |
| morganfainberg | dolphm, 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 it | 18:38 |
| stevemar | bknudson, i dunno, didn't seem unreasonable to me | 18:38 |
| bknudson | I think that's how you're supposed to do the hacking changes, first add a change with them all ignored | 18:39 |
| bknudson | then stop ignoring and fix each one | 18:39 |
| bknudson | might be on a wiki somewhere | 18:39 |
| * stevemar shrugs, | 18:39 | |
| stevemar | i figure its OK to fix a few in one patch too | 18:39 |
| *** harlowja has joined #openstack-keystone | 18:40 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: multi-backend support for identity https://review.openstack.org/74214 | 18:41 |
| *** joesavak has joined #openstack-keystone | 18:42 | |
| *** CaioBrentano has quit IRC | 18:48 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: multi-backend support for identity https://review.openstack.org/74214 | 18:53 |
| ayoung | henrynash, if the default salt is no salt, then adding salt can be a backwards compatible patch with not much effort | 18:59 |
| henrynash | ayoung: although it would have to be off by default or teh IDs would change | 18:59 |
| ayoung | henrynash, if the default salt is no Salt, that works | 19:00 |
| henrynash | ayoung: agreed….you just can’t change it once you’re up and running | 19:00 |
| ayoung | henrynash not without sever pain | 19:01 |
| ayoung | severe even | 19:01 |
| henrynash | ayoung: agreed | 19:01 |
| dstanek | what are we salting? | 19:02 |
| ayoung | henrynash, so you think that the people that want salting will need it in the first revision | 19:02 |
| morganfainberg | dstanek, lunch? | 19:03 |
| dstanek | morganfainberg: ++ | 19:03 |
| morganfainberg | dstanek, i think we're salting lunch | 19:03 |
| dstanek | morganfainberg: that's over here - onward toward dinner | 19:03 |
| bknudson | the hash of the ID | 19:03 |
| henrynash | dstanek: 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 person | 19:04 |
| henrynash | dstanek: if you’re not in the default domain, there is no issue | 19:04 |
| dstanek | henrynash: ah, i see. would the salt be a part of the resulting ID so that it would be recreated? | 19:04 |
| henrynash | dtsanek: 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 |
| henrynash | morganfainberg: hmm, tasty | 19:05 |
| dstanek | i was thinking the salt was for protecting against crypto-analysis - i'll keep my mouth shut now | 19:06 |
| henrynash | ]morganfainberg: lunch, that is :-) | 19:06 |
| ayoung | jamielennox, I resubmitted the session-for-auth_token patch | 19:07 |
| *** erecio has quit IRC | 19:07 | |
| ayoung | let me know if what I submitted is sane | 19:07 |
| ayoung | please | 19:07 |
| henrynash | ayoung: 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 anyway | 19:08 |
| *** erecio has joined #openstack-keystone | 19:08 | |
| ayoung | henrynash, I'd say "no" then | 19:08 |
| ayoung | if you want "salt" you can get it by using a new domain id | 19:08 |
| ayoung | and that should have the same net effect | 19:08 |
| henrynash | ayoung: yep | 19:09 |
| *** leseb has joined #openstack-keystone | 19:09 | |
| ayoung | henrynash, OK, so you are going to split the patch? I assume the "centralize id generation" part first? | 19:09 |
| henrynash | ayoung: I guess that was the concensus…so yes! | 19:09 |
| jamielennox | ayoung: it's broken - | 19:10 |
| jamielennox | ayoung: for whatever reason i can't remove the admin_token from trove, i think devstack builds from stable not master | 19:10 |
| ayoung | henrynash, please submit it with copious comments using British specific terms like Lorrie and Kippers | 19:10 |
| jamielennox | ayoung: so it supplies both an admin token and a user/pass - and it would be a patch to stable-maint to fix that | 19:10 |
| morganfainberg | ayoung, 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 |
| jamielennox | so i need to redo the plugin there and make it do the proper fallback | 19:11 |
| ayoung | morganfainberg, it was to make it through grenade | 19:11 |
| morganfainberg | ayoung, if signing.token_format wins it should make it through grenade, right? | 19:11 |
| ayoung | jamielennox, cool. Just so as you are aware, hrybacki is working on the revocation events patch, and is depending on that session work | 19:11 |
| bknudson | jamielennox: isn't this a bug that you were fixing? (don't fallback to password if given a token?) | 19:11 |
| ayoung | morganfainberg, yes. | 19:12 |
| morganfainberg | ayoung, so why raise an exception? | 19:12 |
| ayoung | morganfainberg, we just put an additional check if the token providerr is out of sync with it | 19:12 |
| morganfainberg | ayoung, lets remove the "out of sync" part | 19:12 |
| henrynash | ayoung: spiff-oh! | 19:12 |
| morganfainberg | thats what i think we're doing wrong | 19:12 |
| ayoung | morganfainberg, it means that they edited their config file by hand and put in something that makes no sense | 19:12 |
| jamielennox | bknudson: yes, but as i said trove seems to build from stable in devstack (or something) and so i couldn't get it to stop | 19:12 |
| ayoung | henrynash, Amoke me a kipper. I'll be back for breakfast! | 19:13 |
| ayoung | Smoke | 19:13 |
| bknudson | jamielennox: weird... so that change in behavior broke trove? | 19:13 |
| jamielennox | yes, they ship with an admin_token in release, then add a user and pass in devstack | 19:14 |
| gyee | morganfainberg, 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 |
| morganfainberg | ayoung, i disagree with the previous choice to detect and raise on that | 19:14 |
| jamielennox | i can't remember why i didn't just fix it in devstack... | 19:14 |
| morganfainberg | gyee, option 4 nets us PKIZ in either case | 19:14 |
| *** leseb has quit IRC | 19:14 | |
| ayoung | morganfainberg, 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 new | 19:14 |
| ayoung | this is the handholding stage | 19:14 |
| morganfainberg | ayoung, you're not going to convince me, sorry | 19:15 |
| morganfainberg | ayoung, we did it wrong before, we're continuing to do it wrong, just make the old option, set by hand, win. | 19:15 |
| gyee | morganfainberg, correct, option 4 nets pkiz | 19:15 |
| morganfainberg | it doesn't break the old configs it doesn't break anyone explicitly setting the provider | 19:15 |
| ayoung | morganfainberg, meh. I don't rally care that much | 19:15 |
| gyee | option 4 basically says gimme the default | 19:15 |
| morganfainberg | and it doesn't break new configs | 19:15 |
| ayoung | it will jsut be harder to debug when someone fat fingers it | 19:15 |
| *** marekd is now known as marekd|away | 19:16 | |
| ayoung | gyee, do you really care? I can drop the raise | 19:16 |
| ayoung | rasie the drop? | 19:16 |
| ayoung | drop the beat. | 19:16 |
| gyee | drop the beat! :D | 19:16 |
| ayoung | beat the drop | 19:16 |
| jamielennox | bknudson: yep, devstack uses icehouse stable - no idea why: git_clone git://git.openstack.org/openstack/trove.git /opt/stack/new/trove stable/icehouse | 19:16 |
| ayoung | gyee, if you are OK with morganfainberg ' | 19:16 |
| ayoung | s approach, I'll make it happen now | 19:17 |
| jamielennox | so the patch would need to be backported - not sure if that's appropriate | 19:17 |
| bknudson | jamielennox: the patch to have trove not set its own admin token? | 19:17 |
| gyee | morgainfainberg, there was a bug on the explicit check I think | 19:17 |
| jamielennox | bknudson: yes | 19:17 |
| morganfainberg | gyee, we would need a minor change to the test i think | 19:17 |
| gyee | to make sure token_format agrees with the provider | 19:17 |
| morganfainberg | gyee, i'm saying drop the "make sure the provider matches token_format" check completely | 19:18 |
| morganfainberg | gyee, always let token_format win if set (and log a nice fat warning like we do now) | 19:18 |
| bknudson | jamielennox: I guess we should add a test for having auth_token fallback to password auth if the token fails | 19:19 |
| morganfainberg | gyee, 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 |
| gyee | morganfainberg, I see, yeah that's sounds fine too, as long as we have the warning | 19:19 |
| * ayoung is caring less each passing minute | 19:19 | |
| ayoung | ok, I call that consensus | 19:20 |
| dolphm | thanks everyone for not coming to the identity program update webinar and not harassing me with terrible questions :) | 19:20 |
| gyee | ayoung, ++ | 19:20 |
| bknudson | it wasn't widely advertised | 19:20 |
| morganfainberg | ayoung, 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 |
| morganfainberg | dolphm, there was a webinar? | 19:21 |
| gyee | dolphm, like when do we support federation? :) | 19:21 |
| dolphm | morganfainberg: yeah, they're all recorded anyway | 19:21 |
| bknudson | I'm way behind on my mailing list reading | 19:21 |
| morganfainberg | dolphm, but... i wanted to ask inane questions! | 19:21 |
| dolphm | gyee: i covered that in the presentation if you were paying attention | 19:21 |
| gyee | haha | 19:21 |
| morganfainberg | ayoung, dolphm, what was the decision on priority of middleware split? | 19:22 |
| dolphm | morganfainberg: that it's a priority :) | 19:22 |
| morganfainberg | dolphm, as in, we're doing it first? or j3? | 19:23 |
| jamielennox | bknudson: yea, we had decided to break that compatability - but it might be easier to just do it | 19:23 |
| morganfainberg | dolphm, if we're doing it now, i'll get all the stuff going so it's ready for friday. | 19:23 |
| morganfainberg | if not, i'll work on other things :) | 19:23 |
| dolphm | morganfainberg: non-persistent tokens! | 19:23 |
| morganfainberg | dolphm, get the spec approved! :) | 19:23 |
| morganfainberg | mod_wsgi gate is very close as well | 19:24 |
| morganfainberg | just need the default PKIZ provider patch and i can change us over. | 19:24 |
| gyee | yay! | 19:24 |
| dolphm | morganfainberg: link? | 19:24 |
| dolphm | i know i saw that today | 19:24 |
| morganfainberg | dolphm, https://review.openstack.org/#/c/98897 | 19:24 |
| bknudson | there were complaints that the gate tests can't support postgres, so are they fine with adding keystone under wsgi? | 19:24 |
| dolphm | https://review.openstack.org/#/c/98897/ | 19:24 |
| morganfainberg | dolphm, the one i just was talking to gyee and ayoung about | 19:24 |
| morganfainberg | bknudson, the default will be mod_wsgi | 19:25 |
| morganfainberg | bknudson, and we'll make one of them run eventlet | 19:25 |
| gyee | bknudson, are they related? | 19:25 |
| morganfainberg | bknudson, no extra gate-jobs | 19:25 |
| bknudson | ok | 19:25 |
| *** dims_ has quit IRC | 19:25 | |
| bknudson | makes sense | 19:25 |
| morganfainberg | it's all driven by devstack and devstack-gate | 19:25 |
| gyee | how's mod_wsgi and postgres related? | 19:25 |
| bknudson | this is great because we've got a team here runs keystone under mod_wsgi | 19:25 |
| morganfainberg | gyee, it isn't | 19:25 |
| morganfainberg | bknudson, and this will make it so we can recommend mod_wsgi as the default deployment choice :) | 19:26 |
| morganfainberg | gyee, the postgres thing was "it's expensive resource wise to run extra tempest runs just to test postgres" | 19:27 |
| bknudson | gyee: 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 reason | 19:27 |
| gyee | i c | 19:27 |
| morganfainberg | instead they combined postgres w/ neutron and added a nova-specific test for nova-net+postgres | 19:27 |
| *** hrybacki has quit IRC | 19:28 | |
| morganfainberg | so except for nova patches, 1 lest tempest run | 19:28 |
| gyee | bkudson, I did setup Apache with mod_authnz_ldap enabled btw | 19:28 |
| *** hrybacki has joined #openstack-keystone | 19:28 | |
| gyee | in my local dev | 19:28 |
| bknudson | gyee: which external auth plugin? | 19:28 |
| gyee | only issue is it has to work in conjunction with basic auth | 19:28 |
| gyee | I was investigating with mod_authnz_ldap performs any better than Keystone ldap code | 19:29 |
| *** hrybacki has quit IRC | 19:30 | |
| bknudson | I can't imagine anything worse than keystone's ldap code efficiency-wise. | 19:30 |
| gyee | bknudson, you are right :) | 19:31 |
| *** jsavak has joined #openstack-keystone | 19:31 | |
| *** joesavak has quit IRC | 19:34 | |
| *** beav has quit IRC | 19:34 | |
| morganfainberg | dolphm, 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 IRC | 19:37 | |
| bknudson | I don't think keystoneclient needs a hard requirement on middleware. | 19:37 |
| dolphm | morganfainberg: oh - that's exactly what i was thinking when we talked about that at the summit - forgot about that | 19:37 |
| jamielennox | bknudson: there is a backwards compatibility requirement | 19:37 |
| morganfainberg | bknudson, except that we want to provide the same location as a transition poiint? | 19:38 |
| dolphm | python-keystoneclient, python-keystonemiddleware and keystone all depend on... python-keystonelib? | 19:38 |
| bknudson | y, import it but don't add the requirement | 19:38 |
| bknudson | anybody wanting to use the optional feature will have to supply both of them | 19:38 |
| morganfainberg | bknudson, that doesn't really work for transition though, i don't think. | 19:39 |
| morganfainberg | dolphm, i think utility code should be external anyway (should it be oslo?) | 19:39 |
| dolphm | morganfainberg: the cms module? | 19:39 |
| morganfainberg | dolphm, yeah. | 19:40 |
| dolphm | morganfainberg: i don't think it should be oslo (it's not really cross-program) | 19:40 |
| morganfainberg | dolphm, works for me. | 19:40 |
| bknudson | an application importing keystoneclient doesn't automatically import the middlware | 19:40 |
| *** dims_ has joined #openstack-keystone | 19:40 | |
| morganfainberg | bknudson, but right now applications getting the middleware expect it to be installed when you install the client | 19:40 |
| bknudson | it would be nova, etc, that would have requirement on both | 19:40 |
| morganfainberg | can we make that broken unless you install both packages? | 19:41 |
| bknudson | one option is copy-paste the common parts for the transition period | 19:42 |
| morganfainberg | bknudson, options are: 1) copy-paste (ick), 2) split cms (etc) into keystonelib, 3) no hard-dep just the import in ksc | 19:42 |
| bknudson | how long is the transition period? a couple of weeks? | 19:42 |
| bknudson | years? | 19:42 |
| morganfainberg | bknudson, we went with a couple cycles when moving things from keystone to ksc | 19:43 |
| jamielennox | morganfainberg: right - but ksc shouldn't work like that | 19:43 |
| *** gyee has quit IRC | 19:43 | |
| morganfainberg | if we split cms out (not for or against) it does mean we don't need ksc for keystone to run. just the lighterweight lib | 19:43 |
| dstanek | morganfainberg: do you want it to be broken if you don't explicitly install both? | 19:44 |
| dstanek | you could have ksc depend on the new package for a transition period so that the other project can start explicitly depending on it | 19:44 |
| morganfainberg | dstanek, the only option i don't want is copy/pste | 19:44 |
| jamielennox | morganfainberg: i don't think this matters right - because CMS won't be the only dependency from auth_token -> ksc | 19:44 |
| jamielennox | i think it is at the moment - but session etc are slowly coming across | 19:45 |
| bknudson | auth_token is going to use session, too | 19:45 |
| morganfainberg | jamielennox, ah session eventually. | 19:45 |
| bknudson | maybe we need a keystone-session package? | 19:45 |
| jamielennox | and auth plugins - and the idea was that auth_token should consume all this from ksc eventually so that users could replicate it | 19:45 |
| jamielennox | stop having auth_token be such a special case | 19:45 |
| morganfainberg | i 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 |
| bknudson | my preference is skip the requirement on middleware in keystoneclient... seems like it's easy enough to install both. | 19:46 |
| morganfainberg | so both packages are explicitly installed to work | 19:46 |
| bknudson | both packages don't have to be installed to work... | 19:46 |
| morganfainberg | bknudson, 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 |
| dstanek | can you have one without the other? | 19:47 |
| bknudson | only to work when you're using keystoneclient middleware | 19:47 |
| jamielennox | right the dependency should go middleware -> client, the problem is that will break a lot of people on update | 19:47 |
| bknudson | dstanek: you can have keystoneclient without middleware | 19:47 |
| bknudson | jamielennox: nova, etc, will have middleware added to requirements.txt | 19:48 |
| *** leseb has joined #openstack-keystone | 19:48 | |
| morganfainberg | jamielennox, 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 |
| bknudson | maybe we need a no-op middleware so that we can add it to nova, etc. | 19:48 |
| morganfainberg | no-op? | 19:49 |
| jamielennox | so 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 |
| bknudson | y, it doesn't do anything. Then you can add it to nova requirements.txt | 19:49 |
| morganfainberg | or worse.. grizzly | 19:49 |
| bknudson | then change middleware to have auth_token | 19:49 |
| bknudson | then change nova,etc to use middleware.auth_token | 19:49 |
| morganfainberg | we could update havana nad icehouse to have the new req | 19:49 |
| bknudson | then remove keystoneclient from nova,etc (if they don't use it) | 19:50 |
| dstanek | the biggest problem is existing clouds will be broken if the client gets updated and the don't change their pipeline | 19:50 |
| bknudson | we could cap havana and icehouse | 19:50 |
| morganfainberg | grizzly is uncapped | 19:51 |
| jamielennox | my 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 work | 19:51 |
| morganfainberg | we could break a lot of installs. | 19:51 |
| bknudson | grizzly isn't supported | 19:51 |
| morganfainberg | bknudson, doesn't mean we should break it if we can avoid. | 19:51 |
| morganfainberg | maybe we deprecate the current middleware and say "hey go use this new package" | 19:51 |
| morganfainberg | but don't remove it for chunk of time | 19:51 |
| dstanek | would id be bad to have ksc import the new package and wrap it in a deprecated warning? | 19:52 |
| bknudson | seems like this is an issue for packagers. | 19:52 |
| bknudson | as a packager, it's not going to affect us. | 19:52 |
| morganfainberg | dstanek, the new package needs code form ksc is the real core of the problem | 19:52 |
| morganfainberg | dstanek, circular deps | 19:52 |
| bknudson | rpms can have circular dependencies | 19:52 |
| dstanek | morganfainberg: haha, really? that's not good | 19:52 |
| morganfainberg | how does pip deal with them? | 19:52 |
| dstanek | i've never tried circular deps with pip | 19:53 |
| morganfainberg | less worried about rpm, don't think it's an issue with .deb | 19:53 |
| *** leseb has quit IRC | 19:53 | |
| bknudson | https://mail.python.org/pipermail/distutils-sig/2012-November/019247.html | 19:54 |
| morganfainberg | bknudson, ok that doesn't help me understand if this would work as a circular dep | 20:05 |
| morganfainberg | bknudson, it.. sounds like it would, but.. i'm not 100% sure | 20:05 |
| *** marcoemorais has quit IRC | 20:07 | |
| *** marcoemorais has joined #openstack-keystone | 20:08 | |
| mfisch | I'm curious if anyone here monitors Keystone with Icinga | 20:15 |
| mfisch | We get seemingly random "requires authentication (401)" when trying to connect via the API | 20:15 |
| mfisch | about once every 2 hours | 20:15 |
| ayoung | morganfainberg, if I put a log warning about using a deprecated value in get_token_provider its going to spam the logs | 20:15 |
| ayoung | mfisch, token duration? Are you reusing a token? | 20:16 |
| mfisch | ayoung: token duration is one hour, but the Icinga script does a user/pass auth with the python API | 20:16 |
| mfisch | c = client.Client(username…) | 20:16 |
| mfisch | thats whats failing | 20:16 |
| ayoung | mfisch, no clue, then | 20:16 |
| mfisch | Hey at least we're on the same page | 20:16 |
| mfisch | I'll tell the monitoring guys they should be happy its not every time | 20:17 |
| mfisch | This is all the server says | 20:18 |
| mfisch | "keystone.common.wsgi [-] Authorization failed." | 20:18 |
| *** praneshp has quit IRC | 20:19 | |
| *** jdennis has quit IRC | 20:19 | |
| *** rushiagr has quit IRC | 20:19 | |
| *** marcoemorais has quit IRC | 20:19 | |
| *** harlowja has quit IRC | 20:19 | |
| *** mgagne has quit IRC | 20:19 | |
| *** dolphm has quit IRC | 20:19 | |
| *** mhu has quit IRC | 20:19 | |
| *** zigo has quit IRC | 20:19 | |
| *** zhiyan_ has quit IRC | 20:19 | |
| *** chmouel has quit IRC | 20:19 | |
| *** shufflebot has quit IRC | 20:19 | |
| *** uvirtbot has quit IRC | 20:19 | |
| *** marcoemorais has joined #openstack-keystone | 20:20 | |
| *** harlowja has joined #openstack-keystone | 20:20 | |
| *** praneshp has joined #openstack-keystone | 20:20 | |
| *** mgagne has joined #openstack-keystone | 20:20 | |
| *** jdennis has joined #openstack-keystone | 20:20 | |
| *** rushiagr has joined #openstack-keystone | 20:20 | |
| *** dolphm has joined #openstack-keystone | 20:20 | |
| *** uvirtbot has joined #openstack-keystone | 20:20 | |
| *** chmouel has joined #openstack-keystone | 20:20 | |
| *** shufflebot has joined #openstack-keystone | 20:20 | |
| *** zigo has joined #openstack-keystone | 20:20 | |
| *** zhiyan_ has joined #openstack-keystone | 20:20 | |
| *** mhu has joined #openstack-keystone | 20:20 | |
| *** dickson.freenode.net sets mode: +o dolphm | 20:20 | |
| *** hrybacki has joined #openstack-keystone | 20:20 | |
| ayoung | dolphm, 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-keystone | 20:22 | |
| dolphm | ayoung: so, i'm first concerned about existing things in the policy backend (people have used the API for stuff already) | 20:22 |
| dolphm | ayoung: but, yeah, i'm basically just thinking single blob | 20:23 |
| ayoung | dolphm, so we keep the existing code around which is "assign a new id when you upload" | 20:23 |
| ayoung | dolphm, OK, so what would happen with that single blob? Would it be assumbled from fragments? | 20:23 |
| ayoung | live in oslo? | 20:24 |
| mfisch | After corrlating the log files I have nothing but successful connections from the server side, perhaps python-keystoneclient is on crack | 20:24 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf https://review.openstack.org/95015 | 20:24 |
| *** nkinder_ has quit IRC | 20:24 | |
| *** chandan_kumar has quit IRC | 20:24 | |
| *** thedodd has quit IRC | 20:24 | |
| *** andreaf has quit IRC | 20:24 | |
| *** xianghui has quit IRC | 20:24 | |
| *** gmurphy has quit IRC | 20:24 | |
| dolphm | ayoung: well, projects still need to document their own default policy expectations, right? | 20:24 |
| dolphm | ayoung: so, what about a simple CLI tool to "compose one or more policy files together" | 20:25 |
| dolphm | ayoung: like, keystone-manage combine-policies glance.policy.json nova.policy.json keystone.policy.json > single.policy.json | 20:26 |
| ayoung | dolphm, that is fine, and it can just explode if there are conflicts | 20:26 |
| dolphm | ayoung: right | 20:26 |
| ayoung | dolphm, how are we going to fetch policy? | 20:26 |
| ayoung | say, nova starts up, and it does a GET 35357:v3/policy...what? | 20:27 |
| ayoung | filter it based on the token that nova passes? | 20:27 |
| *** dims_ has quit IRC | 20:28 | |
| ayoung | dolphm, I don't think we want to have to update the policy ID anywhere | 20:30 |
| *** dims_ has joined #openstack-keystone | 20:30 | |
| dolphm | ayoung: what if it just asked keystone for policies that applied to the current project context, and cached the result? | 20:31 |
| ayoung | dolphm, " current project context" definied how? based on a users request? | 20:31 |
| ayoung | it means we'll have a lot of queries | 20:31 |
| *** chandan_kumar has joined #openstack-keystone | 20:34 | |
| openstackgerrit | A change was merged to openstack/keystone: Add missing docstrings and 1 unittest for LDAP utf-8 fixes https://review.openstack.org/99646 | 20:34 |
| dolphm | ayoung: 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-keystone | 20:36 | |
| *** andreaf_ has joined #openstack-keystone | 20:36 | |
| dstanek | dolphm, 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-keystone | 20:36 | |
| *** thedodd has joined #openstack-keystone | 20:36 | |
| *** andreaf has joined #openstack-keystone | 20:36 | |
| *** 17SAADOYF has joined #openstack-keystone | 20:36 | |
| *** xianghui has joined #openstack-keystone | 20:36 | |
| *** 17SAADOYF has quit IRC | 20:36 | |
| *** andreaf has quit IRC | 20:36 | |
| dolphm | dstanek: well, "centralized policy management" is the foremost vision. but we've always stalled on how that should work | 20:37 |
| *** marcoemorais has quit IRC | 20:37 | |
| dolphm | dstanek: "how do i know which policy to ask for, or how do i ask for the right one?" | 20:37 |
| dstanek | dolphm: 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 files | 20:37 |
| dolphm | i think you can solve the "do i ask for the glance policy vs nova policy" by simply combining them into a single policy blob | 20:38 |
| *** marcoemorais has joined #openstack-keystone | 20:38 | |
| dolphm | dstanek: they use puppet/chef/etc | 20:38 |
| *** marcoemorais has quit IRC | 20:38 | |
| dstanek | dolphm: but are they managed by the same team typically or different? | 20:38 |
| *** marcoemorais has joined #openstack-keystone | 20:38 | |
| dolphm | so, the real use case here is when you complicate things with "this project should use a different policy file" | 20:38 |
| dolphm | etc | 20:38 |
| dolphm | which frankly i don't hear very often, but it has come up | 20:39 |
| dstanek | dolphm: is there a strong use case for that? seemed more like a "it would be cool if" | 20:40 |
| dolphm | dstanek: 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 themselves | 20:41 |
| dolphm | dstanek: but yes i agree - unless they speak up / demand first class support, i'd file it under "it would be cool if" | 20:41 |
| dolphm | it's also, possibly, an interesting alternative to the project-own-services-which-own-roles mess | 20:43 |
| *** devlaps has joined #openstack-keystone | 20:46 | |
| *** hrybacki has quit IRC | 20:51 | |
| openstackgerrit | Ryan Bak proposed a change to openstack/keystone: LDAP: Added documentation for debug_level option https://review.openstack.org/94679 | 20:55 |
| *** leseb has joined #openstack-keystone | 20:59 | |
| *** juanmo1 has quit IRC | 20:59 | |
| *** hrybacki has joined #openstack-keystone | 21:00 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/99076 | 21:00 |
| *** radez is now known as radez_g0n3 | 21:02 | |
| *** nkinder_ has quit IRC | 21:03 | |
| *** hrybacki has quit IRC | 21:03 | |
| *** leseb has quit IRC | 21:04 | |
| *** gyee has joined #openstack-keystone | 21:04 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/96265 | 21:05 |
| *** nkinder_ has joined #openstack-keystone | 21:07 | |
| *** amerine has quit IRC | 21:07 | |
| *** amerine has joined #openstack-keystone | 21:09 | |
| *** marcoemorais has quit IRC | 21:12 | |
| *** marcoemorais has joined #openstack-keystone | 21:12 | |
| *** marcoemorais has quit IRC | 21:13 | |
| *** marcoemorais has joined #openstack-keystone | 21:13 | |
| *** andreaf has joined #openstack-keystone | 21:16 | |
| dtroyer_zz | dolphm, 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 today | 21:17 |
| *** nkinder_ has quit IRC | 21:18 | |
| ayoung | bknudson, 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_id | 21:22 |
| *** dstanek is now known as dstanek_zzz | 21:22 | |
| *** einarf has quit IRC | 21:24 | |
| bknudson | ayoung: there's been some discussion on the mailing list of how to hide token_id, so that all projects do it the same way | 21:24 |
| ayoung | bknudson, so, lets not "hide" id | 21:25 |
| bknudson | seems like the discussion should be there since it's not just keystone that's affected | 21:25 |
| ayoung | lets provide a first class attribute for audit | 21:25 |
| ayoung | bknudson, I know, but I want the keystone team to chime in first | 21:25 |
| bknudson | ayoung: I think there was some work going on about a cross-project request ID | 21:25 |
| bknudson | is that what you're thinking about? | 21:26 |
| ayoung | bknudson, I thought that was related but different, but I see how it could be the same thing. | 21:26 |
| ayoung | Maybe. | 21:26 |
| bknudson | I've thought that's something we should have | 21:27 |
| ayoung | it 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 requests | 21:27 |
| bknudson | at least have some way to connect the client's request with what's logged in the server log | 21:27 |
| ayoung | but I think the sha1 approach is going to cause you pain | 21:27 |
| ayoung | bknudson, just like you had to remove MD5, you are going to have to remove SHA1 | 21:27 |
| ayoung | even though there is no security implication | 21:27 |
| ayoung | its compliance | 21:27 |
| bknudson | yes, the requirement is essentially don't use something < sha2 | 21:28 |
| *** jsavak has quit IRC | 21:28 | |
| ayoung | bknudson, so can you -2 that approach. I'll be happy to dogpile on top of it | 21:28 |
| bknudson | it's ok as long as it's configurable | 21:29 |
| bknudson | and making it configurable can be a separate patch | 21:29 |
| jamielennox | bknudson: let's not make a logging option like that configurable | 21:29 |
| ayoung | bknudson, nope | 21:29 |
| ayoung | it is not configurable | 21:29 |
| bknudson | y, it's pretty ridiculous | 21:29 |
| ayoung | bknudson, does the tracking ID make sense? | 21:30 |
| bknudson | ayoung: I haven't seen what it actually is | 21:30 |
| ayoung | bknudson, add an attribute to the token body | 21:30 |
| ayoung | tracking_id | 21:30 |
| ayoung | its a uuid | 21:31 |
| ayoung | and it is used in audit logs | 21:31 |
| jamielennox | ayoung: so that becomes really horrible from an auth_plugin aspect | 21:31 |
| ayoung | jamielennox, nope | 21:31 |
| *** andreaf has quit IRC | 21:31 | |
| jamielennox | that's not a reason not to have it - just a pain | 21:31 |
| jamielennox | client side auth plugin | 21:31 |
| ayoung | jamielennox, auth_plugin can unpack the token to get it, but they alsio get it in the request to get a token in the first place | 21:31 |
| ayoung | the body of the token is in the token request | 21:32 |
| ayoung | response | 21:32 |
| ayoung | authenticate response | 21:32 |
| bknudson | a lot of these tokens are logged by the clients | 21:32 |
| bknudson | which don't have the token body | 21:32 |
| bknudson | e.g., nova calls glanceclient with a token | 21:32 |
| jamielennox | so auth_plugins have a get_token method, we would need to add a get_token_tracker_id() as well i guess | 21:33 |
| *** nkinder_ has joined #openstack-keystone | 21:33 | |
| bknudson | I always thought we should use part of the token | 21:34 |
| bknudson | since that's what I do when looking for tokens in logs anyways | 21:34 |
| jamielennox | bknudson: yea, but we cant has it, we cant make it public... | 21:34 |
| bknudson | we cant has cheezburger? | 21:35 |
| jamielennox | not agreeing with ayoung necessarily about a tracking id | 21:35 |
| jamielennox | s/has/hash | 21:36 |
| bknudson | yea, that's a goofy one because you could potentially use the same hash algorithm | 21:36 |
| bknudson | so logging the hash could potentially be the same as logging the token | 21:37 |
| jamielennox | yep, morganfainberg and i were debating this the other day | 21:37 |
| *** dims has joined #openstack-keystone | 21:37 | |
| jamielennox | he was salting it but that appears to have disapeared | 21:39 |
| *** dims_ has quit IRC | 21:39 | |
| bknudson | it really seems like the tracking ID is a really heavyweight solution to what seems like it should be pretty trivial | 21:39 |
| jamielennox | ++ | 21:39 |
| bknudson | although we seem to have gotten a requirement that it has to be so obvious that no documentation is required | 21:39 |
| bknudson | and it also needs to be a hash | 21:40 |
| *** nsquare has quit IRC | 21:44 | |
| *** nsquare has joined #openstack-keystone | 21:46 | |
| *** morganfainberg has quit IRC | 21:50 | |
| *** morganfainberg has joined #openstack-keystone | 21:50 | |
| *** marcoemorais has quit IRC | 22:05 | |
| *** marcoemorais has joined #openstack-keystone | 22:06 | |
| ayoung | tracking 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|away | 22:12 | |
| *** jamielennox|away is now known as jamielennox | 22:26 | |
| *** henrynash has quit IRC | 22:32 | |
| *** thedodd has quit IRC | 22:38 | |
| *** amerine has quit IRC | 22:41 | |
| *** nsquare has quit IRC | 22:44 | |
| *** amerine has joined #openstack-keystone | 22:44 | |
| *** nsquare has joined #openstack-keystone | 22:45 | |
| jamielennox | ok, so keystoneclient review for people: https://review.openstack.org/#/c/95015/ | 22:48 |
| gyee | jamielennox, do you have a patch that does version discovery and load auth plugin in session based on input? | 22:56 |
| *** nikunj2512 has quit IRC | 22:58 | |
| *** gordc has quit IRC | 23:04 | |
| jamielennox | input? | 23:08 |
| jamielennox | gyee: &^ | 23:08 |
| jamielennox | i think i have most of those components in review | 23:08 |
| jamielennox | i don't know about the whole thing together | 23:08 |
| *** gokrokve has quit IRC | 23:09 | |
| gyee | jamielennox, sorry, was reviewing your code | 23:13 |
| gyee | just a couple of minor suggestions | 23:13 |
| jamielennox | gyee: then take all the time you need | 23:13 |
| gyee | jamielennox, https://review.openstack.org/#/c/96323/16/ceilometerclient/client.py | 23:14 |
| gyee | the bug is reference here | 23:14 |
| gyee | basically, for keystoneclient integration, we still need to do quite a bit of boilerplate stuff | 23:14 |
| gyee | like version discovery, determining the correct auth plugin to use based on user input, etc | 23:15 |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: JSON Home https://review.openstack.org/97359 | 23:15 |
| gyee | would be nice if we can encapsulate all that in a utility method provided by keystoneclient | 23:15 |
| gyee | I thought you were working on a patch | 23:15 |
| jamielennox | replied | 23:15 |
| gyee | if not, I can work on it | 23:15 |
| jamielennox | wow | 23:16 |
| jamielennox | wtf | 23:16 |
| jamielennox | good to see people contributing here :0 | 23:16 |
| *** nkinder_ has quit IRC | 23:16 | |
| gyee | well, I recruited a few amigos to help out :) | 23:16 |
| gyee | ok, maybe recruit is not the right word here | 23:17 |
| jamielennox | ok, so part of this is the Adapter you just looked at | 23:17 |
| jamielennox | ah - did you just look at | 23:17 |
| jamielennox | lol, another client review for people: https://review.openstack.org/#/c/86237/ | 23:18 |
| gyee | wait, Adapter does version discovery and all that? | 23:18 |
| *** amerine has quit IRC | 23:18 | |
| jamielennox | this is the core that i think most clients need | 23:18 |
| openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Catch AttributeError if no service catalog https://review.openstack.org/100714 | 23:18 |
| ayoung | jamielennox, there ya go^^ | 23:18 |
| jamielennox | no, it doesn't create the session for people | 23:18 |
| gyee | jamielennox, yeah, we need one that does all that boilerplate stuff | 23:18 |
| jamielennox | ayoung: return self.auth_ref and self.auth_ref.has_service_catalog() | 23:19 |
| ayoung | jamielennox, tomato tomaaahto | 23:19 |
| ayoung | jamielennox, it was that self.auth_ref did have the attribute | 23:20 |
| jamielennox | i 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 review | 23:20 |
| jamielennox | no auth_ref was None | 23:20 |
| ayoung | really? | 23:20 |
| jamielennox | gyee: so who is creating the session | 23:20 |
| jamielennox | ayoung: from memory | 23:20 |
| ayoung | jamielennox, this catches it either way | 23:20 |
| gyee | jamielennox, all the client CLI does | 23:20 |
| jamielennox | ayoung: auth_ref should always be an AccessInfo if set | 23:20 |
| *** amerine has joined #openstack-keystone | 23:20 | |
| ayoung | meh | 23:21 |
| jamielennox | gyee: https://review.openstack.org/#/c/95678/ | 23:21 |
| ayoung | jamielennox, are you really going to make us change all of the config files for auth_token just to match heat? | 23:21 |
| jamielennox | gyee: it's the v2/v3 auth plugin that's a problem | 23:21 |
| jamielennox | ayoung: that was the decision | 23:21 |
| jamielennox | probably people don't care | 23:22 |
| jamielennox | check stevebaker and sdague on -dev | 23:22 |
| gyee | jamielennox, here's the problem, clients got a bunch of command line args, auth_url, user_id, username, tenant_id, etc | 23:22 |
| jamielennox | convince them and i'm good - i honestly don't care i just want them standard and to push this review along | 23:22 |
| ayoung | jamielennox, yeah, that ain't gonna fly | 23:22 |
| ayoung | breaking every config everywhere == bad | 23:22 |
| jamielennox | ayoung: it'll still be deprecated | 23:23 |
| gyee | they 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 object | 23:23 |
| ayoung | jamielennox, deprecated == "must eventualyl change with not good reason" | 23:23 |
| * ayoung looking for mailing list discussion | 23:23 | |
| jamielennox | gyee: 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 above | 23:24 |
| gyee | ayoung, deprecated = "we are going to quietly pull the rug under you" :) | 23:24 |
| ayoung | gyee, you agree with me on this, right? | 23:24 |
| jamielennox | ayoung: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object | 23:24 |
| ayoung | thanks | 23:24 |
| jamielennox | i probably should have put keystone on there - i was thinking it mostly unaffected | 23:25 |
| jamielennox | it 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 way | 23:27 |
| gyee | jamielennox, where did you undeprecate the construct method? https://review.openstack.org/#/c/74599/7 | 23:27 |
| jamielennox | gyee: oh, must be somewhere else - sorry | 23:28 |
| jamielennox | ummm | 23:28 |
| jamielennox | gyee: i don't know - i can't keep all my reviews straight any more | 23:29 |
| jamielennox | i agree it needs to come out | 23:29 |
| gyee | k, I'll +2 it | 23:29 |
| gyee | easy fix anyway | 23:29 |
| jamielennox | is that Adapter or from_conf? | 23:30 |
| gyee | jamielennox, ah, you forgot DocImpact | 23:30 |
| gyee | all those needs to be doc | 23:30 |
| gyee | jamielennox, if you can drop a TODO there for the auth_token change would be awesome | 23:30 |
| jamielennox | gyee: so the from_conf i almost thing ayoung is right - we shouldn't change all those CONFs to match heat | 23:32 |
| ayoung | "almost" coming from you is high praise! | 23:32 |
| gyee | but you have the deprecated param there right? | 23:32 |
| gyee | we need to unify all these options anyway | 23:33 |
| jamielennox | heh - yea, i can provide the deprecation - but we are talking about the default value throughout everywhere | 23:33 |
| jamielennox | so it would mean transitioning auth_token in all CONF files from cafile -> ca_file and etc | 23:33 |
| gyee | can't imagine we have to deal with cacert, cafile, ca-certfile | 23:33 |
| jamielennox | i think it's probably better to enforce a lot of pain on one group (heat) than a little bit on everyone | 23:34 |
| gyee | I think its worth the effort | 23:34 |
| jamielennox | which one? | 23:35 |
| gyee | unifying the config options across all openstack | 23:36 |
| gyee | same way as common cli | 23:36 |
| jamielennox | gyee: absolutely the choice is though to change auth_token or change heat | 23:36 |
| ayoung | jamielennox, auth_token means changing puppet | 23:37 |
| ayoung | and devstack | 23:37 |
| gyee | lets have a vote :) | 23:37 |
| ayoung | and chef | 23:37 |
| ayoung | and every deployment out there | 23:37 |
| gyee | do it the democratic way | 23:37 |
| ayoung | gyee, no | 23:37 |
| jamielennox | gyee: the tree of us? | 23:37 |
| ayoung | we just do it | 23:37 |
| gyee | whahhh? | 23:37 |
| ayoung | just write it up and post the rationale | 23:37 |
| ayoung | deprecate the Heat options or support both | 23:38 |
| jamielennox | gyee: which way are you going to vote? | 23:38 |
| gyee | auth_token of course | 23:38 |
| jamielennox | change auth_token or keep auth_token | 23:38 |
| gyee | keep the auth_token naming convention I mean | 23:38 |
| jamielennox | ok, that's 100% of my sample | 23:38 |
| jamielennox | let me change that back | 23:39 |
| gyee | great minds think alike | 23:39 |
| gyee | sorry ayoung | 23:39 |
| ayoung | gyee, what are you sorry for | 23:40 |
| gyee | ayoung, nm, I was going to pull a great minds think alike joke | 23:41 |
| *** gokrokve has joined #openstack-keystone | 23:43 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf https://review.openstack.org/95015 | 23:46 |
| jamielennox | ayoung, gyee: ^ looks like auth_token | 23:46 |
| *** devlaps has quit IRC | 23:47 | |
| ayoung | jamielennox, why does it show: Depedns on Changes exception raised by v3.trusts.update() (MERGED) | 23:47 |
| gyee | looking | 23:47 |
| jamielennox | ayoung: no idea | 23:48 |
| ayoung | jamielennox, is there a "rebase" button on your ui? | 23:48 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf https://review.openstack.org/95015 | 23:49 |
| ayoung | that's why | 23:49 |
| jamielennox | ayoung: did it in terminal - must have forgotten | 23:49 |
| ayoung | looks good | 23:49 |
| ayoung | jamielennox, 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, though | 23:50 |
| ayoung | DRY | 23:50 |
| gyee | jaimelennox, s/timeout/http_connection_timeout/ | 23:50 |
| gyee | jamielennox, https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L234 | 23:50 |
| *** diegows has quit IRC | 23:51 | |
| morganfainberg | ayoung, 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 |
| ayoung | morganfainberg, I confirmed with bknudson that it was | 23:52 |
| ayoung | it wasn't just "md5" but "all hashing < sha2" | 23:52 |
| morganfainberg | ayoung, then we should also disable any hashing algorithms that aren't compliant | 23:52 |
| gyee | wtf? sha1 has compliance issue? | 23:52 |
| morganfainberg | ayoung, unreleated | 23:52 |
| jamielennox | morganfainberg: i've heard suggestions of tjat | 23:53 |
| gyee | which industry? :) | 23:53 |
| gyee | HIPPA | 23:53 |
| ayoung | morganfainberg, nah, we just should not hard code to use any specific hashing algorithms for a specific purpose, so we can always move forward | 23:53 |
| gyee | SUCKS | 23:53 |
| morganfainberg | ayoung, well we need some solution. | 23:53 |
| gyee | sorry, I mean SOX | 23:53 |
| bknudson | it's a FIPS / NIST requirement | 23:53 |
| ayoung | morganfainberg, put a tracking_id in the token | 23:53 |
| morganfainberg | ayoung, sure. | 23:54 |
| ayoung | morganfainberg, drop the token_id from it | 23:54 |
| morganfainberg | ayoung, please remove the -2 i'll wIP it. rather keep the changeid | 23:54 |
| ayoung | wilco | 23:54 |
| bknudson | the keystone server can now be configured to use a conforming hash algorithm so it's ok now | 23:54 |
| morganfainberg | or i'll -2 till we're good. | 23:54 |
| morganfainberg | ayoung, ok i hit the -2 and WIP will update tonight or tomorrow with a plain tracking id or some sort | 23:55 |
| jamielennox | morganfainberg: i was waiting for that one to pass before i did the password logging one | 23:55 |
| gyee | morganfainberg, just salt that sucker | 23:55 |
| jamielennox | i might get in first with a conflict if yours is going to be an issue | 23:55 |
| ayoung | morganfainberg, cool. And we make that part of the official audit story, too. | 23:56 |
| morganfainberg | ayoung, sure, works for me | 23:56 |
| gyee | generate a random salt and use it for the hash | 23:56 |
| gyee | result = <salt><hash> | 23:56 |
| ayoung | gyee, 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 finish | 23:56 |
| ayoung | no need | 23:57 |
| jamielennox | hash.update('jamielennox :)') # NOTE(jamielennox): IMMORTALITY !! | 23:57 |
| gyee | heh | 23:57 |
| morganfainberg | ayoung, yep works for me. and yeah no hashing. | 23:57 |
| gyee | s/salt/marinate/ | 23:57 |
| morganfainberg | gyee, hah | 23:58 |
| morganfainberg | gyee, dry rub? | 23:58 |
| ayoung | ok...what was I working on? | 23:58 |
| morganfainberg | ayoung, not sure ;) | 23:58 |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: JSON Home https://review.openstack.org/97359 | 23:58 |
| ayoung | https://review.openstack.org/#/c/98897/ PKIZ | 23:58 |
| morganfainberg | ayoung, ++ | 23:59 |
| ayoung | morganfainberg, gyee so I removed def test_token_format_provider_mismatch(self) | 23:59 |
| jamielennox | gyee 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!
