Wednesday, 2014-06-25

*** harlowja has quit IRC00:00
*** daneyon has quit IRC00:02
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session Adapters  https://review.openstack.org/8623700:03
dstanekjamielennox: howdy00:04
jamielennoxdstanek: you can't do anything quietly with those notifications00:04
dstanekjamielennox: ?00:04
jamielennoxdstanek: nothing - what's up?00:05
dstanekjamielennox: :-) just wanted to let you know that i'm making a few changes to https://review.openstack.org/#/c/101792/00:05
jamielennoxdstanek: 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 ok00:06
dstanekjamielennox: i added some tests and comments on _redact - haven't done much more than that00:06
jamielennoxdstanek: 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 _redact00:09
morganfainberg_Ljamielennox: middleware! Yay!00:10
jamielennoxmorganfainberg_L: nice00:11
jamielennoxwhen do we promote it as ready?00:11
jamielennoxi've been trying to think about what i want to change compatibility wise00:11
openstackgerritA change was merged to openstack/python-keystoneclient: Unversioned endpoints in service catalog  https://review.openstack.org/7459900:12
jamielennoxand 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 behaviour00:12
jamielennoxyes! ^00:12
morganfainbergjamielennox, well we have some gate work to do before we release00:13
morganfainbergjamielennox, but ASAP we should release00:13
jamielennoxmorganfainberg: i would like to get the whole auth plugin from config file thing to be used by the new plugin00:13
morganfainberg_Ljamielennox: so..00:13
jamielennoxnew middleware00:13
morganfainberg_Lwe discussed this today00:13
jamielennoxit shouldn't be backwards incompatible though00:13
jamielennoxdamnit - the one meeting i miss...00:13
morganfainberg_Lhow ... awful would it be to split session and cms out?00:13
morganfainberg_Lbascially keystonelib becomes the common lib things00:14
jamielennoxmorganfainberg_L: it would be great - i don't think they belong in the same repo though00:14
morganfainberg_Land ksc really is the _client_00:14
dstanekjamielennox: ah, then i won't push this change00:14
jamielennoxdstanek: no, you should push it - i haven't attempted anything in that regard00:14
jamielennoxsession is very common to everyone, same as the base auth plugin classes00:15
dstanekjamielennox: if _redacted goes away the change is useless, but i can push anyway00:15
morganfainberg_Ljamielennox: so you don't think CMS and session should be in a common lib repo?00:15
jamielennoxdstanek: i'm happy to leave redacted - it just came up in a comment00:15
jamielennoxmorganfainberg_L: what's common about CMS that is needed beyond ksc?00:15
morganfainberg_Lkeystone, and middleware both need it00:16
morganfainberg_Land anyone looking to validate a token might want it00:16
morganfainberg_Le.g. session00:16
*** bknudson has joined #openstack-keystone00:17
jamielennoxsession shouldn't, middleware should rely on ksc right?00:17
jamielennoxalthough - i can see why it might00:17
morganfainberg_Lwell my thought was middleware ends up relying on [common]00:17
jamielennoxi haven't needed that yet00:17
morganfainberg_L[ksc] relies on common00:17
morganfainberg_L[keystone] relies on common00:17
morganfainberg_L[*client] relies on common00:18
jamielennoxmorganfainberg_L: i'd really like to move a lot of middleware into ksc00:18
*** marcoemorais has quit IRC00:18
jamielennoxthe whole what is this token should be in ksc00:18
jamielennoxbecause it *is* a keystone concern00:18
*** marcoemorais has joined #openstack-keystone00:18
morganfainberg_Lso KSC is _just_ the client bits, common would be the other parts we share among middleware, keystone, other clients00:18
morganfainberg_L*shurg*00:19
*** ncoghlan has joined #openstack-keystone00:19
morganfainberg_Lnot sure if it is worth the effort at the moment to split things further. as it stands middleware will rely/doesrely on ksc00:19
*** marcoemorais has quit IRC00:19
jamielennoxmorganfainberg_L: so you are talking about keystonecommon then?00:19
*** marcoemorais has joined #openstack-keystone00:19
*** daneyon has joined #openstack-keystone00:20
jamielennoxbecause i'm considering session like a clientcommon00:20
morganfainberg_Lyeah we discussed if it made sense tosplit out all the keystone common stuff (well in this case client common) into it's own project00:20
jamielennoxso session belongs to clientcommon because it's relevant to everyone, if we need keystonecommon to make the middleware split work then that's ok00:21
morganfainberg_Lonly thing there would be cms00:21
jamielennoxbut i don't think that CMS belongs to a clientcommon00:21
morganfainberg_Land we don't _need_ to split cms out00:21
morganfainberg_Lbut 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_Lespecially if session is in a separate project as well00:22
jamielennoxmorganfainberg_L: i want to avoid the relationship that session is a keystone thing00:23
jamielennoxthe identity plugins are and they could potentially be keystonecommon rather than keystoneclient00:23
jamielennoxmorganfainberg_L: also i made the doc change you wanted to https://review.openstack.org/#/c/86237/ if you can have anothre quick look00:24
morganfainberg_Ljamielennox: ++00:24
*** bknudson has left #openstack-keystone00:25
*** praneshp has quit IRC00:25
* jamielennox is going to make people look at/approve client patches00:25
morganfainberg_Ljamielennox: well if you want help splitting things from the repo, let me know. I've got a good handle on what it takes00:25
jamielennoxmorganfainberg_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 dependancy00:26
morganfainberg_Lright00:26
jamielennoxespecially given that the CLIs are all part of the client repos00:26
jamielennoxalso i'm still doing a lot of changes to it00:26
jamielennoxbut yea, i'm up to split it out whenever it makes sense00:26
morganfainberg_Ljamielennox: 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 now00:27
jamielennoxman the apiclient oslo guys are going to hate this :)00:28
morganfainberg_LLOL00:28
morganfainberg_Lwould session go under oslo then? or would you keep it under identity?00:29
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add invalidate doc string to identity plugin  https://review.openstack.org/9955800:30
jamielennoxgod no for oslo00:30
jamielennoxsession is common for everyone00:30
morganfainberg_Li meant make it oslo.session out the gate00:30
morganfainberg_Lnot incubator00:30
jamielennoxit's not an identity concept, there is a base plugin class that will work for any authentication type which is common for everyone00:30
morganfainberg_Lor you mean it's something that is more widely usable in the python community00:30
jamielennoxthen there are identity plugins that live within the identity space00:31
jamielennoxumm, i don't think it's useful for wider python00:31
jamielennoxit's fairly specific to how openstack does things like catalog lookups00:31
morganfainberg_Lwell in either case let me know00:31
*** lbragstad has quit IRC00:31
morganfainberg_Li'm totally happy to help split it out for you.00:32
jamielennoxyea, it's probably an oslo concept00:33
morganfainberg_L+2 on adapter00:33
jamielennoxexcellent00:34
*** bknudson has joined #openstack-keystone00:34
jamielennoxthanks for the review of the CONF stuff as well00:35
morganfainberg_Ljamielennox: 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, etc00:36
jamielennoxmorganfainberg_L: session shouldn't be too hard i think because you would still have keystoneclient relying on the oslo.clientcommon00:36
jamielennoxso you would just provide the class links00:37
morganfainberg_Lright. but still need to do releases for updates00:37
morganfainberg_Lso, lets get conf stuff in, adapters and anything else in flight00:37
morganfainberg_Lthen look at splitting00:37
morganfainberg_L?00:37
jamielennoxmorganfainberg_L: sounds good00:37
jamielennoxi'm hoping to push that quickly00:38
morganfainberg_Lsay, target start of J3 for the split if we're going to do it00:38
morganfainberg_Le.g. make the call then00:38
morganfainberg_Lso packagers have time to roll everything up nicely00:38
jamielennoxso 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 then00:38
jamielennoxso that should be good00:38
morganfainberg_Lugh we need to get specs updated/approved00:39
morganfainberg_Lthis is going to be an empty keystone release if we don't00:40
* morganfainberg_L goes and gets dinner00:41
openstackgerritBrant Knudson proposed a change to openstack/keystonemiddleware: auth_token cached token handling  https://review.openstack.org/10239900:42
jamielennoxmorganfainberg_L: i've got like one patch into keystone since the summit i think00:42
openstackgerritBrant Knudson proposed a change to openstack/keystonemiddleware: Refactor auth_token, move identity server members to class  https://review.openstack.org/10240200:48
openstackgerritBrant Knudson proposed a change to openstack/keystonemiddleware: Refactor auth_token revocation list members to new class  https://review.openstack.org/10240300:48
*** dstanek is now known as dstanek_zzz00:48
*** daneyon has quit IRC00:49
*** morganfainberg is now known as morganfainberg_Z00:57
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: V3 extension advertisement  https://review.openstack.org/9597300:57
*** dstanek_zzz is now known as dstanek01:04
*** praneshp has joined #openstack-keystone01:18
*** diegows has quit IRC01:22
*** mrda has joined #openstack-keystone01:24
*** lbragstad has joined #openstack-keystone01:25
*** harlowja_ has quit IRC01:28
*** oomichi has quit IRC01:29
*** marcoemorais has quit IRC01:30
*** praneshp_ has joined #openstack-keystone01:32
*** harlowja has joined #openstack-keystone01:32
*** oomichi has joined #openstack-keystone01:33
*** amcrn_ has quit IRC01:33
*** dstanek is now known as dstanek_zzz01:34
*** praneshp has quit IRC01:35
*** praneshp_ is now known as praneshp01:35
*** topol has joined #openstack-keystone01:37
*** lbragstad has left #openstack-keystone01:37
*** mberlin1 has quit IRC01:41
*** mberlin has joined #openstack-keystone01:41
*** praneshp has quit IRC01:43
jamielennoxdoes anyone know how to test things in oslo.config like deperecated opts where it's not the main option name01:44
jamielennoxit means it will work if you load something from a config file but you can't use the stub out methods01:45
*** lbragstad has joined #openstack-keystone01:46
bknudsonjamielennox: How about checking if the option has the deprecated name as expected?01:50
bknudsondon't need to test if the deprecated value works01:50
jamielennoxyea, that's what i'm looking at now - it seems a little trivial was al01:50
bknudsonsince we can assume that oslo.config is tested to handle it correctly01:50
bknudsonhttps://review.openstack.org/#/c/101712/ please?01:53
jamielennoxbknudson: done01:54
bknudsonjamielennox: Thanks!01:54
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from conf  https://review.openstack.org/9501502:05
*** morganfainberg_Z is now known as morganfainberg02:06
*** jamielennox is now known as jamielennox|away02:22
openstackgerritJustin Shepherd proposed a change to openstack/keystone: Adding an index on token.user_id  https://review.openstack.org/10204102:26
*** dstanek_zzz is now known as dstanek02:26
*** dims__ has quit IRC02:28
*** nsquare has quit IRC02:30
*** openstackgerrit has quit IRC02:31
*** mitz_ has joined #openstack-keystone02:36
*** Camisa has joined #openstack-keystone02:37
*** Camisa has joined #openstack-keystone02:37
*** tristanC has joined #openstack-keystone02:45
*** fifieldt_ is now known as fifieldt02:47
*** dims__ has joined #openstack-keystone02:54
*** gokrokve has joined #openstack-keystone02:54
*** hrybacki_ has quit IRC02:55
*** gokrokve_ has joined #openstack-keystone02:56
*** richm has left #openstack-keystone02:57
*** dims__ has quit IRC02:58
*** gokrokve has quit IRC02:59
morganfainbergbknudson, does LDAP not support OS-INHERIT for group roles?03:03
morganfainbergbknudson or... group roles at all?03:03
*** praneshp has joined #openstack-keystone03:04
*** harlowja is now known as harlowja_away03:04
morganfainbergbknudson 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 logic03:04
morganfainbergah nvm figured it out03:28
morganfainbergugh03:32
morganfainbergWTF.03:32
*** dstanek is now known as dstanek_zzz03:32
*** zhiyan_ is now known as zhiyan03:49
*** dims__ has joined #openstack-keystone03:55
*** dims__ has quit IRC03:59
* morganfainberg pokes openstackgerrit03:59
morganfainbergawww. bot is gone.03:59
*** topol has quit IRC04:21
*** dstanek_zzz is now known as dstanek04:25
*** dstanek is now known as dstanek_zzz04:35
*** gokrokve_ has quit IRC04:39
*** gokrokve_ has joined #openstack-keystone04:43
*** lbragstad has quit IRC04:45
*** dims__ has joined #openstack-keystone04:56
*** dstanek_zzz is now known as dstanek04:56
*** ukalifon has joined #openstack-keystone04:57
*** ajc_ has joined #openstack-keystone04:59
*** dims__ has quit IRC05:00
*** gyee has quit IRC05:02
*** gokrokve_ has quit IRC05:02
*** dstanek is now known as dstanek_zzz05:06
*** ncoghlan is now known as ncoghlan_afk05:12
*** morganfainberg is now known as morganfainberg_Z05:14
*** rwsu has quit IRC05:24
*** nsquare has joined #openstack-keystone05:26
*** ncoghlan_afk is now known as ncoghlan05:37
*** praneshp_ has joined #openstack-keystone05:47
*** praneshp has quit IRC05:49
*** praneshp_ is now known as praneshp05:49
*** dims__ has joined #openstack-keystone05:56
*** dstanek_zzz is now known as dstanek05:57
*** gokrokve has joined #openstack-keystone05:59
*** chandan_kumar has quit IRC06:00
*** dims__ has quit IRC06:01
*** gokrokve has quit IRC06:04
*** dstanek is now known as dstanek_zzz06:07
*** afazekas_ has joined #openstack-keystone06:13
*** nsquare has quit IRC06:28
*** nsquare has joined #openstack-keystone06:30
*** nsquare has quit IRC06:31
*** jaosorior has joined #openstack-keystone06:33
*** nsquare has joined #openstack-keystone06:37
*** stevemar has quit IRC06:45
*** dims__ has joined #openstack-keystone06:57
*** dstanek_zzz is now known as dstanek06:57
*** gokrokve has joined #openstack-keystone07:00
*** praneshp has quit IRC07:01
*** dims__ has quit IRC07:04
*** gokrokve has quit IRC07:04
*** tomoiaga has joined #openstack-keystone07:07
*** dstanek is now known as dstanek_zzz07:07
*** BAKfr has joined #openstack-keystone07:11
*** marekd|away is now known as marekd07:16
marekdmorning.07:16
*** nsquare has quit IRC07:16
jaosoriormorning07:28
*** dstanek_zzz is now known as dstanek07:58
*** gokrokve has joined #openstack-keystone08:00
*** mrda is now known as mrda-away08:02
*** gokrokve has quit IRC08:06
*** dstanek is now known as dstanek_zzz08:08
*** Ju_ has quit IRC08:34
*** andreaf has joined #openstack-keystone08:39
*** ncoghlan has quit IRC08:42
tziOmthe08:50
*** openstackgerrit has joined #openstack-keystone08:53
*** dstanek_zzz is now known as dstanek08:59
*** gokrokve has joined #openstack-keystone09:01
*** dims has joined #openstack-keystone09:02
*** gokrokve has quit IRC09:06
*** dims has quit IRC09:08
*** dstanek is now known as dstanek_zzz09:09
*** i159 has joined #openstack-keystone09:20
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: NotImplemented _for_groups functions on LDAP  https://review.openstack.org/10224409:57
*** dstanek_zzz is now known as dstanek10:00
*** gokrokve has joined #openstack-keystone10:02
*** gokrokve has quit IRC10:07
*** dstanek is now known as dstanek_zzz10:10
*** gokrokve has joined #openstack-keystone10:37
*** gokrokve has quit IRC10:38
*** dstanek_zzz is now known as dstanek11:00
*** dims has joined #openstack-keystone11:03
*** dims has quit IRC11:08
*** gokrokve has joined #openstack-keystone11:08
*** gokrokve_ has joined #openstack-keystone11:10
*** gokrokve has quit IRC11:13
*** gokrokve_ has quit IRC11:15
*** dims_ has joined #openstack-keystone11:19
*** dims__ has joined #openstack-keystone11:22
*** dims_ has quit IRC11:25
*** gokrokve has joined #openstack-keystone11:37
*** gokrokve has quit IRC11:42
*** erecio has joined #openstack-keystone11:44
*** kwss has joined #openstack-keystone11:45
*** diegows has joined #openstack-keystone11:46
*** rodrigods has joined #openstack-keystone11:48
*** rodrigods has joined #openstack-keystone11:48
*** otwieracz has joined #openstack-keystone11:56
otwieraczHi!11:56
otwieraczI am going to wokr on: https://bugs.launchpad.net/keystone/+bug/131383711:56
uvirtbotLaunchpad bug 1313837 in keystone "unnecessary period in logs make searching/copy/paste annoying" [Low,Confirmed]11:56
otwieraczAs I see in source code, generally every message ends with period.11:58
otwieraczmessage_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.") etc11:59
otwieraczYou think every of this should be corrected?11:59
otwieraczOr maybe something like:11:59
otwieracz2014-04-28 16:16:34.225 5037 WARNING keystone.common.wsgi [-] Could not find token, <377c4c9a571a4b5ca64d56fe0aaa29c3>.11:59
otwieraczWhat copies fine and is looking better?11:59
*** jaosorior has quit IRC12:02
*** erecio has quit IRC12:11
*** erecio has joined #openstack-keystone12:12
*** erecio has quit IRC12:13
*** erecio has joined #openstack-keystone12:14
*** jaosorior has joined #openstack-keystone12:19
*** erecio has quit IRC12:20
*** erecio has joined #openstack-keystone12:21
*** ajc_ has quit IRC12:23
*** dims__ has quit IRC12:31
*** dims__ has joined #openstack-keystone12:31
*** radez_g0n3 is now known as radez12:36
*** gokrokve has joined #openstack-keystone12:38
tomoiagaIt seems there is a circular dependency between the session object and the auth plugin. Is this intentional ?12:41
*** gokrokve has quit IRC12:43
*** hrybacki has joined #openstack-keystone12:46
otwieraczhttps://github.com/openstack/keystone/blob/master/keystone/locale/en_US/LC_MESSAGES/keystone.po12:46
otwieraczIs this file somehow generated from source code?12:46
*** lbragstad has joined #openstack-keystone12:50
*** gokrokve has joined #openstack-keystone12:53
*** dstanek is now known as dstanek_zzz12:53
*** dstanek_zzz is now known as dstanek13:00
*** htruta has joined #openstack-keystone13:02
*** richm has joined #openstack-keystone13:05
*** _elmiko is now known as elmiko13:11
*** dstanek is now known as dstanek_zzz13:20
*** dstanek_zzz is now known as dstanek13:23
*** gokrokve has quit IRC13:25
*** gokrokve has joined #openstack-keystone13:30
hrybackils13:32
hrybackilol, damnit13:32
*** gokrokve has quit IRC13:33
lbragstadbabel.cfg         etc          keystone           openstack-common.conf  requirements.txt  test-requirements-py3.txt  vendor13:33
lbragstadbin               examples     keystone.egg-info  rally-scenarios        run_tests.sh      test-requirements.txt13:33
lbragstadCONTRIBUTING.rst  HACKING.rst  LICENSE            README.rst             setup.cfg         tools13:33
lbragstaddoc               httpd        MANIFEST.in        requirements-py3.txt   setup.py          tox.ini13:33
*** radez is now known as radez_g0n313:36
hrybackilbragstad++13:37
marekdsteeeevemaaaar, wheeere arreee youuuuu?13:37
lbragstadhrybacki: I've :wq my manager a few times13:38
lbragstadso I know the feeling :)13:38
hrybackilbragstad: hah, good to know. I knew someone else had to have done something similar :)13:39
*** joesavak has joined #openstack-keystone13:45
*** gokrokve has joined #openstack-keystone13:53
*** ukalifon has quit IRC13:56
*** tomoiaga has quit IRC14:01
*** jsavak has joined #openstack-keystone14:10
*** Camisa has quit IRC14:12
*** joesavak has quit IRC14:13
*** ayoung has joined #openstack-keystone14:15
*** tellesnobrega has joined #openstack-keystone14:21
*** tomoiaga has joined #openstack-keystone14:27
*** stevemar has joined #openstack-keystone14:30
marekdstevemar: ding dong.14:31
stevemarmarekd, howdy14:31
*** jaosorior has quit IRC14:32
marekdstevemar:  do we howe some good docs/blog posts abount oAuth implemented in Keystone?14:32
marekdstevemar: how does the workflow look like?14:32
*** gordc has joined #openstack-keystone14:33
stevemarmarekd, the api is probably the best resource14:33
stevemarmarekd, https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-oauth1-ext.md14:33
*** tomoiaga has quit IRC14:33
marekdstevemar: let me see that.14:34
stevemarmarekd, look at "Delegated Authentication Flow"14:34
*** dstanek is now known as dstanek_zzz14:34
marekdstevemar: i am trying to fit k2k bp into oAuth flow....14:35
stevemarmarekd, that sounds like a dangerous game14:38
marekdstevemar: hm, why?14:38
marekdstevemar: i am curious your opinions on that.14:38
*** radez_g0n3 is now known as radez14:39
stevemarmarekd, i think its nice to give access in this case, rather than delegate14:42
*** morganfainberg_Z is now known as morganfainberg14:42
stevemarmarekd, also, the oauth mechanism is for specifically delegating role(s) to a single project14:42
marekdand what about something like claims?14:43
marekdor it's oidc specific only?14:43
*** zhiyan is now known as zhiyan_14:43
*** dstanek_zzz is now known as dstanek14:45
*** gokrokve has quit IRC14:49
*** rwsu has joined #openstack-keystone14:49
*** gokrokve has joined #openstack-keystone14:49
*** oomichi has quit IRC14:52
*** gokrokve has quit IRC14:53
morganfainbergayoung, under apache I'm seeing inconsistent failures (tempest). I'm getting the sinking suspicion that the PKIZ tokens are 100% solving things.14:54
dstanekmorganfainberg: 'are' or 'are not'?14:55
morganfainbergdstanek are not14:55
morganfainbergdstanek thanks, :P just woke up14:56
dstanekstevemar, marekd: finally finish up another pass on https://review.openstack.org/#/c/10002314:56
*** david-lyle has joined #openstack-keystone14:57
stevemardstanek, thank you!14:57
marekddstanek: ++14:58
dstaneki still have reservations about using a single token for all clouds14:59
ayoungmorganfainberg, how big are they?  The ones I saw were nowhere near the limit14:59
ayoungI think there is something else going wrong, not a token size issue15:00
morganfainbergayoung, still chasing it down, but it's consistenly an issue with trust XML15:00
morganfainbergor..15:00
ayoungmorganfainberg, do you have a link?15:00
morganfainbergjson15:00
morganfainbergsec15:00
morganfainbergayoung 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 deployment15:01
ayoung'204' != '200'15:02
morganfainbergyeah15:02
morganfainbergonly under apache15:02
morganfainberghaven't seen that one occur except when deployed under apache15:02
ayounglet me confirm it is expected vs actualy in the tes...15:02
morganfainbergayoung, wasn't PKIZ in this case, brain is still getitng moving, and chasing a nova bug.15:02
morganfainbergayoung the weird part is i've seen it pass. multiple times15:03
morganfainbergunder apache15:03
ayoungmorganfainberg http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/identity/admin/v3/test_trusts.py#n17315:05
ayoungcheck_trust_role(15:05
ayoungso what returns a 200 instead of a 204...15:05
morganfainbergayoung, right. why are we inconsistently under apache getting 204s vs 200s. if i recheck no bug, i almost guarantee it would work.15:06
ayoungmorganfainberg, well, lets see15:06
morganfainbergmaybe we're racing somewhere15:06
ayoungself.trustor_client = os.identity_v3_client15:06
ayoungOK...so over python-keystoneclient15:07
ayoungyeah, maybe15:07
morganfainbergayoung, 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 guessing15:07
ayoung./tempest/services/identity/v3/json/identity_client.py:447:15:08
ayounghttp://git.openstack.org/cgit/openstack/tempest/tree/tempest/services/identity/v3/json/identity_client.py#n44715:09
ayoungso it is doing a HEAD on OS-TRUST/trusts/%s/roles/%s"15:09
morganfainbergand it's expecting a 204?15:09
ayoungyep15:09
ayoungbut getting a 20015:09
ayoung204 vis more correct for a head.15:09
* ayoung thinks15:09
morganfainbergsure15:09
ayoung204 No Content  is, I think, required for HEAD15:10
ayoungso the fact that it would ever give a 200 is suspicious15:10
ayoungand something  that the tempest coder should have  called us on15:10
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/routers.py#n4715:11
stevemardolphm, can you take a look @ https://review.openstack.org/#/c/96836/15:11
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n24815:11
morganfainbergis apache... mangling that output somehow?15:12
ayoungmorganfainberg, it is not apache's fault15:12
ayoungit should be a 20415:12
ayoungthere is nothing returned from the call15:12
morganfainbergright and under eventlet i've never seen it fail15:13
ayoungyou mean "I've never seen it succeed."  the test is wrong15:13
ayoungmorganfainberg, aside from finding hte problem15:14
ayoungthe question is what kind of tapdance do we need to do to fix it15:14
morganfainbergthe test is explicitly asking for a 204 on a HEAD check_role_for_trust doesn't return anything (or raises soemthing else)15:14
ayoungwe have tempest codifying a bug here15:14
ayoungand we should be able to fix it, but we'll break tempest15:14
ayoungohhhh...right, I had it backwards15:14
morganfainbergyeah, i'm wondering _how_ that is returning a 200 not a 20415:15
ayoungOK....so, yeah,  there must be cases where apache is concocting some sort of body15:15
morganfainbergyep15:15
ayoungI actually feel better now15:15
ayounghmmm15:15
morganfainbergayoung, hehe, yeah this is an apache oddity15:15
ayoungmorganfainberg, new hypothesis15:16
morganfainbergok15:17
ayoungApache is doing things "right" ish15:17
ayoungmeaning it is interpresting something else as a part of the response15:17
ayoungand deducing it should have a 200 instead of 20415:17
morganfainbergand eventlet is a bit more sloppy?15:18
morganfainberg"oh body looks none, who cares, 204"15:18
ayoungall the errors are 200 instead of 20415:19
morganfainbergyep 3 errors15:19
morganfainbergthe same three i've previously seen15:19
ayoungmorganfainberg I wonder if it could be a versions thing15:20
ayounglike, different hosts have different versions of apache?15:20
morganfainbergwell... unlkely15:21
morganfainbergi've seen this (now) with apache 2.2 and 2.415:21
ayounghttp://logs.openstack.org/47/100747/8/check/check-tempest-dsvm-full/f60fd38/console.html15:21
ayoungcan we figure what is different between those two runs?15:21
ayoungIt doesn't feel like a race because it 3 fails versus none15:22
ayoung I would expect a race to be more randomly distributed15:22
ayoungwhat does the wsgi app hand back to apache.15:23
ayoung?15:23
ayoungdoes it even give it a response code, or does apache deduce that?  I am guessing it does give back a response15:23
ayoungand then apache reinterprets it15:23
ayoungso question is whether apache or keystone is generatng the 20015:24
*** gokrokve has joined #openstack-keystone15:26
*** gokrokve has quit IRC15:26
ayounghttps://issues.apache.org/bugzilla/show_bug.cgi?id=38070  interesting15:26
uvirtbotayoung: Error: Could not parse XML returned by issues.apache.org: HTTP Error 404: Not Found15:26
*** andreaf_ has joined #openstack-keystone15:27
ayoungmorganfainberg, so we have at least one case of apache rewriting response codes from a wsgi app15:28
morganfainberginteresting15:28
*** andreaf_ has quit IRC15:28
*** gyee has joined #openstack-keystone15:31
dstanekstevemar, marekd: quick question - will the remote keystone be able to open a token from a local keystone and see the data inside?15:43
marekdstevemar: dstanek it should...?15:43
marekddstanek: ^^15:43
marekddstanek: otherwise how remote keystone will validate if the token is not faked..15:44
*** daneyon has joined #openstack-keystone15:45
dstanekmarekd, stevemar: my concern there is information leakage15:46
marekddstanek: what exactly?15:46
ayoungdstanek token is a transparent container15:47
ayounganyone can read it15:47
dstanekmarekd: whatever's in the token - catalog, groups, etc - something we don't have yet that could cause a problem15:47
ayoungyou only need the private key to validate15:47
*** daneyon has quit IRC15:47
ayoungdstanek, then only send information that is relevant15:47
dstanekayoung: i don't think you can - the user can't edit the token right?15:48
ayoungdstanek, Hell no15:48
ayoungdstanek, but you could create a trust with only the subset of the data you want, and use that token15:48
marekdayoung: you need private or public key?15:48
marekdayoung: to validate.15:48
ayoungpublic key15:48
marekdi'd say you sign with private and validate with public...15:48
marekdok15:48
ayoungheh15:48
dstanekayoung: then whatever your local keystone puts in the token would be available to the remote keystone15:48
ayoungmarekd, did I give you a heart attack?15:48
marekdayoung: almost...:-)15:49
ayoungdstanek, yep15:49
ayoungdstanek, or anyone else that gets the token15:49
ayoungtoken data is public data15:49
dstanekayoung: 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 IRC15:51
marekddstanek: i don't have any issue with that15:51
*** david-lyle has joined #openstack-keystone15:51
marekddstanek: you only send it to the remote services, that you *somehow* trust.15:52
marekddstanek: not 100% of course15:52
marekdand IMHO you never should15:52
ayounghow has httpd not migrated over to git yet15:52
marekdbut it's not exposing your token to complete strangers.15:52
dstanekmarekd: 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-keystone15:53
*** i159 has quit IRC15:54
*** david-lyle has quit IRC15:56
marekddstanek: 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-keystone15:57
dstanekas a service provider you won't know if a token will be used across clouds15:57
ayoungmorganfainberg, ok  so,  starting from http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/httpd.h?view=markup15:57
dstanekmarekd: ^15:58
marekddstanek: we have discussed15:58
ayoungmorganfainberg, the symbol is NO_CONTENT15:58
ayoung489 #define HTTP_NO_CONTENT 20415:58
marekddstanek: 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 :P15:58
morganfainbergayoung, brb, filing a rather large (and classifying) nova bug.15:59
ayoungmorganfainberg, I'm going to keep posting these as a trail,  feel free to ignore until you are ready15:59
*** david-lyle has quit IRC16:00
*** gokrokve has quit IRC16:00
morganfainbergayoung just need to propose the ER change and i'm back, 1 min16:00
*** david-lyle has joined #openstack-keystone16:00
dstanekmarekd: 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 now16:00
dstanekmarekd: i'm just trying to organize my thoughts :-)16:01
marekddstanek: I have been trying to do that for days (regarding k2k bp) :(16:01
ayoungmorganfainberg, https://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/server/mod_wsgi.c#L10507  is the only place I see NO_CONTENT16:02
marekddstanek: sorry, need to run now, urgent matter.16:02
marekdfeel free to leave more comments on the bp, so we all can keep track16:02
dstanekmarekd: will do16:02
ayoungthat is in wsgi_execute_remote(  so I think that is pretty much it16:03
ayounghttps://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/server/mod_wsgi.c#L987516:03
ayoungbut then they do things like     if (r->status == 200 && !strcmp(r->status_line, "200 Error")) {16:04
morganfainbergayoung, ok back16:05
ayoungmorganfainberg, I'm digging through the mod_wsgi and httpd 2.4 code bases16:06
morganfainbergayoung, ++16:06
ayoungthere is really only one pointwhere it explicitly refernces a 20416:06
*** kwss has quit IRC16:06
ayoungbut I guess there might be a check for 2XX  and that is what I am looking for now16:06
ayoungdefine ap_is_HTTP_SUCCESS(x)      (((x) >= 200)&&((x) < 300))16:07
ayoungthat was from ./httpd/include/httpd.h:48916:08
ayoungdoesn't appear in the mod_wsgi code16:08
morganfainbergthat seems reasonable though16:08
morganfainbergit's a success if >= 200, but not a 300 code16:08
ayoung./src/server/mod_wsgi.c:1765:            if (self->status >= 200 && self->status < 400) {16:09
ayoungmorganfainberg, want to see, if not a smoking gun, then at least power burns?16:13
ayounghttps://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/server/mod_wsgi.c#L522716:13
morganfainbergwait.. HEAD -> GET?!?!16:14
morganfainbergreally?16:14
*** praneshp has joined #openstack-keystone16:14
morganfainberg*blink*16:14
morganfainbergbecause 'WSGI authors are lazy"16:14
morganfainbergam i reading that correctly?16:14
ayoungnot lazy16:15
ayoungjust "return no content" which kindof makes sense, but I suspect that, in this case, it is calling the wrong operation in the controller16:16
morganfainbergbut.16:16
morganfainbergit works _sometimes_16:16
ayoungyep16:16
morganfainbergi am a iittle baffled why trust is the onlyone that hits this as well16:17
morganfainberghave't seen it with other HEAD calls16:17
morganfainbergunless. thats the only one we test in TEMPEST16:17
*** david-lyle has quit IRC16:17
*** david-lyle has joined #openstack-keystone16:17
*** david-lyle has quit IRC16:19
*** david-ly_ has joined #openstack-keystone16:19
bknudsonis keystone treating a HEAD request differently than a GET?16:20
morganfainbergbknudson, yes in the case of trusts. we return no content (204) as expected16:20
bknudsonmorganfainberg: from HEAD and GET?16:20
bknudsoni.e., if you did a GET it returns 204?16:21
morganfainbergbknudson, no16:21
morganfainbergbknudson HEAD does the 204, get would give actual data16:21
morganfainbergunfortunately, ayoung found code in mod_wsgi that (in some cases) makes a HEAD request into a GET request to the wsgi app.16:21
bknudsonthat's how HEAD is supposed to work... returns what a GET would return, except w/o the body16:21
bknudsonso if GET would return 200 then HEAD should return 20016:21
morganfainbergreally?16:22
bknudsonhttp://tools.ietf.org/html/rfc2616#section-9.416:22
*** david-ly_ has quit IRC16:22
*** david-lyle has joined #openstack-keystone16:23
morganfainbergso we need to go fix a bunch of things i think in keystone16:23
morganfainbergand tempest16:23
* morganfainberg ponder16:24
*** packet has joined #openstack-keystone16:24
morganfainbergor eventlet is doing something very wonky16:24
*** afazekas_ has quit IRC16:26
*** BAKfr has quit IRC16:27
*** david-lyle has quit IRC16:27
morganfainbergbknudson, yeah we seem to support HEAD differently in many cases.16:29
morganfainbergbknudson, sometimes without supporting GET16:29
morganfainbergsometimes with different responses than GET16:29
bknudsonmorganfainberg: I'm not sure that supporting HEAD without GET really makes sense from a HTTP perspective...16:30
bknudsonwhat would wsgi keystone do in that case?16:30
bknudsonfail with 404?16:30
morganfainbergbknudson, yep16:30
bknudsonyikes!16:30
ayoungmorganfainberg, we could make it a different URL, but that seems borked16:30
bknudsonjust have GET return 20416:31
bknudsonand change HEAD to return 20416:31
ayoungbknudson, nope16:31
bknudsonor have it return some body {}16:31
ayoungGET return 204  with a body is wrong16:31
morganfainbergayoung, not wrong, just not common16:31
bknudsonGET 204 w/o a body, or GET 200 with some body {}16:31
morganfainbergayoung if there is no content, there is no content :P16:31
ayoungmorganfainberg, no, becasue the GET returns something16:31
ayoungand the HEAD is not supposed to16:31
bknudsonHEAD isn't allowed to return a body per the spec16:32
ayoungbut in this case it would...there is nothing indicating it is a HEAD request, is there?16:32
bknudsonapache strips off the body for a HEAD request16:32
ayoungmorganfainberg, when would GET ever return a 20416:32
morganfainbergayoung, http://tools.ietf.org/html/rfc2616#section-10.2.5 doesn't say GET can't do 20416:32
ayoungmorganfainberg, I mean in this instance16:33
bknudsonwe could have our eventlet server work the same as apache16:33
ayoungthe controller call16:33
morganfainbergayoung, this case uhm...16:33
bknudsonchange HEAD into GET and strip off the body16:33
morganfainbergayoung, /projects/{project_id}/groups/{group_id}/roles/{role_id} ? we don't have a GET for it16:33
morganfainbergtherefore a HEAD and GET indicate existence of a resource, just no content16:33
ayoungmorganfainberg, I'm just talking about the failing test in trusts16:33
morganfainbergboth would be 204 valid16:33
morganfainbergoh16:33
morganfainberguh.16:34
ayoung check_role_for_trust(self, context, trust_id, role_id):16:34
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n248  is the HEAD16:34
ayoungbut16:34
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n259  is the GET16:34
morganfainbergayoung, right16:34
morganfainbergcould we smush them together?16:34
ayoungso we really need to make HEAD return 20016:35
morganfainbergin cases where the get would return 200, the head should also return too16:35
morganfainberg200*16:36
* morganfainberg wonders how many things will get broken if we fix this16:37
bknudsonwe've said that you could run keystone in apache forever16:37
bknudsonso it's been working that way for whoever was running that way16:37
morganfainbergbknudson, the wierd thing is this doesn't fail tempest under apache everytime16:37
bknudsonmorganfainberg: that is weird16:37
morganfainbergbknudson, yeah16:37
bknudsonwell, maybe shouldn't be surprising considering random tempest failures.16:38
morganfainbergbknudson, sure, but this one seems like a legitimate case of "we're actually doing something wrong" and sometimes we fail.16:39
morganfainbergit also makes me wonder if eventlet does something dumb16:40
morganfainberglike if you say HEAD request, and there is actual content, it gives the content back too16:40
bknudsoneventlet is probably trusting the application to work correctly16:41
morganfainbergso in all likelyhood we should just be returning an empty body for HEAD requests if the get would return something in the body16:42
morganfainbergor so we also need to provide content length?16:43
dolphmmorganfainberg: you actually are supposed to send a non-zero Content-Length in response to HEAD, but we don't do that16:48
dolphmmorganfainberg: as far as i know, anyway16:48
morganfainbergdolphm, ok. i'll file a bug on this.16:48
morganfainbergdolphm, i think we need to resolve GET vs HEAD responses before we can move to apache then.16:48
morganfainbergso we don't end up with sometimes-failing odd gate cases.16:49
*** daneyon has joined #openstack-keystone16:49
* dolphm scrolls back wondering wtf is going on...16:49
*** browne has joined #openstack-keystone16:50
morganfainbergdolphm, we sometimes fail a check under apache where tempest is expecting a 204 back from a HEAD call16:50
morganfainbergdolphm, but the GET for the same call would be 20016:50
morganfainbergdolphm in some cases, apache (mod_wsgi) will convert a HEAD request to GET and just strip the data off16:50
morganfainbergit 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
dolphmmorganfainberg: oooh - that's probably my fault :(16:51
*** gokrokve has joined #openstack-keystone16:51
morganfainbergeven under apache it's not 100% consistent, should be pretty easy to fix, but will require some fixes across keystone, tempest and possibly ksc16:52
dolphmmorganfainberg: sounds like the wsgi module itself should handle HEAD requests, and we should only implement GET controller methods?16:53
morganfainbergsounds like a good approach16:53
morganfainbergI'll file a bug shortly and see how broken things get doing thay implementation today after breakfast16:55
morganfainbergthay = that16:55
dstanekdolphm: that's exactly how we handled it where i used to work17:00
dstanekstevemar: i think i'm done thinking about that review for a few days :-)17:00
*** david-lyle has joined #openstack-keystone17:01
otwieraczGuys, can you just take a look at http://wklej.org/hash/d864b3039a/, this is output of otwieracz@voyager ~/keystone $ tox17:04
otwieraczWhy it is failing on unmodified master branch?17:04
dolphmotwieracz: looks like all kinds of things going wrong there - i don't even know where to start17:07
dolphmotwieracz: what's the output of $ python --version17:07
dolphmotwieracz: 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
dstanekotwieracz: it looks like your ipv6 tests are failing failing on 2.717:10
*** jsavak has quit IRC17:12
otwieraczotwieracz@voyager ~ $ python --version17:13
otwieraczPython 3.3.317:13
otwieraczotwieracz@voyager ~ $ python2 --version17:13
otwieraczPython 2.7.617:13
*** harlowja_away is now known as harlowja17:13
hrybackiayoung: so where do we stand in regards to cinder. That left me more confused than when we began17:14
dstanekotwieracz: start with getting it to work on just 2.7 by running 'tox -e py27'17:15
otwieraczdstanek: ok17:15
ayounghrybacki, it means that Cinder is already done17:16
ayoungand we can use that as an example of what to do in the other clients17:16
hrybacki++17:16
hrybackiand what about the discover bit?17:16
ayoungbut the "external auth plugins" part leaves me a little concerned, so take a note to figure out what they are doing there17:17
ayoungprobably for talking to non-keystone auth systems, I hope17:17
dstanekotwieracz: you probably don't have python2.6 installed so that will always fail17:17
otwieraczI need python2.6 for -e py27?17:17
dstanekotwieracz: 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 envlist17:19
otwieraczYes, ok.17:20
otwieraczYou've scared me :)17:20
otwieraczBut, still failing on v6.17:20
dstaneki don't think this is a Keystone specific issue - for some reason you system passed the ipv6 check, but can't actually connect to ipv617:22
dstanekfirewall issue?17:22
dolphmdstanek: otwieracz: i think it's trying to run python 2.7 tests on python 3.317:22
dolphmor something17:22
dstanekdolphm: what makes you say that?17:23
otwieraczI have IPv6 here.17:23
otwieraczSo that's probably why.17:23
dolphmdstanek: $ python --version is 3.3.3, and "py27 runtests: commands[0] | python setup.py testr --slowest --testr-args= ..."17:23
dolphmdstanek: shouldn't that be python2.7, not just python?17:24
dstanekdolphm: 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 that17:24
dolphmotwieracz: what platform are you using that is defaulting python to 3.3?17:24
otwieraczGentoo.17:24
dolphmdstanek: i'd hope so too, but ...17:24
otwieraczBut whatever, -e 27 does not work too.17:25
otwieracz-e py27*17:25
*** daneyon has quit IRC17:25
dolphmotwieracz: what happens if you run... $ python2.7 setup.py testr17:25
otwieraczerror: invalid command 'testr'17:26
dstanekyou'll have to use .tox/py27/bin/python17:26
dstanekif you run that version of python wiht the --version flag it should be 2.717:26
dolphmotwieracz: err, what's .tox/py27/bin/python --version ?17:26
*** daneyon has joined #openstack-keystone17:26
otwieracz2.7.617:26
dolphmotwieracz: well then i'm wrong.17:26
otwieracz/usr/bin/python3.3: No module named 'subunit'17:26
otwieraczwhile17:26
otwieraczotwieracz@voyager ~/mirantis/git/keystone-orig $ .tox/py27/bin/python setup.py testr17:27
morganfainbergdolphm, https://bugs.launchpad.net/keystone/+bug/1334368 HEAD vs GET, marked it as medium17:27
uvirtbotLaunchpad bug 1334368 in keystone "HEAD and GET inconsistencies in Keystone" [Medium,Triaged]17:27
dstaneki think your 2.7 setup is fine and you are just having trouble connecting over ipv617:27
otwieraczI think the same.17:28
otwieraczBut I do not know, why.17:28
otwieraczOh, I may know why.17:28
dstanekmy best guess would be firewall or some other system issue17:28
morganfainbergdolphm, 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 time17:28
*** daneyon has quit IRC17:29
otwieraczdstanek: Yes, that might be the issue – testing now.17:29
dstanekas for py3 - i'm working on getting a few things fixed there - updated deps broke things17:30
*** daneyon has joined #openstack-keystone17:31
*** nsquare has joined #openstack-keystone17:34
ayounghrybacki, https://review.openstack.org/#/c/92390/  but that is only API, not session.17:37
hrybackithe commit message is misleading then17:38
otwieraczdstanek: Yes, now 27 passed./17:39
otwieraczdstanek: It was firewall issue.17:39
*** marcoemorais has joined #openstack-keystone17:42
dstanekotwieracz: excellent17:42
otwieraczThanks for help.17:42
dstanekno problem17:44
otwieraczIf I change exception message I should also fix po files?17:47
otwieraczI mean, there's no other translation project?17:48
dstanekotwieracz: you want to change the message for a specific translation?17:49
otwieraczhttps://bugs.launchpad.net/keystone/+bug/131383717:49
uvirtbotLaunchpad bug 1313837 in keystone "unnecessary period in logs make searching/copy/paste annoying" [Low,Confirmed]17:49
otwieraczthis bug17:49
morganfainbergotwieracz, translations are handled via transifex, don't change the .po files17:49
*** daneyon has quit IRC17:50
dstanekotwieracz: you would change that in the Python code17:50
otwieraczmorganfainberg: So, if I change messages in „exceptions.py”17:50
dstanekwhat morganfainberg said :-)17:50
morganfainbergotwieracz, the translators will need to do the updates and then it would get update based upon what you change in the python file17:50
otwieraczmorganfainberg: I should not update po files?17:50
otwieraczmorganfainberg: OK!17:50
otwieraczmorganfainberg: That's great.17:50
morganfainbergotwieracz, correct, do not update the .po files :)17:50
otwieraczmorganfainberg: I was worrying if I do not miss anything updating lots of lines in .po files.17:50
otwieraczSo, only .py, right?17:51
dstanekotwieracz: yes17:51
otwieraczGreat.17:51
hrybackiayoung: so it looks like cinder pretty nearly copied the work the neutron folks had done, yeah?18:01
ayoungneutron?18:03
ayoungyou mean keystone?18:03
hrybackihttps://review.openstack.org/#/c/92390/ -- neutronclient18:04
ayoungneutron only did V3 api work, so change what they called on the server18:04
hrybackihttps://review.openstack.org/#/c/95305 -- cinderclient18:04
ayoungcinder went frther18:04
ayoungand used keystoneclient18:04
hrybackitrue but they are many similarities between the two -- trying to find where this copy and pasting originated from18:05
ayoungprobably from the keystoneclient itself hrybacki18:08
stevemardstanek, thanks for the review boss18:13
*** joesavak has joined #openstack-keystone18:13
*** afazekas_ has joined #openstack-keystone18:13
dstanekstevemar: my pleasure - i'm looking forward to getting feedback on my security related thoughts18:14
*** ukalifon has joined #openstack-keystone18:22
*** morganfainberg_L has quit IRC18:31
stevemardstanek, you've got to stop copying and pasting your comments from whatever you're writing them in :P18:37
stevemarthey keep breaking the text boxes18:37
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Add optional parameters to EndpointManger create()  https://review.openstack.org/10260218:40
*** afazekas_ has quit IRC18:41
*** ukalifon has quit IRC18:41
*** ukalifon has joined #openstack-keystone18:41
dstaneki'm writing directly into the browser :-(18:42
*** stevemar has quit IRC18:52
*** stevemar has joined #openstack-keystone18:52
*** harlowja has quit IRC18:52
*** stevemar has quit IRC18:56
*** stevemar has joined #openstack-keystone18:56
*** marcoemorais has quit IRC18:59
*** marcoemorais has joined #openstack-keystone18:59
*** marcoemorais has quit IRC19:00
*** marcoemorais has joined #openstack-keystone19:00
*** marcoemorais has quit IRC19:01
*** marcoemorais has joined #openstack-keystone19:02
*** marcoemorais has quit IRC19:02
*** marcoemorais has joined #openstack-keystone19:02
*** afazekas_ has joined #openstack-keystone19:03
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: V3 extension advertisement  https://review.openstack.org/9597319:04
*** openstackgerrit has quit IRC19:04
*** openstackgerrit has joined #openstack-keystone19:06
*** hrybacki_ has joined #openstack-keystone19:30
*** daneyon has joined #openstack-keystone19:30
*** hrybacki has quit IRC19:33
*** dstanek is now known as dstanek_zzz19:34
*** hrybacki_ has quit IRC19:35
*** CaioBrentano has joined #openstack-keystone19:35
CaioBrentanohi all...19:35
CaioBrentanodoes anyone knows what is the "ca_certs" parameter on keystone.conf, session [ssl] ?19:36
morganfainbergdstanek_zzz, https://bugs.launchpad.net/keystone/+bug/133440819:36
uvirtbotLaunchpad bug 1334408 in keystone "test_backend classes not always run in the test_backend_* module" [Wishlist,New]19:36
morganfainbergdstanek_zzz, figure you'd appreciate this one19:36
CaioBrentanoI configured my keystone to work with ssl… Its working just fine… and I didnt set this parameter19:36
*** joesavak has quit IRC19:39
*** daneyon has quit IRC19:41
*** dstanek_zzz is now known as dstanek19:45
dstanekmorganfainberg: your just saying that we add a backend and don't alway test it?19:47
morganfainbergno we add a test case19:47
morganfainbergand we don't test it against all of our backends19:47
morganfainberge.g. inheritence19:47
morganfainbergyou know we only run the inheritence test cases against SQL?19:47
dstanekah19:47
morganfainbergeven though KVS supports it. LDAP on the other hand doesn't, shouldn't we be at least explicitly skipping then?19:48
dstanekdoes a coverage report show that we are lacking tests?19:48
morganfainbergsortof19:48
morganfainbergwe catch some of the code elsewhere19:48
morganfainbergthis all stems from the 'dump everything in test_backend' and the make submodules to run the tests19:49
morganfainbergwe 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
morganfainbergs/smarter/less likely to forget something/19:50
morganfainbergas it turns out... KVS inheritance is kinda broken.19:50
* morganfainberg wants KVS backends to die for Identity / Assignment19:51
morganfainbergdolphm, 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 IRC19:52
*** andreaf_ has joined #openstack-keystone19:52
*** erecio has quit IRC19:52
dstanekmorganfainberg: i have a bunch of commits coming to start cleaning up the tests, so i'm hoping that i'll be making this easier19:55
morganfainbergdstanek, cool19:56
*** erecio has joined #openstack-keystone19:57
dstanekmorganfainberg: 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 rebase19:58
*** openstackgerrit has quit IRC20:05
*** openstackgerrit has joined #openstack-keystone20:06
openstackgerritDavid Stanek proposed a change to openstack/keystone: Middleware tests now run under Python3  https://review.openstack.org/9966920:11
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds a fork of python-ldap for Py3 testing  https://review.openstack.org/9582720:11
openstackgerritDavid Stanek proposed a change to openstack/keystone: Updates Python3 requirements to match Python2  https://review.openstack.org/9582620:11
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds oslo.db support for Python 3 tests  https://review.openstack.org/10262420:11
morganfainbergdstanek, i think i still want to prepose patches that simply redact identity and assignment KVS :P20:11
dstanekmorganfainberg: works for me20:21
*** afazekas_ has quit IRC20:21
*** CaioBrentano has left #openstack-keystone20:22
*** wchrisj has joined #openstack-keystone20:28
wchrisjdolphm: got a sec for a quick question?20:29
wchrisjnm dolphm20:31
*** cuddyt has joined #openstack-keystone20:31
wchrisjCould 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
wchrisjWhen I attempt to auth with a uname/pwd, it fails asking for a domain...20:32
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones  https://review.openstack.org/10002320:34
*** andreaf_ has quit IRC20:39
*** stevemar has quit IRC20:45
dstanekwchrisj: yes you need username, password and domain20:46
wchrisjThe 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
wchrisjthx dstanek, looks that way20:47
wchrisjworks with v2, not with v320:47
dstanekwchrisj: http://git.openstack.org/cgit/openstack/identity-api/tree/v3/src/markdown/identity-api-v3.md#n129220:48
*** marcoemorais has quit IRC20:48
wchrisjthanks dstanek20:49
*** htruta has quit IRC20:50
*** tellesnobrega has quit IRC20:50
*** rodrigods has quit IRC20:50
*** rodrigods has joined #openstack-keystone20:51
*** tellesnobrega has joined #openstack-keystone20:51
*** htruta has joined #openstack-keystone20:51
*** daneyon has joined #openstack-keystone20:52
dstanekwchrisj: np20:55
boris-42morganfainberg hi20:56
*** erecio has quit IRC20:56
morganfainbergboris-42, hi there!20:56
boris-42morganfainberg can you pls review plugin sample for keystone20:56
boris-42morganfainberg https://review.openstack.org/#/c/98836/20:56
*** radez is now known as radez_g0n320:56
boris-42it's already for quite long time20:56
*** topol has joined #openstack-keystone20:57
boris-42morganfainberg 17 days since uploaded (and 13 since latest update)20:57
morganfainbergboris-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-keystone20:58
morganfainbergdstanek wow, group grants in kvs are... just not there... really at all20:59
*** gokrokve has quit IRC21:01
dstanekmorganfainberg: kvs is at best a toy for tests21:03
morganfainbergdstanek, and even that is suspect at this point :P21:04
topoldstanek, didnt someone tell you. dont go looking at kvs.  You wont like what you see...21:07
dstanektopol: that would have been good advice before my eyes started to bleed21:10
topoldstanek, sorry.  But you will see those floating spots in your eyes now forever. It wont go away21:11
*** daneyon has quit IRC21:11
*** ayoung is now known as ayoung-dadmode21:15
*** marcoemorais has joined #openstack-keystone21:21
morganfainbergso, sdague raised a rather serious issue we have, catalog in the token issue21:27
morganfainberghttp://logs.openstack.org/66/99766/2/check/check-grenade-dsvm/9fd33e1/logs/old/screen-key.txt.gz?level=INFO21:27
*** harlowja has joined #openstack-keystone21:28
morganfainbergcareful that might kill your browser21:28
morganfainberg~900k lines of eventlet stack traces21:28
morganfainbergand it looks like we're exceeding the maximum size allowed by eventlet in keystone.21:28
morganfainbergoh... and it results in "cloud death"™ when that occurs21:28
morganfainbergdstanek, dolphm, jamielennox|away, topol, gyee, ayoung-dadmode, ^21:29
morganfainbergwe can try and backport PKIZ to icehouse (that is icehouse)21:29
morganfainbergbut 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
morganfainbergnkinder, ^ as well, since ayoung-dadmode is dadmode.21:32
morganfainbergobviously the easiest solution is UUID tokens, but that is sub-wonderful for other reasons.21:32
bknudsonwhat's wrong with UUID tokens?21:33
gyeemorganfainberg, yeah, that's a known limitation, we can't have more than 8K header by default21:33
bknudsonif your tokens are too big then uuid tokens are the way to go21:33
morganfainbergbknudson, nothing. just that we've been pushing for PKI for a while21:33
nkindermorganfainberg: yeah, I really worry about the token size issues21:33
nkinderwell, UUID tokens force a round trip to keystone for validation (right?)21:34
morganfainbergif 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 hands21:34
morganfainbergnkinder, correct21:34
*** gordc has quit IRC21:34
bknudsonat some point the overheads of huge tokens are higher than the overhead of keystone roundtrip21:34
nkinder..also, we're back to having a big token database to maintain21:34
morganfainbergbknudson, well looks like at 8k we break the cloud ;)21:34
bknudsonthere is no other option for icehouse other than to use UUID tokens21:35
gyeePKI token is the right direction21:35
bknudsonfor big deployments21:35
gyeewe just need to solve the freakin catalog headache21:35
morganfainbergbknudson, that means we need to change the gate / grenade default21:35
nkindergyee: +121:35
morganfainbergbknudson, because gate is tipping over [not a big deployment]21:35
morganfainbergbut big enough21:35
morganfainbergits intermittant, but still.21:35
bknudsonby big deployments I mean 1 server21:35
morganfainbergbknudson, so we should default back to UUID for I?21:36
gyeeheh21:36
gyee1 server big deployment21:36
morganfainbergand change the documentation?21:36
bknudsonI don't know what else to do about it21:36
morganfainberggyee, ++ the catalog needs to be out of the token this release or PKI is probably a dead token option21:36
topolmorganfainberg how did the catalog get soooo big?21:37
morganfainbergbknudson, it's a fair option. neither do i. ;)21:37
nkinderwhy does the catalog have to be in the token in the first place?21:37
*** mrda-away is now known as mrda21:37
morganfainbergtopol, we keep the entire url among other cruft in there.21:37
gyeemorgainfainberg, I almost think catalog needs its own service, like LDAP or something21:37
morganfainbergnkinder, it doesn;t. why is it? because it was a way to get the informaiton about ndpoints to the user21:37
nkindergyee: yeah, I'm thinking that the catalog can be looked up21:37
gyeenkinder, totally, LDAP is made for that stuff21:38
gyeehighly static and fast lookup21:38
nkindergyee: well, LDAP or something else really21:38
topolmorganfainberg, the catalog as become that no good brother in law that has outstayed his welcome at your house21:38
nkindergyee: people aren't going to want to use AD to store their endpoints for example21:38
gyeenkinder, zookeeper idea have been bounced around before21:38
morganfainberggyee, 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 itself21:38
gyeejust didn't have a chance to follow up on it21:38
topolgyee everone hates zookeeper21:38
gyeetopol, why?21:39
topolgyee aint it java21:39
morganfainberggyee, X-CATALOG would just be so we don't "break" everyone at once (or force extra roundtrips to keystone)21:39
morganfainbergtopol, there is some love, hate, hate, and more hate around zookeeper i thnk21:39
nkindermorganfainberg: yeah, something like that would be ideal IMHO21:39
gyeejava is a language, why hate a language?21:39
gyeelanguage is just a tool21:39
topolmorganfainberg ++++21:39
topolgyee, you dont need to convert me sir21:39
dstaneksorry...just catching up21:40
topolgyee, I have just been to that rodeo before21:40
morganfainbergnkinder, it also doesn't help us that our catalog backend is sub-wonderful anyway.21:40
morganfainbergnkinder it's not awful21:40
morganfainbergnkinder just could be a lot better21:40
dstanekif they happens then a cloud is just too big to put their catalog in the token21:40
gyees/tool/weapon/21:40
dstanekgyee: yes, Java is a tool21:40
morganfainbergdstanek, and it is happening in grenade for icehouse, meaning it doesn't take a big cloud to hit the limit21:40
nkinderdstanek: that's how I read it too :)21:40
gyeeI used whatever I can get my hands on :)21:41
topolmorganfainberg, what made this worse than beofre?21:41
bknudsonwe keep getting more services in the catalog21:41
bknudsone.g., heat, etc21:41
gyeebknudson, you bet, think outside of IaaS21:41
gyeewe should have a truck load of *aaS in the catalog21:42
dstanekhow hard would it be to remove the token from the catalog in the grenade tests?21:42
morganfainbergtopol, 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 services21:42
nkindermorganfainberg: the catalog backend can be improved, but the immediate problem is the token size.  Is it "good enough" for now?21:42
morganfainbergnkinder, well i think bad data format has lent to this being a bigger problem21:42
morganfainbergnkinder, but same net result21:42
morganfainbergnkinder s/backend/format for catalog/21:43
morganfainbergsorry21:43
morganfainbergdstanek, unlikely to be doable. much easier to flip back to UUID tokens21:43
bknudsonso how does the X-OS-CATALOG header work?21:43
morganfainbergbknudson, i think this is a single header response issue21:44
*** gokrokve_ has quit IRC21:44
bknudsonit seems like anything we do isn't going to be backwards compat so we're stuck with UUID21:44
morganfainbergbknudson, yeah.21:44
*** gokrokve has joined #openstack-keystone21:44
morganfainbergwell. we might be able to backport PKIZ to lighten the load for i21:44
morganfainbergbut that might just be head-in-sand21:44
gyeenkinder, thanks for putting the crypto inventory wiki, saved my life today when I have to fill out that export form21:44
bknudsonfrom what I've seen PKIZ tokens are 50% the size21:45
bknudsonso they're going to fail at some point anyways21:45
nkinderyeah, PKIZ is a stop-gap21:45
morganfainbergbknudson, correct, for J we need to really solve this21:45
morganfainbergbut we could try and go PKIZ for Icehouse as the stop-gap21:45
bknudsonI don't have a problem with backporting PKIZ21:45
bknudsonHorizon had an issue with them21:46
morganfainbergplus documentation that if we hit X size, sorry you need to use UUID.21:46
nkindergyee: awesome, glad it helped!21:46
morganfainbergbknudson, then focus on getting the catalog out of the token in J, so we don't need the stop-gap solution21:47
dstanekmorganfainberg: is that just a client side issue?21:47
morganfainbergdstanek, hm?21:47
topolgyee+++ great job nkinderon the crypto inventory21:47
dstanekmorganfainberg: to fetch the catalog separate from token21:47
topolnkinder, you coming to the hackathon?21:47
gyeeyeah, otherwise, I would have to scan the code to get the form done21:48
morganfainbergdstanek, yeah we'd need to push it to the client.21:48
gyeewhy is it alway the french that care about the crypto stuff21:48
morganfainbergdstanek, well, any client really.21:48
gyeealways21:48
nkindertopol: can't, I'm taking my family on a vacation21:48
*** gokrokve_ has joined #openstack-keystone21:48
topolnkinder, good for you. hope you go somewhere fun21:48
morganfainbergtopol, see nkinder likes his family more than us. got his priorities straight! :)21:48
nkindertopol: annual camping trip, no computers :)21:49
*** gokrokve has quit IRC21:49
topolnkinder, working showers and bathrooms or bring a shovel and dig a hole?21:49
nkinderthe lure of BBQ in TX was very tempting though21:49
topolnkinder TX BBQ is awesome21:49
nkindertopol: bathrooms, but no showers (but there is a lake, which counts... right?)21:50
morganfainbergbknudson, i think backporting PKIZ is a requirements update, the new provider, and 3 lines of runtime code, and the tests21:50
topolnkinder, I sooo hate camping. better you than me21:50
morganfainbergbknudson, should be easy.21:50
topolmorganfainberg, I rmember that patch. i think you are right21:50
nkindermorganfainberg: if we pull the catalog out of tokens, how much outside of keystone needs to change?21:51
bknudsonmorganfainberg: it's not a big change it's just not the type that's usually backported21:51
topolmorganfainberg would buy us some time  to get it fixed right21:51
morganfainbergbknudson, yeah i know :(21:51
bknudsonand when we know that UUID works then that seems like the safer option21:51
morganfainbergnkinder, keystone, probably not a lot, but a lot of things assume the catalog is in the token21:51
morganfainbergnkinder, a lot of things.21:52
gyeenkinder, keystoneclient discovery logic definitely will need to be updated as it pull the endpoint off the catalog21:52
bknudsonmaybe we can have a pki test that has a smaller catalog21:52
morganfainbergbknudson, for I i'm find backporting a 'default this to uuid instead' fix21:52
gyeenova-glance also depended on the catalog21:52
*** gokrokve_ has quit IRC21:52
topolbknudson, how big a performance hit for folks if they go back to UUID?21:52
*** gokrokve has joined #openstack-keystone21:52
gyeeI think nova looks up the glance endpoint for the image stuff21:53
gyeeglance may even need swift endpoints if it stores the image into swift21:53
nkindergyee: does it use keystoneclient for that though?21:53
bknudsontopol: the performance depends on a lot of variables so I couldn't say.... latency of the network, etc.21:53
morganfainbergtopol, in a high-token volume environment (lots of token issuance) it's really rough21:54
gyeenkinder, I don't think so21:54
topoldoes anyone remember when we switcthed to PKI anyone saying,  wow this is a huge improvement for me.  THANKS21:54
topolcause with PKI you had the hit of doing the signing as a separate process (not cheap)21:54
bknudsonand fetching the revocation list21:55
*** ayoung-dadmode is now known as ayoung21:56
gyeethe openssl part can be improved, like using m2crypto or something21:56
gyeerevocation list can be eliminated with short-lived tokens21:56
morganfainbergbknudson, the cheapest fix for this is going back to UUID for icehouse21:56
topolshort lived tokens my have other bad side efects if they werent expected21:57
morganfainbergand discussing what we're going to do about Juno21:57
topolmorganfainberg, I thnk you are right. And then comes accepting the fact as clouds get bigger putting catalog in the token doesnt scale21:57
ayoungmorganfainberg, backport PKIZ will break horizon21:57
morganfainbergayoung, then the only answer is reverting back to UUID tokens for icehouse21:58
ayoungbut we could backport that as well21:58
gyeetopol, I worked on WPKI (wireless PKI) in one of my previous lifes, WPKI essentially uses short-lived certs to eliminated the need for CRL21:58
ayoungdjango-auth-openstack21:58
topolayoung and morganfainberg making good arguments during this time of crisis :-)21:58
*** marcoemorais has quit IRC21:58
*** david-lyle has quit IRC21:59
*** marcoemorais has joined #openstack-keystone21:59
*** marcoemorais has quit IRC21:59
gyeeit all comes to to risk management21:59
morganfainbergayoung, it's probably safer to use UUID tbh21:59
ayoungtopol, big catalogs are the problem21:59
gyeecomes down to21:59
topolayoung, I agree21:59
*** marcoemorais has joined #openstack-keystone21:59
*** david-lyle has joined #openstack-keystone21:59
topolbut wont they get bigger over time?21:59
topolayoung/21:59
morganfainbergayoung, topol, and the catalogs aren'tgoing to get smaller21:59
topolmorganfainberg+++22:00
morganfainbergtopol, over a short timeframe, let alone long.22:00
ayounglets just drop the catalog from the token unless explicitly requested.  What will it break?22:00
ayounghave like, just nova in there or something22:00
morganfainbergayoung, nova, glance, uhm horizon22:00
topolayoung, interesting idea. bare minimum catalog22:00
nkinderyeah, a default filter22:00
topolayoung, primary and secondary serrvices22:01
*** dims__ has quit IRC22:01
ayoungmorganfainberg, nah, don't need horizon.  And I don't think nova actually uses the info to select glance or neutron22:01
dstanekso dumb question - what is the difference between using UUID tokens and using PKI tokens without the catalog?22:01
topolayoung, make it configurable?22:01
ayoungall we really need is to know "where do I go to do something"22:01
topolayoung, filter mask?22:01
ayoungtopol, nah, the problem is all of the clients.22:01
ayoungthey all need the service catalog in the token22:01
bknudsonwe could switch to returning a token hash if the PKI token gets too big22:01
ayoungand they won't know to say "I need a token for glance"22:01
topolayoung, the whole catalog?22:01
*** lbragstad has quit IRC22:02
ayoungno, glance client  needs the glance service only22:02
topolbknudson, that sounds good22:02
nkinderdstanek: essentially just the way the token is validated22:02
bknudsonI think it would be backwards compat (to return a hash)22:02
ayoungbknudson, yep22:02
nkinderdstanek: and the ability to eventually drop tokens from the database on the keystone side of things22:03
ayoung"continued in next token"22:03
*** elmiko is now known as _elmiko22:03
*** david-lyle has quit IRC22:03
bknudsondstanek: you get a catalog back in the token response for UUID or PKI tokens.22:04
morganfainbergok so. fix for icehouse, UUID. work on dropping catalog for juno?22:04
bknudsonmorganfainberg: what do you think about change keystone PKI to return hash if the token is too big?22:04
dstanekbknudson: in UUID it's not a header right?22:04
nkinderbknudson: I've been tossing that idea around as well22:05
nkindertruncating or dropping the catalog it it's over 8k22:05
bknudsondstanek: no, we don't have any catalog in the header22:05
morganfainbergbknudson, still requires token persistence.22:05
morganfainbergso we can't drop persisting tokens ever.22:05
bknudsonmorganfainberg: sure, but that would be a different provider?22:05
morganfainbergbknudson, oh you mean in the PKI / PKIZ provider?22:05
bknudsonmorganfainberg: I'm mentioning this as another kind of stopgap22:06
bknudsonwasn't saying to forget about figuring out how to get the catalog out of the token22:06
morganfainbergbknudson, hm. maybe. though i think it would be less complex to always return the hash22:06
dstaneki 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
morganfainbergor use uuid22:06
ayoungwouldn't be the provider22:06
ayoungit would be in the controller22:06
ayoungdstanek, hmmm, yea22:06
*** joesavak has joined #openstack-keystone22:06
ayoungclients would be fine22:07
bknudsondstanek: I think you're mostly right... it's auth_token that would be missing the catalog22:07
ayoungyou might be right, it might be that no one needs it22:07
bknudsonand it's not hard to change auth_token22:07
bknudsonclients could supposedly take the token response and generate their own pki from it.22:07
bknudsonbut I doubt anyone would be doing that22:08
*** kevinbenton has joined #openstack-keystone22:08
ayoungthere is an option to drop the catalog from the token.  Can we default that to on and try the CI?22:08
bknudsonayoung: in auth_token22:09
bknudson?22:09
ayoungbknudson, no in keystone22:10
*** cuddyt has quit IRC22:10
bknudsonayoung: you mean there's an existing config option for that?22:11
morganfainbergayoung, it's a query string.22:11
morganfainbergayoung not a global.22:11
nkinderayoung: you mean ?nocatalog22:11
bknudsonhttp://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n30322:12
bknudsonThere's an option in auth_token22:12
kevinbentonis there a way to permission a user to just be able to list tenants and tenant names?22:12
kevinbentonit seems in the v2 api I need to set the tenantName to ‘admin’22:13
bknudsonso if we remove the catalog from the PKI token, auth_token can't set X-Service-Catalog.22:13
bknudsonunless it can get the catalog for the token some other way22:13
bknudsonI wonder if anyone even uses it22:13
morganfainbergbknudson, though x-service-catalog might overrun the limit to now that i think about it22:14
bknudson(X-Service-Catalog)22:14
*** daneyon has joined #openstack-keystone22:14
ayoungI thought there was22:14
ayoungyeah ?nocatalog22:14
*** topol has quit IRC22:14
bknudsonmorganfainberg: there's a limit to how much can be passed along the paste pipeline?22:14
morganfainbergbknudson, the issue is the response from eventlet.22:14
morganfainbergbknudson, responding to posts on /auth/22:15
bknudsonmorganfainberg: oh, this isn't even the server accepting a request with large header?22:15
bknudsonnow it's generating the response? weird.22:15
morganfainbergbknudson, basically we accept the request for a token, and then keystone stacktraces trying to send the response22:16
morganfainbergin eventlet22:16
morganfainbergthe issue is when we issue the token, not even getting to middleware22:16
dstanekmorganfainberg: is that what the 'broken pipes' are?22:16
morganfainbergdstanek, thats what it looks like in this case.22:16
bknudsonbroken pipes and crap goes everywhere22:17
dstanekmorganfainberg: how do you know that it has to do with token size?22:17
bknudsonbeen there22:17
morganfainbergdstanek, or the requsts lib is dropping the connection22:17
morganfainbergor any number of things.22:17
ayoung include_catalog = 'nocatalog' not in context['query_string']22:17
ayoungso instead we would do22:17
morganfainbergdstanek, i've seen similar issues before on this. and it seems to be specific to posts to /auth/token22:17
ayoung include_catalog = 'includecatalog'  in context['query_string']22:18
ayounglet me see what breaks22:18
morganfainbergbknudson, please correct me if i'm wrong, but i _think_ that was the issue we had earlier on22:18
bknudsonmorganfainberg: I don't think I've heard of the server failing to respond because the header is too big.22:19
morganfainbergbknudson, hm.22:19
dstanekmorganfainberg: so when i've seen broken pipe issues in the paste they were caused by the Python process seg faulting22:19
dstanekmorganfainberg: is that what's happening?22:20
bknudsonbut I know there's problems with other servers accepting the monster header22:20
morganfainbergbknudson, might be hitting the out-bound limit, iirc apache has one of those as well22:20
bknudsonit wouldn't surprise me if apache even changed which causes it to fail more now22:20
morganfainberghmm.22:23
morganfainbergbknudson, dstanek, blah22:24
morganfainbergwe don't trap broken pipe in our eventlet code22:24
morganfainbergwe actually should be ignoring it.22:24
* morganfainberg is digging in further22:24
morganfainbergi _think_ the client side might be overwhelemed with data22:24
morganfainberg(still could be token size)22:24
bknudsonSIGPIPE22:24
morganfainbergrequests lib or some such22:25
*** dims__ has joined #openstack-keystone22:25
dstanekit's possible that the client is overloaded, but i would doubt it22:25
dstaneki've used requests to pull lots of data in the past - not really big header though22:26
morganfainbergdstanek, yeah there is weird stuff around headers22:26
morganfainbergdstanek, the more i look at HTTP22:26
morganfainberg:P22:26
bknudsonsome POST /v3/auth/tokens work in that log, and some are failing with the broken pipe22:27
ayounglets just yank the catalog out of the tokens22:27
ayoungwhat is the worst that can happen?22:27
bknudsonseems like we don't need to log a traceback for the pipe error22:27
bknudsonalthough maybe that's in eventlet and we have no control over it22:28
morganfainbergthis is client hanging up22:28
morganfainbergfor sue22:28
morganfainbergfor sure*22:28
morganfainbergbut not sure why the client keeps hanging up on this post22:29
bknudsonmemory corruption22:30
morganfainbergmaybe22:30
bknudsonthis is why we should use java22:31
morganfainberglol22:31
*** openstackgerrit has quit IRC22:35
*** openstackgerrit has joined #openstack-keystone22:36
morganfainbergbknudson, i don't know how to catch this exception :(22:38
bknudsonit's a potential DOS, just start a request and segfault and you'll fill the logs22:38
morganfainbergyarp22:40
dstanekmorganfainberg: you just have to supply a subclass of eventlet.wsgi.HTTPProtocol to the eventlet.wsgi.Server when creating it22:41
morganfainbergdstanek, really?22:42
morganfainbergdstanek, eh could be worse.22:42
dstanekmorganfainberg: wait until you see how you'd have to do it :-P22:42
morganfainbergdstanek, it's going to make me cry... isn't it?22:42
dstanekinstead of copying and hacking handle_one_response you may just want to filter the log22:44
dstaneksuppressing the messages will stop a DOS on the log, but nothing else22:44
dstanekis that what we care about here?22:44
morganfainbergdstanek, well i'm curious what is causing the issue22:45
morganfainbergwe could also just smush log.INFO down for eventlet22:45
morganfainbergdo we _care_ about info?22:45
*** serverascode has quit IRC22:47
kevinbentonhi, 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 admin22:48
morganfainbergdstanek, i'm going to standup a keystone with a massive service catalog (50 endpoints) and see if there is something bedise the client being dumb22:48
kevinbentonis this same limitation present in the v3 api?22:48
morganfainbergkevinbenton, you can do different limiting wiht policy (full RBAC) in v322:48
morganfainbergkevinbenton, v2 doesn't support more than 'is admin' or 'is not admin'22:49
kevinbentonmorganfainberg: how is this policy expressed. Is it configurable via the keystone CLI?22:50
nkinderkevinbenton: I think what you want is shown in the policy.v3cloudsample.json file22:50
morganfainbergnkinder, ++22:50
*** serverascode has joined #openstack-keystone22:51
dstanekmorganfainberg: i can't get requests to break even with really big headers22:51
kevinbentonnkinder: oh okay, so this is the same format as existing policy.json22:51
kevinbenton:q22:52
dstanekmorganfainberg: can this just be networking issues between the keystone instance and the client?22:52
morganfainbergdstanek, in a devstack?22:52
kevinbentonmorganfainberg, nkinder: thanks. now I just need to update my code to use the v3 api :-)22:52
dstanekmorganfainberg: oh, hmmm. i thought this was in a real env22:53
morganfainbergdstanek, nope, this is happening in grenade22:53
dstanekmorganfainberg: ha, found the header size limit in requests - http://dpaste.com/08XXQW222:56
morganfainberg65k?22:56
morganfainberggod i hope we're not over 65k :P22:57
dstanekrequests is doing something funny, but it works file with headers 2**1523:01
dstanekmorganfainberg: off to dinner - my test server http://dpaste.com/3HBRSD1 - my test client http://dpaste.com/2N3F56723:04
*** marcoemorais has quit IRC23:06
*** marcoemorais has joined #openstack-keystone23:06
*** marcoemorais has quit IRC23:06
*** marcoemorais has joined #openstack-keystone23:07
ayoungmorganfainberg, 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 well23:09
*** diegows has quit IRC23:10
nkinderayoung: I think we need to look at what it will take to get the catalog out of tokens though23:11
ayoungnkinder, two sides:  changing keystone is easy23:12
nkinderto me, it doesn't really belong there since it has nothing to do with authorization23:12
ayoungmaking sure nothing need the body is a little harder23:12
nkinderayoung: yeah, I know the other side will be the difficult one here23:12
dstaneknkinder: ++23:12
ayoungnkinder, might not be23:12
dstanekno more catalog!23:12
ayoungauth_token is the point of contact for that23:12
dstaneki'm skeptical that this issue is related to header size23:12
nkindera token is for authorization, so roles belong there.  Endpoints really have nothing to do with authorization.23:12
nkinderdstanek: yeah, I'm not sure either *but* we know token size is causing issues for using mod_wsgi23:13
dstanekagreed.23:13
nkinder...and using mod_wsgi is important for the approach of using apache modules to add stronger authentication mechanisms23:13
dstanekfor this issue i wonder if the server's OOM killer is killing off clients23:14
ayoungnkinder, endpoint binding should be in the token23:16
ayoungbut that doesn't mean the whole catalog should be there23:17
*** daneyon has quit IRC23:17
ayoungGod I feel like we are building this thing by trial and error, from crisis to crisis23:17
nkinderayoung: but my point is that the endpoint info in the token is not used for enforcement23:18
ayoungnkinder, agreed.  It should be if it is there, and only enforcement info should be there23:18
ayoungI wonder if HEAT or Nova are going to have an issue with the token missing the catalog23:18
ayoungself.token_provider_api.issue_v3_token(  returns id, token_data23:20
nkinderayoung: 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-keystone23:21
ayoungnkinder, its a signed JSON document.  CMS validates the signed docuemnt and returns the JSON23:22
morganfainbergdstanek, i think you're right this isn't a token issue.23:22
morganfainbergdstanek, hitting another limit with the token SQL table before eventlet craps out23:22
ayounghttp://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/common/cms.py#n12023:23
nkinderayoung: ok, so we just return the token body as a result of the validation on the client side23:23
ayoungyep23:23
ayoungso long as we sign the right data23:23
morganfainbergdstanek, http://dpaste.com/1J500KX23:23
morganfainbergreaching towards the upper limit on the token size23:23
ayoung1408523:27
morganfainbergayoung, i could get more in there but the token table craps out23:28
*** oomichi has joined #openstack-keystone23:30
dstanek14084 right?23:33
morganfainbergat 65k of total token data we tip over23:35
nkindermorganfainberg: yet another reason for ephemeral/non-persisted tokens ;)23:37
morganfainbergnkinder, yep23:38
dstanekmorganfainberg: just tested eventlet with a 64536 byte header and it went ok there23:40
morganfainbergdstanek, yeah23:40
morganfainbergdstanek, i'm convinced it's the client being dumb23:40
morganfainbergmeaning...23:40
morganfainberg:(23:40
morganfainbergwe need to make eventlet not spam the log in this case.23:41
mgagneCan 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 read23:41
dstanekmorganfainberg: did you see my comment about OOM?23:41
morganfainbergdstanek, no.23:41
dstanekfor this issue i wonder if the server's OOM killer is killing off clients23:41
morganfainbergdstanek, might be23:41
morganfainbergmgagne, 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
morganfainbergmgagne, 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 date23:42
morganfainbergmgagne, and on startup, a client will need to retrieve the complete list from keystone.23:43
morganfainbergdstanek, we should get dmesg in the devstack log output23:43
mgagnemorganfainberg: right. how is this different from the actual revocation list already used with PKI/CRL?23:43
morganfainbergmgagne, the revoction event is based upon information in the token, e.g. user_id23:43
morganfainbergmgagne, so you cna match every token belonging to a user with one event23:43
mgagnemorganfainberg: so it's agnostic of the token format?23:43
morganfainbergmgagne, 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 tokens23:44
mgagnemorganfainberg: so it's about moving from a revoked token list to a revokcation list based on user/project id instead23:44
mgagnemorganfainberg: alright23:44
morganfainbergmgagne, 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
morganfainbergmgagne, 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
mgagnemorganfainberg: 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 queue23:45
morganfainbergmgagne, 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 event23:46
mgagnemorganfainberg: 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
mgagnemorganfainberg: makes sense now thanks for the info23:47
morganfainbergmgagne, it absolutely should also emit notifications on a bus for events, but by no means should that be the only way23:47
morganfainbergdstanek, ok so i think quick and dirty... we handle EPIPE issues23:47
morganfainbergdstanek, and back port that to Icehouse *cries a little*23:48
morganfainbergif there are OOM issues we have to say "uhh"23:48
*** r-daneel has joined #openstack-keystone23:48
morganfainbergi'll see if we can get a dmesg dump in gate as well.23:48
*** r-daneel has quit IRC23:52
morganfainbergdstanek, not OOMkiller23:53
morganfainberglooked at syslog and kern log23:53
dstanekhmm...any way to know which client so we can see if it has anything in its logs?23:56
openstackgerritBrant Knudson proposed a change to openstack/keystone: V3 Extensions  https://review.openstack.org/9538923:57

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