*** harlowja has quit IRC | 00:00 | |
*** daneyon has quit IRC | 00:02 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session Adapters https://review.openstack.org/86237 | 00:03 |
---|---|---|
dstanek | jamielennox: howdy | 00:04 |
jamielennox | dstanek: you can't do anything quietly with those notifications | 00:04 |
dstanek | jamielennox: ? | 00:04 |
jamielennox | dstanek: nothing - what's up? | 00:05 |
dstanek | jamielennox: :-) just wanted to let you know that i'm making a few changes to https://review.openstack.org/#/c/101792/ | 00:05 |
jamielennox | dstanek: sure, it wasn't ready to merge, it needs at least a close bug and some tests, i was just seeing if the direction was ok | 00:06 |
dstanek | jamielennox: i added some tests and comments on _redact - haven't done much more than that | 00:06 |
jamielennox | dstanek: thanks - yea, i think bknudson is probably right that the individual plugins should be managing what they log like i do in v3 rather that doing _redact | 00:09 |
morganfainberg_L | jamielennox: middleware! Yay! | 00:10 |
jamielennox | morganfainberg_L: nice | 00:11 |
jamielennox | when do we promote it as ready? | 00:11 |
jamielennox | i've been trying to think about what i want to change compatibility wise | 00:11 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Unversioned endpoints in service catalog https://review.openstack.org/74599 | 00:12 |
jamielennox | and one of the important ones is that you shouldn't be allowed to specify both a username/password and and admin_token and have the fallback behaviour | 00:12 |
jamielennox | yes! ^ | 00:12 |
morganfainberg | jamielennox, well we have some gate work to do before we release | 00:13 |
morganfainberg | jamielennox, but ASAP we should release | 00:13 |
jamielennox | morganfainberg: i would like to get the whole auth plugin from config file thing to be used by the new plugin | 00:13 |
morganfainberg_L | jamielennox: so.. | 00:13 |
jamielennox | new middleware | 00:13 |
morganfainberg_L | we discussed this today | 00:13 |
jamielennox | it shouldn't be backwards incompatible though | 00:13 |
jamielennox | damnit - the one meeting i miss... | 00:13 |
morganfainberg_L | how ... awful would it be to split session and cms out? | 00:13 |
morganfainberg_L | bascially keystonelib becomes the common lib things | 00:14 |
jamielennox | morganfainberg_L: it would be great - i don't think they belong in the same repo though | 00:14 |
morganfainberg_L | and ksc really is the _client_ | 00:14 |
dstanek | jamielennox: ah, then i won't push this change | 00:14 |
jamielennox | dstanek: no, you should push it - i haven't attempted anything in that regard | 00:14 |
jamielennox | session is very common to everyone, same as the base auth plugin classes | 00:15 |
dstanek | jamielennox: if _redacted goes away the change is useless, but i can push anyway | 00:15 |
morganfainberg_L | jamielennox: so you don't think CMS and session should be in a common lib repo? | 00:15 |
jamielennox | dstanek: i'm happy to leave redacted - it just came up in a comment | 00:15 |
jamielennox | morganfainberg_L: what's common about CMS that is needed beyond ksc? | 00:15 |
morganfainberg_L | keystone, and middleware both need it | 00:16 |
morganfainberg_L | and anyone looking to validate a token might want it | 00:16 |
morganfainberg_L | e.g. session | 00:16 |
*** bknudson has joined #openstack-keystone | 00:17 | |
jamielennox | session shouldn't, middleware should rely on ksc right? | 00:17 |
jamielennox | although - i can see why it might | 00:17 |
morganfainberg_L | well my thought was middleware ends up relying on [common] | 00:17 |
jamielennox | i haven't needed that yet | 00:17 |
morganfainberg_L | [ksc] relies on common | 00:17 |
morganfainberg_L | [keystone] relies on common | 00:17 |
morganfainberg_L | [*client] relies on common | 00:18 |
jamielennox | morganfainberg_L: i'd really like to move a lot of middleware into ksc | 00:18 |
*** marcoemorais has quit IRC | 00:18 | |
jamielennox | the whole what is this token should be in ksc | 00:18 |
jamielennox | because it *is* a keystone concern | 00:18 |
*** marcoemorais has joined #openstack-keystone | 00:18 | |
morganfainberg_L | so KSC is _just_ the client bits, common would be the other parts we share among middleware, keystone, other clients | 00:18 |
morganfainberg_L | *shurg* | 00:19 |
*** ncoghlan has joined #openstack-keystone | 00:19 | |
morganfainberg_L | not sure if it is worth the effort at the moment to split things further. as it stands middleware will rely/doesrely on ksc | 00:19 |
*** marcoemorais has quit IRC | 00:19 | |
jamielennox | morganfainberg_L: so you are talking about keystonecommon then? | 00:19 |
*** marcoemorais has joined #openstack-keystone | 00:19 | |
*** daneyon has joined #openstack-keystone | 00:20 | |
jamielennox | because i'm considering session like a clientcommon | 00:20 |
morganfainberg_L | yeah we discussed if it made sense tosplit out all the keystone common stuff (well in this case client common) into it's own project | 00:20 |
jamielennox | so session belongs to clientcommon because it's relevant to everyone, if we need keystonecommon to make the middleware split work then that's ok | 00:21 |
morganfainberg_L | only thing there would be cms | 00:21 |
jamielennox | but i don't think that CMS belongs to a clientcommon | 00:21 |
morganfainberg_L | and we don't _need_ to split cms out | 00:21 |
morganfainberg_L | but if cms was split, we could avoid the need to "freeze" the middleware in ksc, just make there be a dependency for the transition period and import (like we do with keystone) | 00:22 |
morganfainberg_L | especially if session is in a separate project as well | 00:22 |
jamielennox | morganfainberg_L: i want to avoid the relationship that session is a keystone thing | 00:23 |
jamielennox | the identity plugins are and they could potentially be keystonecommon rather than keystoneclient | 00:23 |
jamielennox | morganfainberg_L: also i made the doc change you wanted to https://review.openstack.org/#/c/86237/ if you can have anothre quick look | 00:24 |
morganfainberg_L | jamielennox: ++ | 00:24 |
*** bknudson has left #openstack-keystone | 00:25 | |
*** praneshp has quit IRC | 00:25 | |
* jamielennox is going to make people look at/approve client patches | 00:25 | |
morganfainberg_L | jamielennox: well if you want help splitting things from the repo, let me know. I've got a good handle on what it takes | 00:25 |
jamielennox | morganfainberg_L: so i haven't been too worried about it yet, i've been working on the assumption that everyone already should have a keystoneclient dependancy | 00:26 |
morganfainberg_L | right | 00:26 |
jamielennox | especially given that the CLIs are all part of the client repos | 00:26 |
jamielennox | also i'm still doing a lot of changes to it | 00:26 |
jamielennox | but yea, i'm up to split it out whenever it makes sense | 00:26 |
morganfainberg_L | jamielennox: you tell me, and we can write it up. it'd take me a day to split things up inc. the proposals to infra/devstack etc now | 00:27 |
jamielennox | man the apiclient oslo guys are going to hate this :) | 00:28 |
morganfainberg_L | LOL | 00:28 |
morganfainberg_L | would session go under oslo then? or would you keep it under identity? | 00:29 |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Add invalidate doc string to identity plugin https://review.openstack.org/99558 | 00:30 |
jamielennox | god no for oslo | 00:30 |
jamielennox | session is common for everyone | 00:30 |
morganfainberg_L | i meant make it oslo.session out the gate | 00:30 |
morganfainberg_L | not incubator | 00:30 |
jamielennox | it's not an identity concept, there is a base plugin class that will work for any authentication type which is common for everyone | 00:30 |
morganfainberg_L | or you mean it's something that is more widely usable in the python community | 00:30 |
jamielennox | then there are identity plugins that live within the identity space | 00:31 |
jamielennox | umm, i don't think it's useful for wider python | 00:31 |
jamielennox | it's fairly specific to how openstack does things like catalog lookups | 00:31 |
morganfainberg_L | well in either case let me know | 00:31 |
*** lbragstad has quit IRC | 00:31 | |
morganfainberg_L | i'm totally happy to help split it out for you. | 00:32 |
jamielennox | yea, it's probably an oslo concept | 00:33 |
morganfainberg_L | +2 on adapter | 00:33 |
jamielennox | excellent | 00:34 |
*** bknudson has joined #openstack-keystone | 00:34 | |
jamielennox | thanks for the review of the CONF stuff as well | 00:35 |
morganfainberg_L | jamielennox: so for session, lets get any other crazy review stuff / restructuring etc in before we split, otherwise it becomes morework to merge- update in project X, wait for release, update to use in Y, etc | 00:36 |
jamielennox | morganfainberg_L: session shouldn't be too hard i think because you would still have keystoneclient relying on the oslo.clientcommon | 00:36 |
jamielennox | so you would just provide the class links | 00:37 |
morganfainberg_L | right. but still need to do releases for updates | 00:37 |
morganfainberg_L | so, lets get conf stuff in, adapters and anything else in flight | 00:37 |
morganfainberg_L | then look at splitting | 00:37 |
morganfainberg_L | ? | 00:37 |
jamielennox | morganfainberg_L: sounds good | 00:37 |
jamielennox | i'm hoping to push that quickly | 00:38 |
morganfainberg_L | say, target start of J3 for the split if we're going to do it | 00:38 |
morganfainberg_L | e.g. make the call then | 00:38 |
morganfainberg_L | so packagers have time to roll everything up nicely | 00:38 |
jamielennox | so this is the route to v3 everywhere and i want that for J so i want to have this stuff in a released client by then | 00:38 |
jamielennox | so that should be good | 00:38 |
morganfainberg_L | ugh we need to get specs updated/approved | 00:39 |
morganfainberg_L | this is going to be an empty keystone release if we don't | 00:40 |
* morganfainberg_L goes and gets dinner | 00:41 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystonemiddleware: auth_token cached token handling https://review.openstack.org/102399 | 00:42 |
jamielennox | morganfainberg_L: i've got like one patch into keystone since the summit i think | 00:42 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystonemiddleware: Refactor auth_token, move identity server members to class https://review.openstack.org/102402 | 00:48 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystonemiddleware: Refactor auth_token revocation list members to new class https://review.openstack.org/102403 | 00:48 |
*** dstanek is now known as dstanek_zzz | 00:48 | |
*** daneyon has quit IRC | 00:49 | |
*** morganfainberg is now known as morganfainberg_Z | 00:57 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: V3 extension advertisement https://review.openstack.org/95973 | 00:57 |
*** dstanek_zzz is now known as dstanek | 01:04 | |
*** praneshp has joined #openstack-keystone | 01:18 | |
*** diegows has quit IRC | 01:22 | |
*** mrda has joined #openstack-keystone | 01:24 | |
*** lbragstad has joined #openstack-keystone | 01:25 | |
*** harlowja_ has quit IRC | 01:28 | |
*** oomichi has quit IRC | 01:29 | |
*** marcoemorais has quit IRC | 01:30 | |
*** praneshp_ has joined #openstack-keystone | 01:32 | |
*** harlowja has joined #openstack-keystone | 01:32 | |
*** oomichi has joined #openstack-keystone | 01:33 | |
*** amcrn_ has quit IRC | 01:33 | |
*** dstanek is now known as dstanek_zzz | 01:34 | |
*** praneshp has quit IRC | 01:35 | |
*** praneshp_ is now known as praneshp | 01:35 | |
*** topol has joined #openstack-keystone | 01:37 | |
*** lbragstad has left #openstack-keystone | 01:37 | |
*** mberlin1 has quit IRC | 01:41 | |
*** mberlin has joined #openstack-keystone | 01:41 | |
*** praneshp has quit IRC | 01:43 | |
jamielennox | does anyone know how to test things in oslo.config like deperecated opts where it's not the main option name | 01:44 |
jamielennox | it means it will work if you load something from a config file but you can't use the stub out methods | 01:45 |
*** lbragstad has joined #openstack-keystone | 01:46 | |
bknudson | jamielennox: How about checking if the option has the deprecated name as expected? | 01:50 |
bknudson | don't need to test if the deprecated value works | 01:50 |
jamielennox | yea, that's what i'm looking at now - it seems a little trivial was al | 01:50 |
bknudson | since we can assume that oslo.config is tested to handle it correctly | 01:50 |
bknudson | https://review.openstack.org/#/c/101712/ please? | 01:53 |
jamielennox | bknudson: done | 01:54 |
bknudson | jamielennox: Thanks! | 01:54 |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf https://review.openstack.org/95015 | 02:05 |
*** morganfainberg_Z is now known as morganfainberg | 02:06 | |
*** jamielennox is now known as jamielennox|away | 02:22 | |
openstackgerrit | Justin Shepherd proposed a change to openstack/keystone: Adding an index on token.user_id https://review.openstack.org/102041 | 02:26 |
*** dstanek_zzz is now known as dstanek | 02:26 | |
*** dims__ has quit IRC | 02:28 | |
*** nsquare has quit IRC | 02:30 | |
*** openstackgerrit has quit IRC | 02:31 | |
*** mitz_ has joined #openstack-keystone | 02:36 | |
*** Camisa has joined #openstack-keystone | 02:37 | |
*** Camisa has joined #openstack-keystone | 02:37 | |
*** tristanC has joined #openstack-keystone | 02:45 | |
*** fifieldt_ is now known as fifieldt | 02:47 | |
*** dims__ has joined #openstack-keystone | 02:54 | |
*** gokrokve has joined #openstack-keystone | 02:54 | |
*** hrybacki_ has quit IRC | 02:55 | |
*** gokrokve_ has joined #openstack-keystone | 02:56 | |
*** richm has left #openstack-keystone | 02:57 | |
*** dims__ has quit IRC | 02:58 | |
*** gokrokve has quit IRC | 02:59 | |
morganfainberg | bknudson, does LDAP not support OS-INHERIT for group roles? | 03:03 |
morganfainberg | bknudson or... group roles at all? | 03:03 |
*** praneshp has joined #openstack-keystone | 03:04 | |
*** harlowja is now known as harlowja_away | 03:04 | |
morganfainberg | bknudson trying to bring back https://review.openstack.org/#/c/86025/6/keystone/assignment/backends/ldap.py from abandonment... but ... *blink* wtf. that looks like it doesn't come close to matching the other logic | 03:04 |
morganfainberg | ah nvm figured it out | 03:28 |
morganfainberg | ugh | 03:32 |
morganfainberg | WTF. | 03:32 |
*** dstanek is now known as dstanek_zzz | 03:32 | |
*** zhiyan_ is now known as zhiyan | 03:49 | |
*** dims__ has joined #openstack-keystone | 03:55 | |
*** dims__ has quit IRC | 03:59 | |
* morganfainberg pokes openstackgerrit | 03:59 | |
morganfainberg | awww. bot is gone. | 03:59 |
*** topol has quit IRC | 04:21 | |
*** dstanek_zzz is now known as dstanek | 04:25 | |
*** dstanek is now known as dstanek_zzz | 04:35 | |
*** gokrokve_ has quit IRC | 04:39 | |
*** gokrokve_ has joined #openstack-keystone | 04:43 | |
*** lbragstad has quit IRC | 04:45 | |
*** dims__ has joined #openstack-keystone | 04:56 | |
*** dstanek_zzz is now known as dstanek | 04:56 | |
*** ukalifon has joined #openstack-keystone | 04:57 | |
*** ajc_ has joined #openstack-keystone | 04:59 | |
*** dims__ has quit IRC | 05:00 | |
*** gyee has quit IRC | 05:02 | |
*** gokrokve_ has quit IRC | 05:02 | |
*** dstanek is now known as dstanek_zzz | 05:06 | |
*** ncoghlan is now known as ncoghlan_afk | 05:12 | |
*** morganfainberg is now known as morganfainberg_Z | 05:14 | |
*** rwsu has quit IRC | 05:24 | |
*** nsquare has joined #openstack-keystone | 05:26 | |
*** ncoghlan_afk is now known as ncoghlan | 05:37 | |
*** praneshp_ has joined #openstack-keystone | 05:47 | |
*** praneshp has quit IRC | 05:49 | |
*** praneshp_ is now known as praneshp | 05:49 | |
*** dims__ has joined #openstack-keystone | 05:56 | |
*** dstanek_zzz is now known as dstanek | 05:57 | |
*** gokrokve has joined #openstack-keystone | 05:59 | |
*** chandan_kumar has quit IRC | 06:00 | |
*** dims__ has quit IRC | 06:01 | |
*** gokrokve has quit IRC | 06:04 | |
*** dstanek is now known as dstanek_zzz | 06:07 | |
*** afazekas_ has joined #openstack-keystone | 06:13 | |
*** nsquare has quit IRC | 06:28 | |
*** nsquare has joined #openstack-keystone | 06:30 | |
*** nsquare has quit IRC | 06:31 | |
*** jaosorior has joined #openstack-keystone | 06:33 | |
*** nsquare has joined #openstack-keystone | 06:37 | |
*** stevemar has quit IRC | 06:45 | |
*** dims__ has joined #openstack-keystone | 06:57 | |
*** dstanek_zzz is now known as dstanek | 06:57 | |
*** gokrokve has joined #openstack-keystone | 07:00 | |
*** praneshp has quit IRC | 07:01 | |
*** dims__ has quit IRC | 07:04 | |
*** gokrokve has quit IRC | 07:04 | |
*** tomoiaga has joined #openstack-keystone | 07:07 | |
*** dstanek is now known as dstanek_zzz | 07:07 | |
*** BAKfr has joined #openstack-keystone | 07:11 | |
*** marekd|away is now known as marekd | 07:16 | |
marekd | morning. | 07:16 |
*** nsquare has quit IRC | 07:16 | |
jaosorior | morning | 07:28 |
*** dstanek_zzz is now known as dstanek | 07:58 | |
*** gokrokve has joined #openstack-keystone | 08:00 | |
*** mrda is now known as mrda-away | 08:02 | |
*** gokrokve has quit IRC | 08:06 | |
*** dstanek is now known as dstanek_zzz | 08:08 | |
*** Ju_ has quit IRC | 08:34 | |
*** andreaf has joined #openstack-keystone | 08:39 | |
*** ncoghlan has quit IRC | 08:42 | |
tziOm | the | 08:50 |
*** openstackgerrit has joined #openstack-keystone | 08:53 | |
*** dstanek_zzz is now known as dstanek | 08:59 | |
*** gokrokve has joined #openstack-keystone | 09:01 | |
*** dims has joined #openstack-keystone | 09:02 | |
*** gokrokve has quit IRC | 09:06 | |
*** dims has quit IRC | 09:08 | |
*** dstanek is now known as dstanek_zzz | 09:09 | |
*** i159 has joined #openstack-keystone | 09:20 | |
openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: NotImplemented _for_groups functions on LDAP https://review.openstack.org/102244 | 09:57 |
*** dstanek_zzz is now known as dstanek | 10:00 | |
*** gokrokve has joined #openstack-keystone | 10:02 | |
*** gokrokve has quit IRC | 10:07 | |
*** dstanek is now known as dstanek_zzz | 10:10 | |
*** gokrokve has joined #openstack-keystone | 10:37 | |
*** gokrokve has quit IRC | 10:38 | |
*** dstanek_zzz is now known as dstanek | 11:00 | |
*** dims has joined #openstack-keystone | 11:03 | |
*** dims has quit IRC | 11:08 | |
*** gokrokve has joined #openstack-keystone | 11:08 | |
*** gokrokve_ has joined #openstack-keystone | 11:10 | |
*** gokrokve has quit IRC | 11:13 | |
*** gokrokve_ has quit IRC | 11:15 | |
*** dims_ has joined #openstack-keystone | 11:19 | |
*** dims__ has joined #openstack-keystone | 11:22 | |
*** dims_ has quit IRC | 11:25 | |
*** gokrokve has joined #openstack-keystone | 11:37 | |
*** gokrokve has quit IRC | 11:42 | |
*** erecio has joined #openstack-keystone | 11:44 | |
*** kwss has joined #openstack-keystone | 11:45 | |
*** diegows has joined #openstack-keystone | 11:46 | |
*** rodrigods has joined #openstack-keystone | 11:48 | |
*** rodrigods has joined #openstack-keystone | 11:48 | |
*** otwieracz has joined #openstack-keystone | 11:56 | |
otwieracz | Hi! | 11:56 |
otwieracz | I am going to wokr on: https://bugs.launchpad.net/keystone/+bug/1313837 | 11:56 |
uvirtbot | Launchpad bug 1313837 in keystone "unnecessary period in logs make searching/copy/paste annoying" [Low,Confirmed] | 11:56 |
otwieracz | As I see in source code, generally every message ends with period. | 11:58 |
otwieracz | message_format = _("Could not find policy, %(policy_id)s."), message_format = _("Could not find role, %(role_id)s."), message_format = _("Could not find project, %(project_id)s.") etc | 11:59 |
otwieracz | You think every of this should be corrected? | 11:59 |
otwieracz | Or maybe something like: | 11:59 |
otwieracz | 2014-04-28 16:16:34.225 5037 WARNING keystone.common.wsgi [-] Could not find token, <377c4c9a571a4b5ca64d56fe0aaa29c3>. | 11:59 |
otwieracz | What copies fine and is looking better? | 11:59 |
*** jaosorior has quit IRC | 12:02 | |
*** erecio has quit IRC | 12:11 | |
*** erecio has joined #openstack-keystone | 12:12 | |
*** erecio has quit IRC | 12:13 | |
*** erecio has joined #openstack-keystone | 12:14 | |
*** jaosorior has joined #openstack-keystone | 12:19 | |
*** erecio has quit IRC | 12:20 | |
*** erecio has joined #openstack-keystone | 12:21 | |
*** ajc_ has quit IRC | 12:23 | |
*** dims__ has quit IRC | 12:31 | |
*** dims__ has joined #openstack-keystone | 12:31 | |
*** radez_g0n3 is now known as radez | 12:36 | |
*** gokrokve has joined #openstack-keystone | 12:38 | |
tomoiaga | It seems there is a circular dependency between the session object and the auth plugin. Is this intentional ? | 12:41 |
*** gokrokve has quit IRC | 12:43 | |
*** hrybacki has joined #openstack-keystone | 12:46 | |
otwieracz | https://github.com/openstack/keystone/blob/master/keystone/locale/en_US/LC_MESSAGES/keystone.po | 12:46 |
otwieracz | Is this file somehow generated from source code? | 12:46 |
*** lbragstad has joined #openstack-keystone | 12:50 | |
*** gokrokve has joined #openstack-keystone | 12:53 | |
*** dstanek is now known as dstanek_zzz | 12:53 | |
*** dstanek_zzz is now known as dstanek | 13:00 | |
*** htruta has joined #openstack-keystone | 13:02 | |
*** richm has joined #openstack-keystone | 13:05 | |
*** _elmiko is now known as elmiko | 13:11 | |
*** dstanek is now known as dstanek_zzz | 13:20 | |
*** dstanek_zzz is now known as dstanek | 13:23 | |
*** gokrokve has quit IRC | 13:25 | |
*** gokrokve has joined #openstack-keystone | 13:30 | |
hrybacki | ls | 13:32 |
hrybacki | lol, damnit | 13:32 |
*** gokrokve has quit IRC | 13:33 | |
lbragstad | babel.cfg etc keystone openstack-common.conf requirements.txt test-requirements-py3.txt vendor | 13:33 |
lbragstad | bin examples keystone.egg-info rally-scenarios run_tests.sh test-requirements.txt | 13:33 |
lbragstad | CONTRIBUTING.rst HACKING.rst LICENSE README.rst setup.cfg tools | 13:33 |
lbragstad | doc httpd MANIFEST.in requirements-py3.txt setup.py tox.ini | 13:33 |
*** radez is now known as radez_g0n3 | 13:36 | |
hrybacki | lbragstad++ | 13:37 |
marekd | steeeevemaaaar, wheeere arreee youuuuu? | 13:37 |
lbragstad | hrybacki: I've :wq my manager a few times | 13:38 |
lbragstad | so I know the feeling :) | 13:38 |
hrybacki | lbragstad: hah, good to know. I knew someone else had to have done something similar :) | 13:39 |
*** joesavak has joined #openstack-keystone | 13:45 | |
*** gokrokve has joined #openstack-keystone | 13:53 | |
*** ukalifon has quit IRC | 13:56 | |
*** tomoiaga has quit IRC | 14:01 | |
*** jsavak has joined #openstack-keystone | 14:10 | |
*** Camisa has quit IRC | 14:12 | |
*** joesavak has quit IRC | 14:13 | |
*** ayoung has joined #openstack-keystone | 14:15 | |
*** tellesnobrega has joined #openstack-keystone | 14:21 | |
*** tomoiaga has joined #openstack-keystone | 14:27 | |
*** stevemar has joined #openstack-keystone | 14:30 | |
marekd | stevemar: ding dong. | 14:31 |
stevemar | marekd, howdy | 14:31 |
*** jaosorior has quit IRC | 14:32 | |
marekd | stevemar: do we howe some good docs/blog posts abount oAuth implemented in Keystone? | 14:32 |
marekd | stevemar: how does the workflow look like? | 14:32 |
*** gordc has joined #openstack-keystone | 14:33 | |
stevemar | marekd, the api is probably the best resource | 14:33 |
stevemar | marekd, https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-oauth1-ext.md | 14:33 |
*** tomoiaga has quit IRC | 14:33 | |
marekd | stevemar: let me see that. | 14:34 |
stevemar | marekd, look at "Delegated Authentication Flow" | 14:34 |
*** dstanek is now known as dstanek_zzz | 14:34 | |
marekd | stevemar: i am trying to fit k2k bp into oAuth flow.... | 14:35 |
stevemar | marekd, that sounds like a dangerous game | 14:38 |
marekd | stevemar: hm, why? | 14:38 |
marekd | stevemar: i am curious your opinions on that. | 14:38 |
*** radez_g0n3 is now known as radez | 14:39 | |
stevemar | marekd, i think its nice to give access in this case, rather than delegate | 14:42 |
*** morganfainberg_Z is now known as morganfainberg | 14:42 | |
stevemar | marekd, also, the oauth mechanism is for specifically delegating role(s) to a single project | 14:42 |
marekd | and what about something like claims? | 14:43 |
marekd | or it's oidc specific only? | 14:43 |
*** zhiyan is now known as zhiyan_ | 14:43 | |
*** dstanek_zzz is now known as dstanek | 14:45 | |
*** gokrokve has quit IRC | 14:49 | |
*** rwsu has joined #openstack-keystone | 14:49 | |
*** gokrokve has joined #openstack-keystone | 14:49 | |
*** oomichi has quit IRC | 14:52 | |
*** gokrokve has quit IRC | 14:53 | |
morganfainberg | ayoung, under apache I'm seeing inconsistent failures (tempest). I'm getting the sinking suspicion that the PKIZ tokens are 100% solving things. | 14:54 |
dstanek | morganfainberg: 'are' or 'are not'? | 14:55 |
morganfainberg | dstanek are not | 14:55 |
morganfainberg | dstanek thanks, :P just woke up | 14:56 |
dstanek | stevemar, marekd: finally finish up another pass on https://review.openstack.org/#/c/100023 | 14:56 |
*** david-lyle has joined #openstack-keystone | 14:57 | |
stevemar | dstanek, thank you! | 14:57 |
marekd | dstanek: ++ | 14:58 |
dstanek | i still have reservations about using a single token for all clouds | 14:59 |
ayoung | morganfainberg, how big are they? The ones I saw were nowhere near the limit | 14:59 |
ayoung | I think there is something else going wrong, not a token size issue | 15:00 |
morganfainberg | ayoung, still chasing it down, but it's consistenly an issue with trust XML | 15:00 |
morganfainberg | or.. | 15:00 |
ayoung | morganfainberg, do you have a link? | 15:00 |
morganfainberg | json | 15:00 |
morganfainberg | sec | 15:00 |
morganfainberg | ayoung http://logs.openstack.org/47/100747/9/check/check-tempest-dsvm-full/18f23e5/console.html#_2014-06-25_05_20_37_820 this series of failures i've seen off and on throughout trying to enable the apache keystone deployment | 15:01 |
ayoung | '204' != '200' | 15:02 |
morganfainberg | yeah | 15:02 |
morganfainberg | only under apache | 15:02 |
morganfainberg | haven't seen that one occur except when deployed under apache | 15:02 |
ayoung | let me confirm it is expected vs actualy in the tes... | 15:02 |
morganfainberg | ayoung, wasn't PKIZ in this case, brain is still getitng moving, and chasing a nova bug. | 15:02 |
morganfainberg | ayoung the weird part is i've seen it pass. multiple times | 15:03 |
morganfainberg | under apache | 15:03 |
ayoung | morganfainberg http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/identity/admin/v3/test_trusts.py#n173 | 15:05 |
ayoung | check_trust_role( | 15:05 |
ayoung | so what returns a 200 instead of a 204... | 15:05 |
morganfainberg | ayoung, right. why are we inconsistently under apache getting 204s vs 200s. if i recheck no bug, i almost guarantee it would work. | 15:06 |
ayoung | morganfainberg, well, lets see | 15:06 |
morganfainberg | maybe we're racing somewhere | 15:06 |
ayoung | self.trustor_client = os.identity_v3_client | 15:06 |
ayoung | OK...so over python-keystoneclient | 15:07 |
ayoung | yeah, maybe | 15:07 |
morganfainberg | ayoung, http://logs.openstack.org/47/100747/9/check/check-tempest-dsvm-full/18f23e5/console.html#_2014-06-25_05_20_37_823 is what i am guessing | 15:07 |
ayoung | ./tempest/services/identity/v3/json/identity_client.py:447: | 15:08 |
ayoung | http://git.openstack.org/cgit/openstack/tempest/tree/tempest/services/identity/v3/json/identity_client.py#n447 | 15:09 |
ayoung | so it is doing a HEAD on OS-TRUST/trusts/%s/roles/%s" | 15:09 |
morganfainberg | and it's expecting a 204? | 15:09 |
ayoung | yep | 15:09 |
ayoung | but getting a 200 | 15:09 |
ayoung | 204 vis more correct for a head. | 15:09 |
* ayoung thinks | 15:09 | |
morganfainberg | sure | 15:09 |
ayoung | 204 No Content is, I think, required for HEAD | 15:10 |
ayoung | so the fact that it would ever give a 200 is suspicious | 15:10 |
ayoung | and something that the tempest coder should have called us on | 15:10 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/routers.py#n47 | 15:11 |
stevemar | dolphm, can you take a look @ https://review.openstack.org/#/c/96836/ | 15:11 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n248 | 15:11 |
morganfainberg | is apache... mangling that output somehow? | 15:12 |
ayoung | morganfainberg, it is not apache's fault | 15:12 |
ayoung | it should be a 204 | 15:12 |
ayoung | there is nothing returned from the call | 15:12 |
morganfainberg | right and under eventlet i've never seen it fail | 15:13 |
ayoung | you mean "I've never seen it succeed." the test is wrong | 15:13 |
ayoung | morganfainberg, aside from finding hte problem | 15:14 |
ayoung | the question is what kind of tapdance do we need to do to fix it | 15:14 |
morganfainberg | the test is explicitly asking for a 204 on a HEAD check_role_for_trust doesn't return anything (or raises soemthing else) | 15:14 |
ayoung | we have tempest codifying a bug here | 15:14 |
ayoung | and we should be able to fix it, but we'll break tempest | 15:14 |
ayoung | ohhhh...right, I had it backwards | 15:14 |
morganfainberg | yeah, i'm wondering _how_ that is returning a 200 not a 204 | 15:15 |
ayoung | OK....so, yeah, there must be cases where apache is concocting some sort of body | 15:15 |
morganfainberg | yep | 15:15 |
ayoung | I actually feel better now | 15:15 |
ayoung | hmmm | 15:15 |
morganfainberg | ayoung, hehe, yeah this is an apache oddity | 15:15 |
ayoung | morganfainberg, new hypothesis | 15:16 |
morganfainberg | ok | 15:17 |
ayoung | Apache is doing things "right" ish | 15:17 |
ayoung | meaning it is interpresting something else as a part of the response | 15:17 |
ayoung | and deducing it should have a 200 instead of 204 | 15:17 |
morganfainberg | and eventlet is a bit more sloppy? | 15:18 |
morganfainberg | "oh body looks none, who cares, 204" | 15:18 |
ayoung | all the errors are 200 instead of 204 | 15:19 |
morganfainberg | yep 3 errors | 15:19 |
morganfainberg | the same three i've previously seen | 15:19 |
ayoung | morganfainberg I wonder if it could be a versions thing | 15:20 |
ayoung | like, different hosts have different versions of apache? | 15:20 |
morganfainberg | well... unlkely | 15:21 |
morganfainberg | i've seen this (now) with apache 2.2 and 2.4 | 15:21 |
ayoung | http://logs.openstack.org/47/100747/8/check/check-tempest-dsvm-full/f60fd38/console.html | 15:21 |
ayoung | can we figure what is different between those two runs? | 15:21 |
ayoung | It doesn't feel like a race because it 3 fails versus none | 15:22 |
ayoung | I would expect a race to be more randomly distributed | 15:22 |
ayoung | what does the wsgi app hand back to apache. | 15:23 |
ayoung | ? | 15:23 |
ayoung | does it even give it a response code, or does apache deduce that? I am guessing it does give back a response | 15:23 |
ayoung | and then apache reinterprets it | 15:23 |
ayoung | so question is whether apache or keystone is generatng the 200 | 15:24 |
*** gokrokve has joined #openstack-keystone | 15:26 | |
*** gokrokve has quit IRC | 15:26 | |
ayoung | https://issues.apache.org/bugzilla/show_bug.cgi?id=38070 interesting | 15:26 |
uvirtbot | ayoung: Error: Could not parse XML returned by issues.apache.org: HTTP Error 404: Not Found | 15:26 |
*** andreaf_ has joined #openstack-keystone | 15:27 | |
ayoung | morganfainberg, so we have at least one case of apache rewriting response codes from a wsgi app | 15:28 |
morganfainberg | interesting | 15:28 |
*** andreaf_ has quit IRC | 15:28 | |
*** gyee has joined #openstack-keystone | 15:31 | |
dstanek | stevemar, marekd: quick question - will the remote keystone be able to open a token from a local keystone and see the data inside? | 15:43 |
marekd | stevemar: dstanek it should...? | 15:43 |
marekd | dstanek: ^^ | 15:43 |
marekd | dstanek: otherwise how remote keystone will validate if the token is not faked.. | 15:44 |
*** daneyon has joined #openstack-keystone | 15:45 | |
dstanek | marekd, stevemar: my concern there is information leakage | 15:46 |
marekd | dstanek: what exactly? | 15:46 |
ayoung | dstanek token is a transparent container | 15:47 |
ayoung | anyone can read it | 15:47 |
dstanek | marekd: whatever's in the token - catalog, groups, etc - something we don't have yet that could cause a problem | 15:47 |
ayoung | you only need the private key to validate | 15:47 |
*** daneyon has quit IRC | 15:47 | |
ayoung | dstanek, then only send information that is relevant | 15:47 |
dstanek | ayoung: i don't think you can - the user can't edit the token right? | 15:48 |
ayoung | dstanek, Hell no | 15:48 |
ayoung | dstanek, but you could create a trust with only the subset of the data you want, and use that token | 15:48 |
marekd | ayoung: you need private or public key? | 15:48 |
marekd | ayoung: to validate. | 15:48 |
ayoung | public key | 15:48 |
marekd | i'd say you sign with private and validate with public... | 15:48 |
marekd | ok | 15:48 |
ayoung | heh | 15:48 |
dstanek | ayoung: then whatever your local keystone puts in the token would be available to the remote keystone | 15:48 |
ayoung | marekd, did I give you a heart attack? | 15:48 |
marekd | ayoung: almost...:-) | 15:49 |
ayoung | dstanek, yep | 15:49 |
ayoung | dstanek, or anyone else that gets the token | 15:49 |
ayoung | token data is public data | 15:49 |
dstanek | ayoung: besides the obvious risk because the token in a bearer token...but should the data in the token be considered 'private' in that you wouldn't want it to leak outside of your OpenStack installation? | 15:51 |
*** david-lyle has quit IRC | 15:51 | |
marekd | dstanek: i don't have any issue with that | 15:51 |
*** david-lyle has joined #openstack-keystone | 15:51 | |
marekd | dstanek: you only send it to the remote services, that you *somehow* trust. | 15:52 |
marekd | dstanek: not 100% of course | 15:52 |
marekd | and IMHO you never should | 15:52 |
ayoung | how has httpd not migrated over to git yet | 15:52 |
marekd | but it's not exposing your token to complete strangers. | 15:52 |
dstanek | marekd: is there any reason that cern wouldn't want rackspace to know about it's endpoints, group structure, etc? | 15:53 |
*** gokrokve has joined #openstack-keystone | 15:53 | |
*** i159 has quit IRC | 15:54 | |
*** david-lyle has quit IRC | 15:56 | |
marekd | dstanek: nor cern particulary, but maybe other cloud admins.... but...maybe we can omit Service Catalog in such tokens? | 15:57 |
*** david-lyle has joined #openstack-keystone | 15:57 | |
dstanek | as a service provider you won't know if a token will be used across clouds | 15:57 |
ayoung | morganfainberg, ok so, starting from http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/httpd.h?view=markup | 15:57 |
dstanek | marekd: ^ | 15:58 |
marekd | dstanek: we have discussed | 15:58 |
ayoung | morganfainberg, the symbol is NO_CONTENT | 15:58 |
ayoung | 489 #define HTTP_NO_CONTENT 204 | 15:58 |
marekd | dstanek: some 'flags' or whatever for extended service catalog..but hehe, i am in my own trap...i later want to get rid of the SC :P | 15:58 |
morganfainberg | ayoung, brb, filing a rather large (and classifying) nova bug. | 15:59 |
ayoung | morganfainberg, I'm going to keep posting these as a trail, feel free to ignore until you are ready | 15:59 |
*** david-lyle has quit IRC | 16:00 | |
*** gokrokve has quit IRC | 16:00 | |
morganfainberg | ayoung just need to propose the ER change and i'm back, 1 min | 16:00 |
*** david-lyle has joined #openstack-keystone | 16:00 | |
dstanek | marekd: what's interesting there is the user is in control of the information leakage in a way where they have to do something above and beyond what they do now | 16:00 |
dstanek | marekd: i'm just trying to organize my thoughts :-) | 16:01 |
marekd | dstanek: I have been trying to do that for days (regarding k2k bp) :( | 16:01 |
ayoung | morganfainberg, https://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/server/mod_wsgi.c#L10507 is the only place I see NO_CONTENT | 16:02 |
marekd | dstanek: sorry, need to run now, urgent matter. | 16:02 |
marekd | feel free to leave more comments on the bp, so we all can keep track | 16:02 |
dstanek | marekd: will do | 16:02 |
ayoung | that is in wsgi_execute_remote( so I think that is pretty much it | 16:03 |
ayoung | https://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/server/mod_wsgi.c#L9875 | 16:03 |
ayoung | but then they do things like if (r->status == 200 && !strcmp(r->status_line, "200 Error")) { | 16:04 |
morganfainberg | ayoung, ok back | 16:05 |
ayoung | morganfainberg, I'm digging through the mod_wsgi and httpd 2.4 code bases | 16:06 |
morganfainberg | ayoung, ++ | 16:06 |
ayoung | there is really only one pointwhere it explicitly refernces a 204 | 16:06 |
*** kwss has quit IRC | 16:06 | |
ayoung | but I guess there might be a check for 2XX and that is what I am looking for now | 16:06 |
ayoung | define ap_is_HTTP_SUCCESS(x) (((x) >= 200)&&((x) < 300)) | 16:07 |
ayoung | that was from ./httpd/include/httpd.h:489 | 16:08 |
ayoung | doesn't appear in the mod_wsgi code | 16:08 |
morganfainberg | that seems reasonable though | 16:08 |
morganfainberg | it's a success if >= 200, but not a 300 code | 16:08 |
ayoung | ./src/server/mod_wsgi.c:1765: if (self->status >= 200 && self->status < 400) { | 16:09 |
ayoung | morganfainberg, want to see, if not a smoking gun, then at least power burns? | 16:13 |
ayoung | https://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/server/mod_wsgi.c#L5227 | 16:13 |
morganfainberg | wait.. HEAD -> GET?!?! | 16:14 |
morganfainberg | really? | 16:14 |
*** praneshp has joined #openstack-keystone | 16:14 | |
morganfainberg | *blink* | 16:14 |
morganfainberg | because 'WSGI authors are lazy" | 16:14 |
morganfainberg | am i reading that correctly? | 16:14 |
ayoung | not lazy | 16:15 |
ayoung | just "return no content" which kindof makes sense, but I suspect that, in this case, it is calling the wrong operation in the controller | 16:16 |
morganfainberg | but. | 16:16 |
morganfainberg | it works _sometimes_ | 16:16 |
ayoung | yep | 16:16 |
morganfainberg | i am a iittle baffled why trust is the onlyone that hits this as well | 16:17 |
morganfainberg | have't seen it with other HEAD calls | 16:17 |
morganfainberg | unless. thats the only one we test in TEMPEST | 16:17 |
*** david-lyle has quit IRC | 16:17 | |
*** david-lyle has joined #openstack-keystone | 16:17 | |
*** david-lyle has quit IRC | 16:19 | |
*** david-ly_ has joined #openstack-keystone | 16:19 | |
bknudson | is keystone treating a HEAD request differently than a GET? | 16:20 |
morganfainberg | bknudson, yes in the case of trusts. we return no content (204) as expected | 16:20 |
bknudson | morganfainberg: from HEAD and GET? | 16:20 |
bknudson | i.e., if you did a GET it returns 204? | 16:21 |
morganfainberg | bknudson, no | 16:21 |
morganfainberg | bknudson HEAD does the 204, get would give actual data | 16:21 |
morganfainberg | unfortunately, ayoung found code in mod_wsgi that (in some cases) makes a HEAD request into a GET request to the wsgi app. | 16:21 |
bknudson | that's how HEAD is supposed to work... returns what a GET would return, except w/o the body | 16:21 |
bknudson | so if GET would return 200 then HEAD should return 200 | 16:21 |
morganfainberg | really? | 16:22 |
bknudson | http://tools.ietf.org/html/rfc2616#section-9.4 | 16:22 |
*** david-ly_ has quit IRC | 16:22 | |
*** david-lyle has joined #openstack-keystone | 16:23 | |
morganfainberg | so we need to go fix a bunch of things i think in keystone | 16:23 |
morganfainberg | and tempest | 16:23 |
* morganfainberg ponder | 16:24 | |
*** packet has joined #openstack-keystone | 16:24 | |
morganfainberg | or eventlet is doing something very wonky | 16:24 |
*** afazekas_ has quit IRC | 16:26 | |
*** BAKfr has quit IRC | 16:27 | |
*** david-lyle has quit IRC | 16:27 | |
morganfainberg | bknudson, yeah we seem to support HEAD differently in many cases. | 16:29 |
morganfainberg | bknudson, sometimes without supporting GET | 16:29 |
morganfainberg | sometimes with different responses than GET | 16:29 |
bknudson | morganfainberg: I'm not sure that supporting HEAD without GET really makes sense from a HTTP perspective... | 16:30 |
bknudson | what would wsgi keystone do in that case? | 16:30 |
bknudson | fail with 404? | 16:30 |
morganfainberg | bknudson, yep | 16:30 |
bknudson | yikes! | 16:30 |
ayoung | morganfainberg, we could make it a different URL, but that seems borked | 16:30 |
bknudson | just have GET return 204 | 16:31 |
bknudson | and change HEAD to return 204 | 16:31 |
ayoung | bknudson, nope | 16:31 |
bknudson | or have it return some body {} | 16:31 |
ayoung | GET return 204 with a body is wrong | 16:31 |
morganfainberg | ayoung, not wrong, just not common | 16:31 |
bknudson | GET 204 w/o a body, or GET 200 with some body {} | 16:31 |
morganfainberg | ayoung if there is no content, there is no content :P | 16:31 |
ayoung | morganfainberg, no, becasue the GET returns something | 16:31 |
ayoung | and the HEAD is not supposed to | 16:31 |
bknudson | HEAD isn't allowed to return a body per the spec | 16:32 |
ayoung | but in this case it would...there is nothing indicating it is a HEAD request, is there? | 16:32 |
bknudson | apache strips off the body for a HEAD request | 16:32 |
ayoung | morganfainberg, when would GET ever return a 204 | 16:32 |
morganfainberg | ayoung, http://tools.ietf.org/html/rfc2616#section-10.2.5 doesn't say GET can't do 204 | 16:32 |
ayoung | morganfainberg, I mean in this instance | 16:33 |
bknudson | we could have our eventlet server work the same as apache | 16:33 |
ayoung | the controller call | 16:33 |
morganfainberg | ayoung, this case uhm... | 16:33 |
bknudson | change HEAD into GET and strip off the body | 16:33 |
morganfainberg | ayoung, /projects/{project_id}/groups/{group_id}/roles/{role_id} ? we don't have a GET for it | 16:33 |
morganfainberg | therefore a HEAD and GET indicate existence of a resource, just no content | 16:33 |
ayoung | morganfainberg, I'm just talking about the failing test in trusts | 16:33 |
morganfainberg | both would be 204 valid | 16:33 |
morganfainberg | oh | 16:33 |
morganfainberg | uh. | 16:34 |
ayoung | check_role_for_trust(self, context, trust_id, role_id): | 16:34 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n248 is the HEAD | 16:34 |
ayoung | but | 16:34 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n259 is the GET | 16:34 |
morganfainberg | ayoung, right | 16:34 |
morganfainberg | could we smush them together? | 16:34 |
ayoung | so we really need to make HEAD return 200 | 16:35 |
morganfainberg | in cases where the get would return 200, the head should also return too | 16:35 |
morganfainberg | 200* | 16:36 |
* morganfainberg wonders how many things will get broken if we fix this | 16:37 | |
bknudson | we've said that you could run keystone in apache forever | 16:37 |
bknudson | so it's been working that way for whoever was running that way | 16:37 |
morganfainberg | bknudson, the wierd thing is this doesn't fail tempest under apache everytime | 16:37 |
bknudson | morganfainberg: that is weird | 16:37 |
morganfainberg | bknudson, yeah | 16:37 |
bknudson | well, maybe shouldn't be surprising considering random tempest failures. | 16:38 |
morganfainberg | bknudson, sure, but this one seems like a legitimate case of "we're actually doing something wrong" and sometimes we fail. | 16:39 |
morganfainberg | it also makes me wonder if eventlet does something dumb | 16:40 |
morganfainberg | like if you say HEAD request, and there is actual content, it gives the content back too | 16:40 |
bknudson | eventlet is probably trusting the application to work correctly | 16:41 |
morganfainberg | so in all likelyhood we should just be returning an empty body for HEAD requests if the get would return something in the body | 16:42 |
morganfainberg | or so we also need to provide content length? | 16:43 |
dolphm | morganfainberg: you actually are supposed to send a non-zero Content-Length in response to HEAD, but we don't do that | 16:48 |
dolphm | morganfainberg: as far as i know, anyway | 16:48 |
morganfainberg | dolphm, ok. i'll file a bug on this. | 16:48 |
morganfainberg | dolphm, i think we need to resolve GET vs HEAD responses before we can move to apache then. | 16:48 |
morganfainberg | so we don't end up with sometimes-failing odd gate cases. | 16:49 |
*** daneyon has joined #openstack-keystone | 16:49 | |
* dolphm scrolls back wondering wtf is going on... | 16:49 | |
*** browne has joined #openstack-keystone | 16:50 | |
morganfainberg | dolphm, we sometimes fail a check under apache where tempest is expecting a 204 back from a HEAD call | 16:50 |
morganfainberg | dolphm, but the GET for the same call would be 200 | 16:50 |
morganfainberg | dolphm in some cases, apache (mod_wsgi) will convert a HEAD request to GET and just strip the data off | 16:50 |
morganfainberg | it appears we should _never_ respond with a different HTTP code on HEAD vs GET. but we do at least in a couple places (404 vs 204, 204 vs 200, etc) | 16:51 |
dolphm | morganfainberg: oooh - that's probably my fault :( | 16:51 |
*** gokrokve has joined #openstack-keystone | 16:51 | |
morganfainberg | even under apache it's not 100% consistent, should be pretty easy to fix, but will require some fixes across keystone, tempest and possibly ksc | 16:52 |
dolphm | morganfainberg: sounds like the wsgi module itself should handle HEAD requests, and we should only implement GET controller methods? | 16:53 |
morganfainberg | sounds like a good approach | 16:53 |
morganfainberg | I'll file a bug shortly and see how broken things get doing thay implementation today after breakfast | 16:55 |
morganfainberg | thay = that | 16:55 |
dstanek | dolphm: that's exactly how we handled it where i used to work | 17:00 |
dstanek | stevemar: i think i'm done thinking about that review for a few days :-) | 17:00 |
*** david-lyle has joined #openstack-keystone | 17:01 | |
otwieracz | Guys, can you just take a look at http://wklej.org/hash/d864b3039a/, this is output of otwieracz@voyager ~/keystone $ tox | 17:04 |
otwieracz | Why it is failing on unmodified master branch? | 17:04 |
dolphm | otwieracz: looks like all kinds of things going wrong there - i don't even know where to start | 17:07 |
dolphm | otwieracz: what's the output of $ python --version | 17:07 |
dolphm | otwieracz: almost looks like the version of python that tox is assuming you have is completely wrong (it's assuming 2.7.x for the tests being executed, and the failure might suggest you're on 3.x?) | 17:09 |
dstanek | otwieracz: it looks like your ipv6 tests are failing failing on 2.7 | 17:10 |
*** jsavak has quit IRC | 17:12 | |
otwieracz | otwieracz@voyager ~ $ python --version | 17:13 |
otwieracz | Python 3.3.3 | 17:13 |
otwieracz | otwieracz@voyager ~ $ python2 --version | 17:13 |
otwieracz | Python 2.7.6 | 17:13 |
*** harlowja_away is now known as harlowja | 17:13 | |
hrybacki | ayoung: so where do we stand in regards to cinder. That left me more confused than when we began | 17:14 |
dstanek | otwieracz: start with getting it to work on just 2.7 by running 'tox -e py27' | 17:15 |
otwieracz | dstanek: ok | 17:15 |
ayoung | hrybacki, it means that Cinder is already done | 17:16 |
ayoung | and we can use that as an example of what to do in the other clients | 17:16 |
hrybacki | ++ | 17:16 |
hrybacki | and what about the discover bit? | 17:16 |
ayoung | but the "external auth plugins" part leaves me a little concerned, so take a note to figure out what they are doing there | 17:17 |
ayoung | probably for talking to non-keystone auth systems, I hope | 17:17 |
dstanek | otwieracz: you probably don't have python2.6 installed so that will always fail | 17:17 |
otwieracz | I need python2.6 for -e py27? | 17:17 |
dstanek | otwieracz: no, based on your output you just ran 'tox' - that will fail without Python2.6 because it tries to run against all of the environments in envlist | 17:19 |
otwieracz | Yes, ok. | 17:20 |
otwieracz | You've scared me :) | 17:20 |
otwieracz | But, still failing on v6. | 17:20 |
dstanek | i don't think this is a Keystone specific issue - for some reason you system passed the ipv6 check, but can't actually connect to ipv6 | 17:22 |
dstanek | firewall issue? | 17:22 |
dolphm | dstanek: otwieracz: i think it's trying to run python 2.7 tests on python 3.3 | 17:22 |
dolphm | or something | 17:22 |
dstanek | dolphm: what makes you say that? | 17:23 |
otwieracz | I have IPv6 here. | 17:23 |
otwieracz | So that's probably why. | 17:23 |
dolphm | dstanek: $ python --version is 3.3.3, and "py27 runtests: commands[0] | python setup.py testr --slowest --testr-args= ..." | 17:23 |
dolphm | dstanek: shouldn't that be python2.7, not just python? | 17:24 |
dstanek | dolphm: i think it is in the activated env at that point and python should point to the Python that created it - but i'm not 100% sure on that | 17:24 |
dolphm | otwieracz: what platform are you using that is defaulting python to 3.3? | 17:24 |
otwieracz | Gentoo. | 17:24 |
dolphm | dstanek: i'd hope so too, but ... | 17:24 |
otwieracz | But whatever, -e 27 does not work too. | 17:25 |
otwieracz | -e py27* | 17:25 |
*** daneyon has quit IRC | 17:25 | |
dolphm | otwieracz: what happens if you run... $ python2.7 setup.py testr | 17:25 |
otwieracz | error: invalid command 'testr' | 17:26 |
dstanek | you'll have to use .tox/py27/bin/python | 17:26 |
dstanek | if you run that version of python wiht the --version flag it should be 2.7 | 17:26 |
dolphm | otwieracz: err, what's .tox/py27/bin/python --version ? | 17:26 |
*** daneyon has joined #openstack-keystone | 17:26 | |
otwieracz | 2.7.6 | 17:26 |
dolphm | otwieracz: well then i'm wrong. | 17:26 |
otwieracz | /usr/bin/python3.3: No module named 'subunit' | 17:26 |
otwieracz | while | 17:26 |
otwieracz | otwieracz@voyager ~/mirantis/git/keystone-orig $ .tox/py27/bin/python setup.py testr | 17:27 |
morganfainberg | dolphm, https://bugs.launchpad.net/keystone/+bug/1334368 HEAD vs GET, marked it as medium | 17:27 |
uvirtbot | Launchpad bug 1334368 in keystone "HEAD and GET inconsistencies in Keystone" [Medium,Triaged] | 17:27 |
dstanek | i think your 2.7 setup is fine and you are just having trouble connecting over ipv6 | 17:27 |
otwieracz | I think the same. | 17:28 |
otwieracz | But I do not know, why. | 17:28 |
otwieracz | Oh, I may know why. | 17:28 |
dstanek | my best guess would be firewall or some other system issue | 17:28 |
morganfainberg | dolphm, as much as I want to classify that as "High", it doesn't "break" anything in awful ways, and people have been living with it for quite some time | 17:28 |
*** daneyon has quit IRC | 17:29 | |
otwieracz | dstanek: Yes, that might be the issue – testing now. | 17:29 |
dstanek | as for py3 - i'm working on getting a few things fixed there - updated deps broke things | 17:30 |
*** daneyon has joined #openstack-keystone | 17:31 | |
*** nsquare has joined #openstack-keystone | 17:34 | |
ayoung | hrybacki, https://review.openstack.org/#/c/92390/ but that is only API, not session. | 17:37 |
hrybacki | the commit message is misleading then | 17:38 |
otwieracz | dstanek: Yes, now 27 passed./ | 17:39 |
otwieracz | dstanek: It was firewall issue. | 17:39 |
*** marcoemorais has joined #openstack-keystone | 17:42 | |
dstanek | otwieracz: excellent | 17:42 |
otwieracz | Thanks for help. | 17:42 |
dstanek | no problem | 17:44 |
otwieracz | If I change exception message I should also fix po files? | 17:47 |
otwieracz | I mean, there's no other translation project? | 17:48 |
dstanek | otwieracz: you want to change the message for a specific translation? | 17:49 |
otwieracz | https://bugs.launchpad.net/keystone/+bug/1313837 | 17:49 |
uvirtbot | Launchpad bug 1313837 in keystone "unnecessary period in logs make searching/copy/paste annoying" [Low,Confirmed] | 17:49 |
otwieracz | this bug | 17:49 |
morganfainberg | otwieracz, translations are handled via transifex, don't change the .po files | 17:49 |
*** daneyon has quit IRC | 17:50 | |
dstanek | otwieracz: you would change that in the Python code | 17:50 |
otwieracz | morganfainberg: So, if I change messages in „exceptions.py” | 17:50 |
dstanek | what morganfainberg said :-) | 17:50 |
morganfainberg | otwieracz, the translators will need to do the updates and then it would get update based upon what you change in the python file | 17:50 |
otwieracz | morganfainberg: I should not update po files? | 17:50 |
otwieracz | morganfainberg: OK! | 17:50 |
otwieracz | morganfainberg: That's great. | 17:50 |
morganfainberg | otwieracz, correct, do not update the .po files :) | 17:50 |
otwieracz | morganfainberg: I was worrying if I do not miss anything updating lots of lines in .po files. | 17:50 |
otwieracz | So, only .py, right? | 17:51 |
dstanek | otwieracz: yes | 17:51 |
otwieracz | Great. | 17:51 |
hrybacki | ayoung: so it looks like cinder pretty nearly copied the work the neutron folks had done, yeah? | 18:01 |
ayoung | neutron? | 18:03 |
ayoung | you mean keystone? | 18:03 |
hrybacki | https://review.openstack.org/#/c/92390/ -- neutronclient | 18:04 |
ayoung | neutron only did V3 api work, so change what they called on the server | 18:04 |
hrybacki | https://review.openstack.org/#/c/95305 -- cinderclient | 18:04 |
ayoung | cinder went frther | 18:04 |
ayoung | and used keystoneclient | 18:04 |
hrybacki | true but they are many similarities between the two -- trying to find where this copy and pasting originated from | 18:05 |
ayoung | probably from the keystoneclient itself hrybacki | 18:08 |
stevemar | dstanek, thanks for the review boss | 18:13 |
*** joesavak has joined #openstack-keystone | 18:13 | |
*** afazekas_ has joined #openstack-keystone | 18:13 | |
dstanek | stevemar: my pleasure - i'm looking forward to getting feedback on my security related thoughts | 18:14 |
*** ukalifon has joined #openstack-keystone | 18:22 | |
*** morganfainberg_L has quit IRC | 18:31 | |
stevemar | dstanek, you've got to stop copying and pasting your comments from whatever you're writing them in :P | 18:37 |
stevemar | they keep breaking the text boxes | 18:37 |
openstackgerrit | Harry Rybacki proposed a change to openstack/python-keystoneclient: Add optional parameters to EndpointManger create() https://review.openstack.org/102602 | 18:40 |
*** afazekas_ has quit IRC | 18:41 | |
*** ukalifon has quit IRC | 18:41 | |
*** ukalifon has joined #openstack-keystone | 18:41 | |
dstanek | i'm writing directly into the browser :-( | 18:42 |
*** stevemar has quit IRC | 18:52 | |
*** stevemar has joined #openstack-keystone | 18:52 | |
*** harlowja has quit IRC | 18:52 | |
*** stevemar has quit IRC | 18:56 | |
*** stevemar has joined #openstack-keystone | 18:56 | |
*** marcoemorais has quit IRC | 18:59 | |
*** marcoemorais has joined #openstack-keystone | 18:59 | |
*** marcoemorais has quit IRC | 19:00 | |
*** marcoemorais has joined #openstack-keystone | 19:00 | |
*** marcoemorais has quit IRC | 19:01 | |
*** marcoemorais has joined #openstack-keystone | 19:02 | |
*** marcoemorais has quit IRC | 19:02 | |
*** marcoemorais has joined #openstack-keystone | 19:02 | |
*** afazekas_ has joined #openstack-keystone | 19:03 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: V3 extension advertisement https://review.openstack.org/95973 | 19:04 |
*** openstackgerrit has quit IRC | 19:04 | |
*** openstackgerrit has joined #openstack-keystone | 19:06 | |
*** hrybacki_ has joined #openstack-keystone | 19:30 | |
*** daneyon has joined #openstack-keystone | 19:30 | |
*** hrybacki has quit IRC | 19:33 | |
*** dstanek is now known as dstanek_zzz | 19:34 | |
*** hrybacki_ has quit IRC | 19:35 | |
*** CaioBrentano has joined #openstack-keystone | 19:35 | |
CaioBrentano | hi all... | 19:35 |
CaioBrentano | does anyone knows what is the "ca_certs" parameter on keystone.conf, session [ssl] ? | 19:36 |
morganfainberg | dstanek_zzz, https://bugs.launchpad.net/keystone/+bug/1334408 | 19:36 |
uvirtbot | Launchpad bug 1334408 in keystone "test_backend classes not always run in the test_backend_* module" [Wishlist,New] | 19:36 |
morganfainberg | dstanek_zzz, figure you'd appreciate this one | 19:36 |
CaioBrentano | I configured my keystone to work with ssl… Its working just fine… and I didnt set this parameter | 19:36 |
*** joesavak has quit IRC | 19:39 | |
*** daneyon has quit IRC | 19:41 | |
*** dstanek_zzz is now known as dstanek | 19:45 | |
dstanek | morganfainberg: your just saying that we add a backend and don't alway test it? | 19:47 |
morganfainberg | no we add a test case | 19:47 |
morganfainberg | and we don't test it against all of our backends | 19:47 |
morganfainberg | e.g. inheritence | 19:47 |
morganfainberg | you know we only run the inheritence test cases against SQL? | 19:47 |
dstanek | ah | 19:47 |
morganfainberg | even though KVS supports it. LDAP on the other hand doesn't, shouldn't we be at least explicitly skipping then? | 19:48 |
dstanek | does a coverage report show that we are lacking tests? | 19:48 |
morganfainberg | sortof | 19:48 |
morganfainberg | we catch some of the code elsewhere | 19:48 |
morganfainberg | this all stems from the 'dump everything in test_backend' and the make submodules to run the tests | 19:49 |
morganfainberg | we should probably have something a bit smarter than humans to automatically test these things "oh I see you have KVS, SQL, and LDAP as assignment backends, I'll run the assignment test suits over them, put overrides >>> here <<< if needed" | 19:49 |
morganfainberg | s/smarter/less likely to forget something/ | 19:50 |
morganfainberg | as it turns out... KVS inheritance is kinda broken. | 19:50 |
* morganfainberg wants KVS backends to die for Identity / Assignment | 19:51 | |
morganfainberg | dolphm, can we deprecate KVS for identity and assignment instead of re-implementing under dogpile? or does soemthing like mongo make sense for those? | 19:51 |
*** ukalifon has quit IRC | 19:52 | |
*** andreaf_ has joined #openstack-keystone | 19:52 | |
*** erecio has quit IRC | 19:52 | |
dstanek | morganfainberg: i have a bunch of commits coming to start cleaning up the tests, so i'm hoping that i'll be making this easier | 19:55 |
morganfainberg | dstanek, cool | 19:56 |
*** erecio has joined #openstack-keystone | 19:57 | |
dstanek | morganfainberg: i'll rebase and get the first few up there soon - they change where new refs are created so every few days i have to manually rebase | 19:58 |
*** openstackgerrit has quit IRC | 20:05 | |
*** openstackgerrit has joined #openstack-keystone | 20:06 | |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Middleware tests now run under Python3 https://review.openstack.org/99669 | 20:11 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Adds a fork of python-ldap for Py3 testing https://review.openstack.org/95827 | 20:11 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Updates Python3 requirements to match Python2 https://review.openstack.org/95826 | 20:11 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Adds oslo.db support for Python 3 tests https://review.openstack.org/102624 | 20:11 |
morganfainberg | dstanek, i think i still want to prepose patches that simply redact identity and assignment KVS :P | 20:11 |
dstanek | morganfainberg: works for me | 20:21 |
*** afazekas_ has quit IRC | 20:21 | |
*** CaioBrentano has left #openstack-keystone | 20:22 | |
*** wchrisj has joined #openstack-keystone | 20:28 | |
wchrisj | dolphm: got a sec for a quick question? | 20:29 |
wchrisj | nm dolphm | 20:31 |
*** cuddyt has joined #openstack-keystone | 20:31 | |
wchrisj | Could someone tell me if the Keystone v3 API allows a user to auth with JUST a user-name and password? I know I can auth with a user-id and password, but most users wont know their id... | 20:32 |
wchrisj | When I attempt to auth with a uname/pwd, it fails asking for a domain... | 20:32 |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones https://review.openstack.org/100023 | 20:34 |
*** andreaf_ has quit IRC | 20:39 | |
*** stevemar has quit IRC | 20:45 | |
dstanek | wchrisj: yes you need username, password and domain | 20:46 |
wchrisj | The docs seem to say that auth with just a uname/pwd wont work: "Provide one of the following sets of credentials to authenticate: User ID and password, user name and password scoped by domain ID or name, user ID and password scoped by project ID or name with or without domain scope, or token." | 20:46 |
wchrisj | thx dstanek, looks that way | 20:47 |
wchrisj | works with v2, not with v3 | 20:47 |
dstanek | wchrisj: http://git.openstack.org/cgit/openstack/identity-api/tree/v3/src/markdown/identity-api-v3.md#n1292 | 20:48 |
*** marcoemorais has quit IRC | 20:48 | |
wchrisj | thanks dstanek | 20:49 |
*** htruta has quit IRC | 20:50 | |
*** tellesnobrega has quit IRC | 20:50 | |
*** rodrigods has quit IRC | 20:50 | |
*** rodrigods has joined #openstack-keystone | 20:51 | |
*** tellesnobrega has joined #openstack-keystone | 20:51 | |
*** htruta has joined #openstack-keystone | 20:51 | |
*** daneyon has joined #openstack-keystone | 20:52 | |
dstanek | wchrisj: np | 20:55 |
boris-42 | morganfainberg hi | 20:56 |
*** erecio has quit IRC | 20:56 | |
morganfainberg | boris-42, hi there! | 20:56 |
boris-42 | morganfainberg can you pls review plugin sample for keystone | 20:56 |
boris-42 | morganfainberg https://review.openstack.org/#/c/98836/ | 20:56 |
*** radez is now known as radez_g0n3 | 20:56 | |
boris-42 | it's already for quite long time | 20:56 |
*** topol has joined #openstack-keystone | 20:57 | |
boris-42 | morganfainberg 17 days since uploaded (and 13 since latest update) | 20:57 |
morganfainberg | boris-42 i'll take a look at ti today, need to finish this bug i'm trying to resolve now. | 20:58 |
*** gokrokve_ has joined #openstack-keystone | 20:58 | |
morganfainberg | dstanek wow, group grants in kvs are... just not there... really at all | 20:59 |
*** gokrokve has quit IRC | 21:01 | |
dstanek | morganfainberg: kvs is at best a toy for tests | 21:03 |
morganfainberg | dstanek, and even that is suspect at this point :P | 21:04 |
topol | dstanek, didnt someone tell you. dont go looking at kvs. You wont like what you see... | 21:07 |
dstanek | topol: that would have been good advice before my eyes started to bleed | 21:10 |
topol | dstanek, sorry. But you will see those floating spots in your eyes now forever. It wont go away | 21:11 |
*** daneyon has quit IRC | 21:11 | |
*** ayoung is now known as ayoung-dadmode | 21:15 | |
*** marcoemorais has joined #openstack-keystone | 21:21 | |
morganfainberg | so, sdague raised a rather serious issue we have, catalog in the token issue | 21:27 |
morganfainberg | http://logs.openstack.org/66/99766/2/check/check-grenade-dsvm/9fd33e1/logs/old/screen-key.txt.gz?level=INFO | 21:27 |
*** harlowja has joined #openstack-keystone | 21:28 | |
morganfainberg | careful that might kill your browser | 21:28 |
morganfainberg | ~900k lines of eventlet stack traces | 21:28 |
morganfainberg | and it looks like we're exceeding the maximum size allowed by eventlet in keystone. | 21:28 |
morganfainberg | oh... and it results in "cloud death"™ when that occurs | 21:28 |
morganfainberg | dstanek, dolphm, jamielennox|away, topol, gyee, ayoung-dadmode, ^ | 21:29 |
morganfainberg | we can try and backport PKIZ to icehouse (that is icehouse) | 21:29 |
morganfainberg | but i think this highlights we _must_ get the catalog out of the token. | 21:30 |
* morganfainberg will resurrect the token version spec tonight. | 21:30 | |
morganfainberg | nkinder, ^ as well, since ayoung-dadmode is dadmode. | 21:32 |
morganfainberg | obviously the easiest solution is UUID tokens, but that is sub-wonderful for other reasons. | 21:32 |
bknudson | what's wrong with UUID tokens? | 21:33 |
gyee | morganfainberg, yeah, that's a known limitation, we can't have more than 8K header by default | 21:33 |
bknudson | if your tokens are too big then uuid tokens are the way to go | 21:33 |
morganfainberg | bknudson, nothing. just that we've been pushing for PKI for a while | 21:33 |
nkinder | morganfainberg: yeah, I really worry about the token size issues | 21:33 |
nkinder | well, UUID tokens force a round trip to keystone for validation (right?) | 21:34 |
morganfainberg | if the best answer for icehouse is send out a message telling operators to use UUID instead for big deployments, we might have another set of riots on our hands | 21:34 |
morganfainberg | nkinder, correct | 21:34 |
*** gordc has quit IRC | 21:34 | |
bknudson | at some point the overheads of huge tokens are higher than the overhead of keystone roundtrip | 21:34 |
nkinder | ..also, we're back to having a big token database to maintain | 21:34 |
morganfainberg | bknudson, well looks like at 8k we break the cloud ;) | 21:34 |
bknudson | there is no other option for icehouse other than to use UUID tokens | 21:35 |
gyee | PKI token is the right direction | 21:35 |
bknudson | for big deployments | 21:35 |
gyee | we just need to solve the freakin catalog headache | 21:35 |
morganfainberg | bknudson, that means we need to change the gate / grenade default | 21:35 |
nkinder | gyee: +1 | 21:35 |
morganfainberg | bknudson, because gate is tipping over [not a big deployment] | 21:35 |
morganfainberg | but big enough | 21:35 |
morganfainberg | its intermittant, but still. | 21:35 |
bknudson | by big deployments I mean 1 server | 21:35 |
morganfainberg | bknudson, so we should default back to UUID for I? | 21:36 |
gyee | heh | 21:36 |
gyee | 1 server big deployment | 21:36 |
morganfainberg | and change the documentation? | 21:36 |
bknudson | I don't know what else to do about it | 21:36 |
morganfainberg | gyee, ++ the catalog needs to be out of the token this release or PKI is probably a dead token option | 21:36 |
topol | morganfainberg how did the catalog get soooo big? | 21:37 |
morganfainberg | bknudson, it's a fair option. neither do i. ;) | 21:37 |
nkinder | why does the catalog have to be in the token in the first place? | 21:37 |
*** mrda-away is now known as mrda | 21:37 | |
morganfainberg | topol, we keep the entire url among other cruft in there. | 21:37 |
gyee | morgainfainberg, I almost think catalog needs its own service, like LDAP or something | 21:37 |
morganfainberg | nkinder, it doesn;t. why is it? because it was a way to get the informaiton about ndpoints to the user | 21:37 |
nkinder | gyee: yeah, I'm thinking that the catalog can be looked up | 21:37 |
gyee | nkinder, totally, LDAP is made for that stuff | 21:38 |
gyee | highly static and fast lookup | 21:38 |
nkinder | gyee: well, LDAP or something else really | 21:38 |
topol | morganfainberg, the catalog as become that no good brother in law that has outstayed his welcome at your house | 21:38 |
nkinder | gyee: people aren't going to want to use AD to store their endpoints for example | 21:38 |
gyee | nkinder, zookeeper idea have been bounced around before | 21:38 |
morganfainberg | gyee, i was thinking when you auth you get X-CATALOG header. and a service that will lookup the endpoints based upon a token, we can then just put IDs for the catalog in the token itself | 21:38 |
gyee | just didn't have a chance to follow up on it | 21:38 |
topol | gyee everone hates zookeeper | 21:38 |
gyee | topol, why? | 21:39 |
topol | gyee aint it java | 21:39 |
morganfainberg | gyee, X-CATALOG would just be so we don't "break" everyone at once (or force extra roundtrips to keystone) | 21:39 |
morganfainberg | topol, there is some love, hate, hate, and more hate around zookeeper i thnk | 21:39 |
nkinder | morganfainberg: yeah, something like that would be ideal IMHO | 21:39 |
gyee | java is a language, why hate a language? | 21:39 |
gyee | language is just a tool | 21:39 |
topol | morganfainberg ++++ | 21:39 |
topol | gyee, you dont need to convert me sir | 21:39 |
dstanek | sorry...just catching up | 21:40 |
topol | gyee, I have just been to that rodeo before | 21:40 |
morganfainberg | nkinder, it also doesn't help us that our catalog backend is sub-wonderful anyway. | 21:40 |
morganfainberg | nkinder it's not awful | 21:40 |
morganfainberg | nkinder just could be a lot better | 21:40 |
dstanek | if they happens then a cloud is just too big to put their catalog in the token | 21:40 |
gyee | s/tool/weapon/ | 21:40 |
dstanek | gyee: yes, Java is a tool | 21:40 |
morganfainberg | dstanek, and it is happening in grenade for icehouse, meaning it doesn't take a big cloud to hit the limit | 21:40 |
nkinder | dstanek: that's how I read it too :) | 21:40 |
gyee | I used whatever I can get my hands on :) | 21:41 |
topol | morganfainberg, what made this worse than beofre? | 21:41 |
bknudson | we keep getting more services in the catalog | 21:41 |
bknudson | e.g., heat, etc | 21:41 |
gyee | bknudson, you bet, think outside of IaaS | 21:41 |
gyee | we should have a truck load of *aaS in the catalog | 21:42 |
dstanek | how hard would it be to remove the token from the catalog in the grenade tests? | 21:42 |
morganfainberg | topol, apparently moving to trusty made it worse this (so some extra distro dependent stuff) but it's just a symptom of the ever increasing number of services | 21:42 |
nkinder | morganfainberg: the catalog backend can be improved, but the immediate problem is the token size. Is it "good enough" for now? | 21:42 |
morganfainberg | nkinder, well i think bad data format has lent to this being a bigger problem | 21:42 |
morganfainberg | nkinder, but same net result | 21:42 |
morganfainberg | nkinder s/backend/format for catalog/ | 21:43 |
morganfainberg | sorry | 21:43 |
morganfainberg | dstanek, unlikely to be doable. much easier to flip back to UUID tokens | 21:43 |
bknudson | so how does the X-OS-CATALOG header work? | 21:43 |
morganfainberg | bknudson, i think this is a single header response issue | 21:44 |
*** gokrokve_ has quit IRC | 21:44 | |
bknudson | it seems like anything we do isn't going to be backwards compat so we're stuck with UUID | 21:44 |
morganfainberg | bknudson, yeah. | 21:44 |
*** gokrokve has joined #openstack-keystone | 21:44 | |
morganfainberg | well. we might be able to backport PKIZ to lighten the load for i | 21:44 |
morganfainberg | but that might just be head-in-sand | 21:44 |
gyee | nkinder, thanks for putting the crypto inventory wiki, saved my life today when I have to fill out that export form | 21:44 |
bknudson | from what I've seen PKIZ tokens are 50% the size | 21:45 |
bknudson | so they're going to fail at some point anyways | 21:45 |
nkinder | yeah, PKIZ is a stop-gap | 21:45 |
morganfainberg | bknudson, correct, for J we need to really solve this | 21:45 |
morganfainberg | but we could try and go PKIZ for Icehouse as the stop-gap | 21:45 |
bknudson | I don't have a problem with backporting PKIZ | 21:45 |
bknudson | Horizon had an issue with them | 21:46 |
morganfainberg | plus documentation that if we hit X size, sorry you need to use UUID. | 21:46 |
nkinder | gyee: awesome, glad it helped! | 21:46 |
morganfainberg | bknudson, then focus on getting the catalog out of the token in J, so we don't need the stop-gap solution | 21:47 |
dstanek | morganfainberg: is that just a client side issue? | 21:47 |
morganfainberg | dstanek, hm? | 21:47 |
topol | gyee+++ great job nkinderon the crypto inventory | 21:47 |
dstanek | morganfainberg: to fetch the catalog separate from token | 21:47 |
topol | nkinder, you coming to the hackathon? | 21:47 |
gyee | yeah, otherwise, I would have to scan the code to get the form done | 21:48 |
morganfainberg | dstanek, yeah we'd need to push it to the client. | 21:48 |
gyee | why is it alway the french that care about the crypto stuff | 21:48 |
morganfainberg | dstanek, well, any client really. | 21:48 |
gyee | always | 21:48 |
nkinder | topol: can't, I'm taking my family on a vacation | 21:48 |
*** gokrokve_ has joined #openstack-keystone | 21:48 | |
topol | nkinder, good for you. hope you go somewhere fun | 21:48 |
morganfainberg | topol, see nkinder likes his family more than us. got his priorities straight! :) | 21:48 |
nkinder | topol: annual camping trip, no computers :) | 21:49 |
*** gokrokve has quit IRC | 21:49 | |
topol | nkinder, working showers and bathrooms or bring a shovel and dig a hole? | 21:49 |
nkinder | the lure of BBQ in TX was very tempting though | 21:49 |
topol | nkinder TX BBQ is awesome | 21:49 |
nkinder | topol: bathrooms, but no showers (but there is a lake, which counts... right?) | 21:50 |
morganfainberg | bknudson, i think backporting PKIZ is a requirements update, the new provider, and 3 lines of runtime code, and the tests | 21:50 |
topol | nkinder, I sooo hate camping. better you than me | 21:50 |
morganfainberg | bknudson, should be easy. | 21:50 |
topol | morganfainberg, I rmember that patch. i think you are right | 21:50 |
nkinder | morganfainberg: if we pull the catalog out of tokens, how much outside of keystone needs to change? | 21:51 |
bknudson | morganfainberg: it's not a big change it's just not the type that's usually backported | 21:51 |
topol | morganfainberg would buy us some time to get it fixed right | 21:51 |
morganfainberg | bknudson, yeah i know :( | 21:51 |
bknudson | and when we know that UUID works then that seems like the safer option | 21:51 |
morganfainberg | nkinder, keystone, probably not a lot, but a lot of things assume the catalog is in the token | 21:51 |
morganfainberg | nkinder, a lot of things. | 21:52 |
gyee | nkinder, keystoneclient discovery logic definitely will need to be updated as it pull the endpoint off the catalog | 21:52 |
bknudson | maybe we can have a pki test that has a smaller catalog | 21:52 |
morganfainberg | bknudson, for I i'm find backporting a 'default this to uuid instead' fix | 21:52 |
gyee | nova-glance also depended on the catalog | 21:52 |
*** gokrokve_ has quit IRC | 21:52 | |
topol | bknudson, how big a performance hit for folks if they go back to UUID? | 21:52 |
*** gokrokve has joined #openstack-keystone | 21:52 | |
gyee | I think nova looks up the glance endpoint for the image stuff | 21:53 |
gyee | glance may even need swift endpoints if it stores the image into swift | 21:53 |
nkinder | gyee: does it use keystoneclient for that though? | 21:53 |
bknudson | topol: the performance depends on a lot of variables so I couldn't say.... latency of the network, etc. | 21:53 |
morganfainberg | topol, in a high-token volume environment (lots of token issuance) it's really rough | 21:54 |
gyee | nkinder, I don't think so | 21:54 |
topol | does anyone remember when we switcthed to PKI anyone saying, wow this is a huge improvement for me. THANKS | 21:54 |
topol | cause with PKI you had the hit of doing the signing as a separate process (not cheap) | 21:54 |
bknudson | and fetching the revocation list | 21:55 |
*** ayoung-dadmode is now known as ayoung | 21:56 | |
gyee | the openssl part can be improved, like using m2crypto or something | 21:56 |
gyee | revocation list can be eliminated with short-lived tokens | 21:56 |
morganfainberg | bknudson, the cheapest fix for this is going back to UUID for icehouse | 21:56 |
topol | short lived tokens my have other bad side efects if they werent expected | 21:57 |
morganfainberg | and discussing what we're going to do about Juno | 21:57 |
topol | morganfainberg, I thnk you are right. And then comes accepting the fact as clouds get bigger putting catalog in the token doesnt scale | 21:57 |
ayoung | morganfainberg, backport PKIZ will break horizon | 21:57 |
morganfainberg | ayoung, then the only answer is reverting back to UUID tokens for icehouse | 21:58 |
ayoung | but we could backport that as well | 21:58 |
gyee | topol, I worked on WPKI (wireless PKI) in one of my previous lifes, WPKI essentially uses short-lived certs to eliminated the need for CRL | 21:58 |
ayoung | django-auth-openstack | 21:58 |
topol | ayoung and morganfainberg making good arguments during this time of crisis :-) | 21:58 |
*** marcoemorais has quit IRC | 21:58 | |
*** david-lyle has quit IRC | 21:59 | |
*** marcoemorais has joined #openstack-keystone | 21:59 | |
*** marcoemorais has quit IRC | 21:59 | |
gyee | it all comes to to risk management | 21:59 |
morganfainberg | ayoung, it's probably safer to use UUID tbh | 21:59 |
ayoung | topol, big catalogs are the problem | 21:59 |
gyee | comes down to | 21:59 |
topol | ayoung, I agree | 21:59 |
*** marcoemorais has joined #openstack-keystone | 21:59 | |
*** david-lyle has joined #openstack-keystone | 21:59 | |
topol | but wont they get bigger over time? | 21:59 |
topol | ayoung/ | 21:59 |
morganfainberg | ayoung, topol, and the catalogs aren'tgoing to get smaller | 21:59 |
topol | morganfainberg+++ | 22:00 |
morganfainberg | topol, over a short timeframe, let alone long. | 22:00 |
ayoung | lets just drop the catalog from the token unless explicitly requested. What will it break? | 22:00 |
ayoung | have like, just nova in there or something | 22:00 |
morganfainberg | ayoung, nova, glance, uhm horizon | 22:00 |
topol | ayoung, interesting idea. bare minimum catalog | 22:00 |
nkinder | yeah, a default filter | 22:00 |
topol | ayoung, primary and secondary serrvices | 22:01 |
*** dims__ has quit IRC | 22:01 | |
ayoung | morganfainberg, nah, don't need horizon. And I don't think nova actually uses the info to select glance or neutron | 22:01 |
dstanek | so dumb question - what is the difference between using UUID tokens and using PKI tokens without the catalog? | 22:01 |
topol | ayoung, make it configurable? | 22:01 |
ayoung | all we really need is to know "where do I go to do something" | 22:01 |
topol | ayoung, filter mask? | 22:01 |
ayoung | topol, nah, the problem is all of the clients. | 22:01 |
ayoung | they all need the service catalog in the token | 22:01 |
bknudson | we could switch to returning a token hash if the PKI token gets too big | 22:01 |
ayoung | and they won't know to say "I need a token for glance" | 22:01 |
topol | ayoung, the whole catalog? | 22:01 |
*** lbragstad has quit IRC | 22:02 | |
ayoung | no, glance client needs the glance service only | 22:02 |
topol | bknudson, that sounds good | 22:02 |
nkinder | dstanek: essentially just the way the token is validated | 22:02 |
bknudson | I think it would be backwards compat (to return a hash) | 22:02 |
ayoung | bknudson, yep | 22:02 |
nkinder | dstanek: and the ability to eventually drop tokens from the database on the keystone side of things | 22:03 |
ayoung | "continued in next token" | 22:03 |
*** elmiko is now known as _elmiko | 22:03 | |
*** david-lyle has quit IRC | 22:03 | |
bknudson | dstanek: you get a catalog back in the token response for UUID or PKI tokens. | 22:04 |
morganfainberg | ok so. fix for icehouse, UUID. work on dropping catalog for juno? | 22:04 |
bknudson | morganfainberg: what do you think about change keystone PKI to return hash if the token is too big? | 22:04 |
dstanek | bknudson: in UUID it's not a header right? | 22:04 |
nkinder | bknudson: I've been tossing that idea around as well | 22:05 |
nkinder | truncating or dropping the catalog it it's over 8k | 22:05 |
bknudson | dstanek: no, we don't have any catalog in the header | 22:05 |
morganfainberg | bknudson, still requires token persistence. | 22:05 |
morganfainberg | so we can't drop persisting tokens ever. | 22:05 |
bknudson | morganfainberg: sure, but that would be a different provider? | 22:05 |
morganfainberg | bknudson, oh you mean in the PKI / PKIZ provider? | 22:05 |
bknudson | morganfainberg: I'm mentioning this as another kind of stopgap | 22:06 |
bknudson | wasn't saying to forget about figuring out how to get the catalog out of the token | 22:06 |
morganfainberg | bknudson, hm. maybe. though i think it would be less complex to always return the hash | 22:06 |
dstanek | i feel like i'm missing something about removing the catalog from the token then...if it's not there we can just include it in the body and clients can still continue to work...right? | 22:06 |
morganfainberg | or use uuid | 22:06 |
ayoung | wouldn't be the provider | 22:06 |
ayoung | it would be in the controller | 22:06 |
ayoung | dstanek, hmmm, yea | 22:06 |
*** joesavak has joined #openstack-keystone | 22:06 | |
ayoung | clients would be fine | 22:07 |
bknudson | dstanek: I think you're mostly right... it's auth_token that would be missing the catalog | 22:07 |
ayoung | you might be right, it might be that no one needs it | 22:07 |
bknudson | and it's not hard to change auth_token | 22:07 |
bknudson | clients could supposedly take the token response and generate their own pki from it. | 22:07 |
bknudson | but I doubt anyone would be doing that | 22:08 |
*** kevinbenton has joined #openstack-keystone | 22:08 | |
ayoung | there is an option to drop the catalog from the token. Can we default that to on and try the CI? | 22:08 |
bknudson | ayoung: in auth_token | 22:09 |
bknudson | ? | 22:09 |
ayoung | bknudson, no in keystone | 22:10 |
*** cuddyt has quit IRC | 22:10 | |
bknudson | ayoung: you mean there's an existing config option for that? | 22:11 |
morganfainberg | ayoung, it's a query string. | 22:11 |
morganfainberg | ayoung not a global. | 22:11 |
nkinder | ayoung: you mean ?nocatalog | 22:11 |
bknudson | http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n303 | 22:12 |
bknudson | There's an option in auth_token | 22:12 |
kevinbenton | is there a way to permission a user to just be able to list tenants and tenant names? | 22:12 |
kevinbenton | it seems in the v2 api I need to set the tenantName to ‘admin’ | 22:13 |
bknudson | so if we remove the catalog from the PKI token, auth_token can't set X-Service-Catalog. | 22:13 |
bknudson | unless it can get the catalog for the token some other way | 22:13 |
bknudson | I wonder if anyone even uses it | 22:13 |
morganfainberg | bknudson, though x-service-catalog might overrun the limit to now that i think about it | 22:14 |
bknudson | (X-Service-Catalog) | 22:14 |
*** daneyon has joined #openstack-keystone | 22:14 | |
ayoung | I thought there was | 22:14 |
ayoung | yeah ?nocatalog | 22:14 |
*** topol has quit IRC | 22:14 | |
bknudson | morganfainberg: there's a limit to how much can be passed along the paste pipeline? | 22:14 |
morganfainberg | bknudson, the issue is the response from eventlet. | 22:14 |
morganfainberg | bknudson, responding to posts on /auth/ | 22:15 |
bknudson | morganfainberg: oh, this isn't even the server accepting a request with large header? | 22:15 |
bknudson | now it's generating the response? weird. | 22:15 |
morganfainberg | bknudson, basically we accept the request for a token, and then keystone stacktraces trying to send the response | 22:16 |
morganfainberg | in eventlet | 22:16 |
morganfainberg | the issue is when we issue the token, not even getting to middleware | 22:16 |
dstanek | morganfainberg: is that what the 'broken pipes' are? | 22:16 |
morganfainberg | dstanek, thats what it looks like in this case. | 22:16 |
bknudson | broken pipes and crap goes everywhere | 22:17 |
dstanek | morganfainberg: how do you know that it has to do with token size? | 22:17 |
bknudson | been there | 22:17 |
morganfainberg | dstanek, or the requsts lib is dropping the connection | 22:17 |
morganfainberg | or any number of things. | 22:17 |
ayoung | include_catalog = 'nocatalog' not in context['query_string'] | 22:17 |
ayoung | so instead we would do | 22:17 |
morganfainberg | dstanek, i've seen similar issues before on this. and it seems to be specific to posts to /auth/token | 22:17 |
ayoung | include_catalog = 'includecatalog' in context['query_string'] | 22:18 |
ayoung | let me see what breaks | 22:18 |
morganfainberg | bknudson, please correct me if i'm wrong, but i _think_ that was the issue we had earlier on | 22:18 |
bknudson | morganfainberg: I don't think I've heard of the server failing to respond because the header is too big. | 22:19 |
morganfainberg | bknudson, hm. | 22:19 |
dstanek | morganfainberg: so when i've seen broken pipe issues in the paste they were caused by the Python process seg faulting | 22:19 |
dstanek | morganfainberg: is that what's happening? | 22:20 |
bknudson | but I know there's problems with other servers accepting the monster header | 22:20 |
morganfainberg | bknudson, might be hitting the out-bound limit, iirc apache has one of those as well | 22:20 |
bknudson | it wouldn't surprise me if apache even changed which causes it to fail more now | 22:20 |
morganfainberg | hmm. | 22:23 |
morganfainberg | bknudson, dstanek, blah | 22:24 |
morganfainberg | we don't trap broken pipe in our eventlet code | 22:24 |
morganfainberg | we actually should be ignoring it. | 22:24 |
* morganfainberg is digging in further | 22:24 | |
morganfainberg | i _think_ the client side might be overwhelemed with data | 22:24 |
morganfainberg | (still could be token size) | 22:24 |
bknudson | SIGPIPE | 22:24 |
morganfainberg | requests lib or some such | 22:25 |
*** dims__ has joined #openstack-keystone | 22:25 | |
dstanek | it's possible that the client is overloaded, but i would doubt it | 22:25 |
dstanek | i've used requests to pull lots of data in the past - not really big header though | 22:26 |
morganfainberg | dstanek, yeah there is weird stuff around headers | 22:26 |
morganfainberg | dstanek, the more i look at HTTP | 22:26 |
morganfainberg | :P | 22:26 |
bknudson | some POST /v3/auth/tokens work in that log, and some are failing with the broken pipe | 22:27 |
ayoung | lets just yank the catalog out of the tokens | 22:27 |
ayoung | what is the worst that can happen? | 22:27 |
bknudson | seems like we don't need to log a traceback for the pipe error | 22:27 |
bknudson | although maybe that's in eventlet and we have no control over it | 22:28 |
morganfainberg | this is client hanging up | 22:28 |
morganfainberg | for sue | 22:28 |
morganfainberg | for sure* | 22:28 |
morganfainberg | but not sure why the client keeps hanging up on this post | 22:29 |
bknudson | memory corruption | 22:30 |
morganfainberg | maybe | 22:30 |
bknudson | this is why we should use java | 22:31 |
morganfainberg | lol | 22:31 |
*** openstackgerrit has quit IRC | 22:35 | |
*** openstackgerrit has joined #openstack-keystone | 22:36 | |
morganfainberg | bknudson, i don't know how to catch this exception :( | 22:38 |
bknudson | it's a potential DOS, just start a request and segfault and you'll fill the logs | 22:38 |
morganfainberg | yarp | 22:40 |
dstanek | morganfainberg: you just have to supply a subclass of eventlet.wsgi.HTTPProtocol to the eventlet.wsgi.Server when creating it | 22:41 |
morganfainberg | dstanek, really? | 22:42 |
morganfainberg | dstanek, eh could be worse. | 22:42 |
dstanek | morganfainberg: wait until you see how you'd have to do it :-P | 22:42 |
morganfainberg | dstanek, it's going to make me cry... isn't it? | 22:42 |
dstanek | instead of copying and hacking handle_one_response you may just want to filter the log | 22:44 |
dstanek | suppressing the messages will stop a DOS on the log, but nothing else | 22:44 |
dstanek | is that what we care about here? | 22:44 |
morganfainberg | dstanek, well i'm curious what is causing the issue | 22:45 |
morganfainberg | we could also just smush log.INFO down for eventlet | 22:45 |
morganfainberg | do we _care_ about info? | 22:45 |
*** serverascode has quit IRC | 22:47 | |
kevinbenton | hi, i see that get_all_projects in the v2 API has an assert_admin call (https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L40) so a user can’t be allowed to list tenants via a policy.json change without making them a full admin | 22:48 |
morganfainberg | dstanek, i'm going to standup a keystone with a massive service catalog (50 endpoints) and see if there is something bedise the client being dumb | 22:48 |
kevinbenton | is this same limitation present in the v3 api? | 22:48 |
morganfainberg | kevinbenton, you can do different limiting wiht policy (full RBAC) in v3 | 22:48 |
morganfainberg | kevinbenton, v2 doesn't support more than 'is admin' or 'is not admin' | 22:49 |
kevinbenton | morganfainberg: how is this policy expressed. Is it configurable via the keystone CLI? | 22:50 |
nkinder | kevinbenton: I think what you want is shown in the policy.v3cloudsample.json file | 22:50 |
morganfainberg | nkinder, ++ | 22:50 |
*** serverascode has joined #openstack-keystone | 22:51 | |
dstanek | morganfainberg: i can't get requests to break even with really big headers | 22:51 |
kevinbenton | nkinder: oh okay, so this is the same format as existing policy.json | 22:51 |
kevinbenton | :q | 22:52 |
dstanek | morganfainberg: can this just be networking issues between the keystone instance and the client? | 22:52 |
morganfainberg | dstanek, in a devstack? | 22:52 |
kevinbenton | morganfainberg, nkinder: thanks. now I just need to update my code to use the v3 api :-) | 22:52 |
dstanek | morganfainberg: oh, hmmm. i thought this was in a real env | 22:53 |
morganfainberg | dstanek, nope, this is happening in grenade | 22:53 |
dstanek | morganfainberg: ha, found the header size limit in requests - http://dpaste.com/08XXQW2 | 22:56 |
morganfainberg | 65k? | 22:56 |
morganfainberg | god i hope we're not over 65k :P | 22:57 |
dstanek | requests is doing something funny, but it works file with headers 2**15 | 23:01 |
dstanek | morganfainberg: off to dinner - my test server http://dpaste.com/3HBRSD1 - my test client http://dpaste.com/2N3F567 | 23:04 |
*** marcoemorais has quit IRC | 23:06 | |
*** marcoemorais has joined #openstack-keystone | 23:06 | |
*** marcoemorais has quit IRC | 23:06 | |
*** marcoemorais has joined #openstack-keystone | 23:07 | |
ayoung | morganfainberg, ah, no we can't just drop the catalog. The body of the token is what is returned, so nocatalog drops it out of the body as well | 23:09 |
*** diegows has quit IRC | 23:10 | |
nkinder | ayoung: I think we need to look at what it will take to get the catalog out of tokens though | 23:11 |
ayoung | nkinder, two sides: changing keystone is easy | 23:12 |
nkinder | to me, it doesn't really belong there since it has nothing to do with authorization | 23:12 |
ayoung | making sure nothing need the body is a little harder | 23:12 |
nkinder | ayoung: yeah, I know the other side will be the difficult one here | 23:12 |
dstanek | nkinder: ++ | 23:12 |
ayoung | nkinder, might not be | 23:12 |
dstanek | no more catalog! | 23:12 |
ayoung | auth_token is the point of contact for that | 23:12 |
dstanek | i'm skeptical that this issue is related to header size | 23:12 |
nkinder | a token is for authorization, so roles belong there. Endpoints really have nothing to do with authorization. | 23:12 |
nkinder | dstanek: yeah, I'm not sure either *but* we know token size is causing issues for using mod_wsgi | 23:13 |
dstanek | agreed. | 23:13 |
nkinder | ...and using mod_wsgi is important for the approach of using apache modules to add stronger authentication mechanisms | 23:13 |
dstanek | for this issue i wonder if the server's OOM killer is killing off clients | 23:14 |
ayoung | nkinder, endpoint binding should be in the token | 23:16 |
ayoung | but that doesn't mean the whole catalog should be there | 23:17 |
*** daneyon has quit IRC | 23:17 | |
ayoung | God I feel like we are building this thing by trial and error, from crisis to crisis | 23:17 |
nkinder | ayoung: but my point is that the endpoint info in the token is not used for enforcement | 23:18 |
ayoung | nkinder, agreed. It should be if it is there, and only enforcement info should be there | 23:18 |
ayoung | I wonder if HEAT or Nova are going to have an issue with the token missing the catalog | 23:18 |
ayoung | self.token_provider_api.issue_v3_token( returns id, token_data | 23:20 |
nkinder | ayoung: how is the token data extracted/parsed from the token? Wouldn't that all be handled in keystone/keystoneclient code? | 23:21 |
*** rodrigods_ has joined #openstack-keystone | 23:21 | |
ayoung | nkinder, its a signed JSON document. CMS validates the signed docuemnt and returns the JSON | 23:22 |
morganfainberg | dstanek, i think you're right this isn't a token issue. | 23:22 |
morganfainberg | dstanek, hitting another limit with the token SQL table before eventlet craps out | 23:22 |
ayoung | http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/common/cms.py#n120 | 23:23 |
nkinder | ayoung: ok, so we just return the token body as a result of the validation on the client side | 23:23 |
ayoung | yep | 23:23 |
ayoung | so long as we sign the right data | 23:23 |
morganfainberg | dstanek, http://dpaste.com/1J500KX | 23:23 |
morganfainberg | reaching towards the upper limit on the token size | 23:23 |
ayoung | 14085 | 23:27 |
morganfainberg | ayoung, i could get more in there but the token table craps out | 23:28 |
*** oomichi has joined #openstack-keystone | 23:30 | |
dstanek | 14084 right? | 23:33 |
morganfainberg | at 65k of total token data we tip over | 23:35 |
nkinder | morganfainberg: yet another reason for ephemeral/non-persisted tokens ;) | 23:37 |
morganfainberg | nkinder, yep | 23:38 |
dstanek | morganfainberg: just tested eventlet with a 64536 byte header and it went ok there | 23:40 |
morganfainberg | dstanek, yeah | 23:40 |
morganfainberg | dstanek, i'm convinced it's the client being dumb | 23:40 |
morganfainberg | meaning... | 23:40 |
morganfainberg | :( | 23:40 |
morganfainberg | we need to make eventlet not spam the log in this case. | 23:41 |
mgagne | Can someone explain in clear terms how revocation events work? Is a database or bus involved? How are the other services using the middleware consuming those events? it isn't clear from the blueprint I read | 23:41 |
dstanek | morganfainberg: did you see my comment about OOM? | 23:41 |
morganfainberg | dstanek, no. | 23:41 |
dstanek | for this issue i wonder if the server's OOM killer is killing off clients | 23:41 |
morganfainberg | dstanek, might be | 23:41 |
morganfainberg | mgagne, the revocation events are held in the keystone DB. the middleware polls for them (the same as it does for the revocation list in icehouse and earlier). | 23:42 |
morganfainberg | mgagne, eventually there will also be notifications for new events. but in the case a notification is missed, the client will still poll keystone on a fixed interval to make sure it's internal-list is up to date | 23:42 |
morganfainberg | mgagne, and on startup, a client will need to retrieve the complete list from keystone. | 23:43 |
morganfainberg | dstanek, we should get dmesg in the devstack log output | 23:43 |
mgagne | morganfainberg: right. how is this different from the actual revocation list already used with PKI/CRL? | 23:43 |
morganfainberg | mgagne, the revoction event is based upon information in the token, e.g. user_id | 23:43 |
morganfainberg | mgagne, so you cna match every token belonging to a user with one event | 23:43 |
mgagne | morganfainberg: so it's agnostic of the token format? | 23:43 |
morganfainberg | mgagne, the token revocation list is revoke by token id, so if a user had 1000000 tokens, that many tokens must be added to the list to revoke all of the user's active tokens | 23:44 |
mgagne | morganfainberg: so it's about moving from a revoked token list to a revokcation list based on user/project id instead | 23:44 |
mgagne | morganfainberg: alright | 23:44 |
morganfainberg | mgagne, it needs to know the token format, but it just allows for a more scalable way of revoking mass number of tokens. it also means we don't need to store the token in a persistent store (e.g. sql) | 23:44 |
morganfainberg | mgagne, based upon any element we want to support in the token, or combination of elements(e.g. user_id/domain_id, just user_id, trust_id, project_id, group_id, etc) | 23:45 |
mgagne | morganfainberg: much clearer now, the term "event" is kind of misleading for an outsider/operator as it is often associated with the use of a messaging queue | 23:45 |
morganfainberg | mgagne, the reason it's called an event is because it occurs at a fixed time, e.g. jun 9th 2014 at 1040, any token issued before ' jun 9th 2014 at 1040' would be invalidated by the event | 23:46 |
mgagne | morganfainberg: and I was wondering who had the great idea to require a bus, especially with a global keystone which could be deployed across the world =) | 23:47 |
mgagne | morganfainberg: makes sense now thanks for the info | 23:47 |
morganfainberg | mgagne, it absolutely should also emit notifications on a bus for events, but by no means should that be the only way | 23:47 |
morganfainberg | dstanek, ok so i think quick and dirty... we handle EPIPE issues | 23:47 |
morganfainberg | dstanek, and back port that to Icehouse *cries a little* | 23:48 |
morganfainberg | if there are OOM issues we have to say "uhh" | 23:48 |
*** r-daneel has joined #openstack-keystone | 23:48 | |
morganfainberg | i'll see if we can get a dmesg dump in gate as well. | 23:48 |
*** r-daneel has quit IRC | 23:52 | |
morganfainberg | dstanek, not OOMkiller | 23:53 |
morganfainberg | looked at syslog and kern log | 23:53 |
dstanek | hmm...any way to know which client so we can see if it has anything in its logs? | 23:56 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: V3 Extensions https://review.openstack.org/95389 | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!