Tuesday, 2014-07-22

jamielennoxayoung: mind if i cleanup https://review.openstack.org/#/c/108071/1/specs/juno/explicit-unscoped.rst00:00
openstackgerritJamie Lennox proposed a change to openstack/keystone-specs: Explicity request an unscoped token  https://review.openstack.org/10807100:25
*** hrybacki has joined #openstack-keystone00:26
*** dims has joined #openstack-keystone00:29
*** ncoghlan is now known as ncoghlan_afk00:29
*** dims has quit IRC00:34
*** david-lyle has joined #openstack-keystone00:35
ayoungjamielennox, no problem at all.00:38
jamielennoxayoung: good, i posted it already :)00:38
ayoungjamielennox, did you see my response to your "service catalog for unscoped"  review request?  Does it make sense that the service catalog would only be in the response ,but not in the token itself?00:39
*** david-lyle has quit IRC00:39
jamielennoxayoung: yea, i posted a response to that00:39
jamielennoxbasically i'm fine with that if there is some precendence00:39
jamielennoxdo we do that anywhere already?00:39
ayoungjamielennox, no.  But the service catalog was only in the token itself due to the need to replicate the validate call00:40
jamielennoxayoung: no that's not true, if i pass my token to nova and nova calls glance it should call "my" glance00:40
ayoungsince only keystone itself can ever consume an unscoped token, there is no reason for it to need to return a catalog in validate00:40
ayoungnot an unscoped token00:40
jamielennoxbut i agree that in an unscoped token there's not really a need to embed the catalog00:41
ayoungjamielennox, that used to happen in the "validate" call00:41
jamielennoxayoung: oh for UUID tokens - yea that makes sense00:43
jamielennoxah the good old days00:43
ayoungjamielennox, BTW,  there is some ugliness with the straigh client.Client(....) way of creating a client, even if there is a tokenid passed in.  Would it make sense to change those factory methods to creat a session under the covers00:44
jamielennoxayoung: should i make that clear in the blueprint or look to in the api review?00:44
jamielennoxactually never mind me - there is no api review for this00:44
jamielennoxayoung: only issue with that would be dealing constructing the plugins, i've resisted the concept of a big plugin factory00:45
ayoungYeah, but in the case of "if token"  or "if password" we want to have the existing logic carried over.  I was just seeing some cases where I fied something in the auth plugin, only to see it was actually getting the endpoint in httpclient00:46
jamielennoxyep, but it's not just that because it includes it token and v2 or if token and v300:49
*** ncoghlan_afk is now known as ncoghlan00:50
ayoungjamielennox,  if a v3 client.Cliet were passed a v2 token, wouldn't that be ok, and same for the reverse?00:52
jamielennoxayoung: yes00:52
jamielennoxit's more about what is available00:52
jamielennoxsee for example: https://review.openstack.org/#/c/81147/00:53
ayoungI like that jamielennox00:56
jamielennoxi think that one will be really useful for CLI and CONF files00:56
jamielennoxit's where all this auth plugin and discovery stuff starts to come together00:57
ayoungI think Horizon should use it00:57
ayoungI might just pull that in to my horizon work00:57
jamielennoxit's almost unecessary because it mostly relies on whether you provide domain information, but still useful00:57
jamielennoxand importantly the auth_url that you pass it is unversioned00:57
*** ncoghlan is now known as ncoghlan_afk01:00
ayoungjamielennox, its that last part that is messing me up.  the client.Client code should probably use it.01:01
jamielennoxso what are you doing that needs client.Client() ?01:02
jamielennoxif you have discoverable auth do you need discoverable client?01:03
jamielennoxayoung: what's the policy on changing backend APIs?01:03
*** gmurphy has quit IRC01:08
ayoungjamielennox, client.Client is called from Horizon01:08
ayoungI'll pass a link here in a second01:08
*** gmurphy has joined #openstack-keystone01:09
ayoungjamielennox, http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py#n16801:12
jamielennoxayoung: that looks version specific to me01:13
ayoungjamielennox, yes, it is.  That is why I was saying client.Client, but I realize that might not have been clear.01:17
ayoungI meant specifically the versioned, so01:17
ayoungfrom v2 import client....01:18
jamielennoxah right, no we have a keystoneclient.client.Client() which does discovery01:18
jamielennoxi thought you meant that01:18
ayoungnot one from keystoneclient.client01:18
ayoungjamielennox, so would it make sense to make those plugin and session aware?01:18
ayoungjamielennox, there is a good chance that I will end up having to change the Horzion code, too, to pull in the session from Django-OpenStack-auth, but right now I am trying to avoid it.01:19
jamielennoxayoung: so if you have a session and a auth plugin at that point then you're fine - v2/v3 auth won't matter01:19
openstackgerritBrant Knudson proposed a change to openstack/keystone: JSON-Home for V3  https://review.openstack.org/10398301:19
*** ncoghlan_afk is now known as ncoghlan01:24
*** marcoemorais has quit IRC01:27
ayoungjamielennox, so if I pass a token into v3.client.Client, I'll use the token auth plugin and create a session implicitly.  Same with v2.  If only password, I'll use the password auth plugin01:27
*** dims has joined #openstack-keystone01:30
jamielennoxayoung: i tried that initially - it's just way to hard to keep the backwards compatability correct01:31
ayounghmmm.  probably true01:31
jamielennoxour tests and other users do just dumb things where they expect they should be able to override things like the store token and have that work01:31
jamielennoxit made the base client just layers of redirection values01:32
ayoungjamielennox, I've already had to hack keystone, client, and DOA.  I was hoping to avoid hacking Horizon as well.  Quite foolish to think I could01:32
jamielennoxso clean break, if you pass session then you get new behaviour, if you don't you get old behaviour01:32
jamielennoxi've done that even more strictly in novaclient and cinderclient01:32
ayoung OK...01:33
ayounglets see what happens when I pip install -e horizon then as a first step...01:33
*** dims has quit IRC01:34
ayoungugh....this not be cheap....01:44
jamielennoxhorizon install?01:45
*** mberlin1 has quit IRC01:49
*** radez is now known as radez_g0n301:50
*** mberlin has joined #openstack-keystone01:50
*** ncoghlan has quit IRC01:50
*** ncoghlan has joined #openstack-keystone01:51
*** jamielennox has quit IRC01:52
*** diegows has quit IRC01:52
*** dims has joined #openstack-keystone01:56
*** jamielennox has joined #openstack-keystone01:56
*** oomichi has joined #openstack-keystone02:32
*** xianghui has quit IRC03:00
*** Chicago has joined #openstack-keystone03:01
*** xianghui has joined #openstack-keystone03:05
*** richm has left #openstack-keystone03:14
*** dims has quit IRC03:25
*** hrybacki has quit IRC03:36
*** amcrn has quit IRC03:45
*** cjellick_ has joined #openstack-keystone04:01
*** chandankumar has joined #openstack-keystone04:03
*** cjellick has quit IRC04:04
*** stevemar has joined #openstack-keystone04:04
stevemarjamielennox, ping04:05
jamielennoxstevemar: hello04:05
stevemarjamielennox, just a quick q04:05
stevemarwhy did you move things around line 220 here: https://review.openstack.org/#/c/108221/2/openstackclient/tests/identity/v3/test_identity_provider.py04:05
*** cjellick_ has quit IRC04:06
*** shakamunyi has joined #openstack-keystone04:06
jamielennoxstevemar: i don't remember - i think i would have been trying to reuse it and then scrapped that change04:06
*** gabriel-bezerra has quit IRC04:06
jamielennoxyea, i think i was having some issues when i was trying to have a federation mock, which then had a sub identity_providers mock04:07
stevemarjamielennox, it's cool, as long as i wasn't missing something04:07
*** gabriel-bezerra has joined #openstack-keystone04:07
stevemarit's cool, +A04:07
jamielennoxthat didn't work so i ended up with the FakeFederationManager04:07
stevemari tried it out with federation extension enabled04:07
stevemarand it worked (yay)04:07
*** jamielennox_ has joined #openstack-keystone04:08
*** ncoghlan_ has joined #openstack-keystone04:08
*** shakamunyi has quit IRC04:08
*** ncoghlan__ has joined #openstack-keystone04:08
*** jamielenno| has joined #openstack-keystone04:09
jamielenno|stevemar: cheers04:09
jamielenno|bah - wtf is happening with my connection04:09
stevemarjamielenno|, it's dying, there are three of you now04:10
*** gabriel-bezerra has quit IRC04:10
*** gabriel-bezerra has joined #openstack-keystone04:10
*** jamielennox has quit IRC04:12
*** jamielenno| is now known as jamielennox04:12
*** jamielennox_ has quit IRC04:12
*** ncoghlan has quit IRC04:12
*** ncoghlan_ has quit IRC04:12
openstackgerritArun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling.  https://review.openstack.org/9530004:15
jamielennoxstevemar: what did you setup your local federation env with? i tried a few things and now realize how crap ECP is04:15
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Specification for OpenID Connect  https://review.openstack.org/10789004:19
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Specification for OpenID Connect  https://review.openstack.org/10789004:20
jamielennoxstevemar: also just for my curiosity with oauth and openid connect are you persisting data to the keystone db?04:20
jamielennoxmy understanding of SAML federation is that it is a purely ephemeral user id, can you do that with oauth or openid?04:21
stevemarjamielennox, my local federation env, for real testing of SSO and ECP authN, i use tivoli federated identity manager04:21
stevemarhad someone from that team help me with the setup, it really helped04:22
stevemarfor oauth, thats just delegation, the only thing i persist to the keystone dbs are the request and access token information04:22
jamielennoxstevemar: yep - i didn't think we did oauth from external idp04:22
stevemari think / hope that openid connect will be the same as saml, it'll all be ephemeral04:23
jamielennoxis oauth (/2) possible in that way?04:23
stevemarjamielennox, openid connect is all the goodness of oauth2 and more04:26
stevemarjamielennox, oauth2 by itself is just another delegation protocol, like oauth1 or trusts.04:26
*** gabriel-bezerra has quit IRC04:26
*** gabriel-bezerra has joined #openstack-keystone04:27
stevemaropenid was being developed, then they threw in some oauth2 and called it openid connect :P04:27
jamielennoxbut oauth2 can obviously delegate to a new user04:27
jamielennoxtaking eg google04:28
jamielennoxyou could signing with oauth(/2), you wouldn't actually need any permissions on google's services but it would provide auth04:28
jamielennoxyou have the same problem with role mapping04:28
jamielennoxbut if it boils down to a user_id what do you need to save locally?04:29
jamielennoxit's still kind of useless because all this is web driven - but just for interest04:29
stevemarjamielennox, shouldn't save anything locally about the user04:29
stevemarthe mapping should give the user roles04:30
stevemarjamielennox, yeah, thats the trouble with these things, all web driven04:30
jamielennoxok, so it means that oauth wouldn't have the obvious things like a list of groups and roles you could easily map, but there is nothing preventing oauth - it's just not that useful04:31
*** alex_xu has joined #openstack-keystone04:31
*** cjellick has joined #openstack-keystone04:32
stevemarjamielennox, correct, oauth by itself is just delegation04:32
stevemarjamielennox, out of curiosity, do you know if auth token mangles the catalog and removes endpoint ids? (super specific question)04:33
jamielennoxstevemar: auth_token shouldn't mangle it, i don't know off the top of my head if endpoint ids are in the catalog04:33
jamielennoxi think they are for v3 but not for v204:33
jamielennoxbut i'd check that04:34
stevemarjamielennox, for v3 they are, (according to the API spec)04:34
stevemarbut i'm wondering if they are there for templated catalog?04:34
jamielennoxstevemar: yea, i remember discussing that though and we decided they shouldn't be04:34
jamielennoxbut then this endpoint enforcement thing came up and we will need them04:34
*** ajayaa has joined #openstack-keystone04:34
jamielennoxstevemar: i think no, because there is no actual v3 templated response. It just takes the v2 catalog and transforms it04:35
jamielennoxstevemar: oh - wait04:35
jamielennoxstevemar: yes, auth_token mangles the catalog04:35
jamielennoxit turns v3 catalog into v2 catalog04:35
stevemarjamielennox, yes, this guy here https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L38504:36
* jamielennox wrote that and should remember this stuff04:36
stevemarjamielennox, haha04:36
stevemarjamielennox, happens04:36
jamielennoxwhy do you need endpoint ids?04:37
stevemarjamielennox, the code i'm looking at is going through the endpoints in the catalog and checking ['endpoints'][0]['id']04:38
stevemarbut failing on the id part04:38
jamielennoxalso another question - in mapping you have a locals list and a remote list, does it make sense to have multiple local entries?04:38
stevemarbut _v3_to_v2_catalog shouldn't mangle the id's - right?04:39
jamielennoxstevemar: it might not pick them up04:39
stevemarjamielennox, iirc the kent folk were saying we should have it that way04:39
*** cjellick has quit IRC04:40
jamielennoxstevemar: so i just got a v2 token and it appears there is an endpoint id in the token04:41
jamielennoxit's a bit weird though because it's closer to a service id04:41
jamielennoxin v2 an endpoint consists of a public, internal and admin URL04:42
jamielennoxwhereby in v3 each of those would have a different id04:42
*** gabriel-bezerra has quit IRC04:42
stevemarlet me try running CatalogConversionTests in ksclient04:43
*** gabriel-bezerra has joined #openstack-keystone04:43
stevemarjamielennox, bah, no id there, might be a limitation of the fixture though04:47
jamielennoxstevemar: i expect i just never tested that the id went through04:47
stevemarlet me find out why they might need it... i suspect they don't but will complain that i should fix it04:48
jamielennoxif you look at the way it's written it picks out the v3 parts it wants04:48
jamielennoxalso given that you'd compress 3 ids down to one i don't know what the right value would be04:48
*** amcrn has joined #openstack-keystone04:49
jamielennoxoh, there is a legacy_endpoint_id that is used for v2, otherwise it uses v3 endpoint id per url04:49
stevemarjamielennox, where do you see that part?04:50
jamielennoxlooking at the database and memory04:50
jamielennox(my memory)04:50
jamielennoxi'm just looking now to see if legacy_endpoint_id is part of the catalo g04:51
stevemarjamielennox, i just searched for legacy_endpoint_id no results :(04:51
jamielennoxthink you mispelt then, i get a few04:52
jamielennoxmostly keystone/catalog/controllers.p04:52
stevemaroh i was looking in client04:53
*** dims has joined #openstack-keystone04:54
jamielennoxstevemar: nope, no legacy_endpoint_id emitted04:56
jamielennoxstevemar: v2 http://paste.openstack.org/show/87531/04:58
jamielennoxv3: http://paste.openstack.org/show/87530/.04:58
*** gabriel-bezerra has quit IRC04:58
*** amcrn has quit IRC04:59
jamielennoxusing the same user/pass/project04:59
stevemarjamielennox, if i am invoking nova image-list, shouldn't that hit keystoneclient.middleware? (trying to debug)04:59
jamielennoxi expect so04:59
*** dims has quit IRC04:59
jamielennoxbut see anyway that the ids between v2 and v3 aren't the same - so we can't jsut convert one to the other04:59
*** gabriel-bezerra has joined #openstack-keystone04:59
stevemarso in auth_token_middleware, the convert v3_to_v2 method, we just don't add them?05:00
stevemarno information is better than misinformation i suppose05:01
jamielennoxstevemar: i'm still lost as to why you care about endpoint id?05:01
stevemarjamielennox, i don't care, someone else does.05:02
jamielennoxok, so why they care?05:02
stevemarauditing tools05:02
stevemarthey have an id field to fill in! thus we must have an id05:02
jamielennoxlol, but it's the catalog - why would you need to log that?05:03
stevemari have noooo idea05:08
jamielennoxok, so back to mapping for just a sec, locals list and remotes list, what happens if you have mutliple local entries?05:10
stevemarlet me try and remember...05:11
jamielennoxyea, the mapping syntax is described nowhere05:11
stevemarjamielennox, i always default back to the fixtures05:13
stevemarright right, i remember now05:13
stevemarit's if you want to apply several local ones at once05:13
jamielennoxso i can understand mapping to serveral groups, but there is users mixed in there as well05:14
stevemarjamielennox, so in that example (RULES_SMALL), we could have a single rule to just map users05:14
jamielennoxthere's just the assumption then that you can map to multiple things - and expect it to blow up if user is specified more than once it should die05:14
stevemarjamielennox, we do blow up if the user is specified more than once05:15
stevemarbut yes05:15
*** gabriel-bezerra has quit IRC05:15
jamielennoxis the somewhat unusual syntax because it gets copied straight into a token?05:16
*** gabriel-bezerra has joined #openstack-keystone05:17
*** bvandenh has joined #openstack-keystone05:19
stevemarjamielennox, more or less, we take the user and group ids and slot them into a token05:20
stevemaran unscoped token*05:20
*** chandankumar has quit IRC05:25
*** arborism has joined #openstack-keystone05:32
*** shausy has joined #openstack-keystone05:33
ajayaaayoung: How do I enable caching for catalog/assignment while running unit tests?05:42
*** bvandenh has quit IRC05:44
jamielennoxajayaa: i don't know of the top of my head - but i don't think you should05:45
jamielennoxthe unit tests are written for very specific scenarios - if you cache within them they won't work05:46
ajayaaI am working on the blueprint "add caching layer in keystone."05:46
ajayaaI have added the caching layer for catalog. But I need to write tests for it.05:46
*** stevemar has quit IRC05:47
jamielennoxajayaa: oh, right - um i think you'll want to set the value in CONF but i don't know what that value is05:47
jamielennoxi'd check out morganfainberg's existing tests05:48
ajayaaI am checking them out. Wrote a similar test to already existing test. Created a region. deleted the region bypassing the assignment api. Then tried to retrieve it. It should have passed if caching worked correctly.05:49
ajayaajamielennox,  I should work imo. But it fails. So I was wondering whether there is some flag or some config setting by which I can enable caching in unit tests.05:51
jamielennoxajayaa: that doesn't look like you've turned the cache on though05:52
jamielennoxhmm, guess you must have otherwise it'd skip05:52
jamielennoxajayaa: i really don't know sorry05:53
ajayaaokay, jamielennox05:53
ajayaajamielennox, at what time can I get hold of morganfainberg?05:53
jamielennoxumm, up till about 4 hours ago - i don't know about start05:54
jamielennoxhe's in san fransisco - but he works long hours05:54
*** ncoghlan__ is now known as ncoghlan_afk05:54
*** k4n0 has joined #openstack-keystone05:59
*** chandankumar has joined #openstack-keystone06:01
*** soulxu1404_ has joined #openstack-keystone06:02
*** alex_xu has quit IRC06:02
*** tomoiaga has joined #openstack-keystone06:02
*** soulxu1404_ is now known as alex_xu06:05
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/10693906:06
*** ncoghlan_afk is now known as ncoghlan__06:07
openstackgerritguang-yee proposed a change to openstack/keystone: X.509 SSL certificate authentication plugin  https://review.openstack.org/10373606:10
openstackgerritguang-yee proposed a change to openstack/keystone-specs: X.509 SSL certificate authentication  https://review.openstack.org/10591306:14
*** henrynash has joined #openstack-keystone06:15
*** gyee has quit IRC06:17
*** ncoghlan__ is now known as ncoghlan_afk06:17
*** andreaf has quit IRC06:22
*** alex_xu has quit IRC06:34
*** chandankumar has quit IRC06:39
*** alex_xu has joined #openstack-keystone06:51
openstackgerritJamie Lennox proposed a change to openstack/keystone: Add restricted catalog to unscoped token  https://review.openstack.org/10859206:51
*** arborism has quit IRC06:52
*** dims has joined #openstack-keystone06:57
*** dims has quit IRC07:02
*** harlowja is now known as harlowja_away07:04
*** ncoghlan_afk is now known as ncoghlan__07:20
*** gabriel-bezerra has quit IRC07:20
*** gabriel-bezerra has joined #openstack-keystone07:21
*** jamielennox is now known as jamielennox|away07:31
*** alex_xu has quit IRC07:34
*** k4n0 has quit IRC07:51
openstackgerritBob Thyne proposed a change to openstack/identity-api: Update OS-EP-FILTER API  https://review.openstack.org/10629207:55
*** dims has joined #openstack-keystone07:58
*** alex_xu has joined #openstack-keystone07:59
*** afazekas has joined #openstack-keystone08:01
*** gabriel-bezerra has quit IRC08:01
*** gabriel-bezerra has joined #openstack-keystone08:02
*** dims has quit IRC08:03
*** k4n0 has joined #openstack-keystone08:04
*** bvandenh has joined #openstack-keystone08:12
*** andreaf has joined #openstack-keystone08:18
*** alex_xu has quit IRC08:18
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations.  https://review.openstack.org/8063008:25
*** alex_xu has joined #openstack-keystone08:30
*** k4n0 has quit IRC08:32
openstackgerritMarek Denis proposed a change to openstack/keystone-specs: Keystone WebSSO  https://review.openstack.org/10861108:42
*** k4n0 has joined #openstack-keystone08:49
*** henrynash has quit IRC08:53
*** dims has joined #openstack-keystone08:58
*** dims has quit IRC09:04
*** alex_xu has quit IRC09:12
*** ncoghlan__ has quit IRC09:17
*** k4n0 has quit IRC09:19
*** openstackgerrit has quit IRC09:31
*** openstackgerrit has joined #openstack-keystone09:32
*** k4n0 has joined #openstack-keystone09:38
*** cjellick has joined #openstack-keystone09:38
*** cjellick has quit IRC09:42
openstackgerritA change was merged to openstack/python-keystoneclient: Use immutable arg rather mutable arg  https://review.openstack.org/10380109:50
*** hyakuhei has quit IRC09:54
*** csd has quit IRC09:54
*** anteaya has quit IRC09:54
*** csd has joined #openstack-keystone09:55
*** hyakuhei has joined #openstack-keystone09:55
*** anteaya has joined #openstack-keystone09:56
*** oomichi has quit IRC09:59
*** dims has joined #openstack-keystone09:59
*** dims has quit IRC10:04
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Specification for IETF ABFAB federation  https://review.openstack.org/10863110:07
*** diegows has joined #openstack-keystone10:59
*** masahito has joined #openstack-keystone11:13
masahitohi there!!11:16
masahitoI have a question about usage of keystoneclient.11:16
masahitohow do I customize an option value "http_connect_timeout" in auth_token.py?11:21
masahitoI think it is a Int value but the code in the master repo shows Bool value.11:22
*** k4n0 has quit IRC11:28
*** dims has joined #openstack-keystone11:32
*** shausy has quit IRC11:37
*** shausy2 has joined #openstack-keystone11:37
*** henrynash has joined #openstack-keystone11:46
masahitoumm... anyone isn't in this channel now.11:47
*** xianghui has quit IRC11:47
*** ayoung has quit IRC11:47
tomoiagamasahito: http://docs.openstack.org/trunk/config-reference/content/keystone-configuration-file.html11:51
tomoiagamasahito: look for http_connect_timeout11:51
masahitotomoiaga: thanks for answering11:53
tomoiagamasahito: it says there it's bool. however, 0 is False and > 0 is True in Python and looking at the code you can use a value grater than 0 if you want to set it like 10 for example11:54
tomoiagamasahito: also note that the value needs to be set unde [keystone_authtoken] in the keystone.conf file11:55
*** xianghui has joined #openstack-keystone12:00
*** gabriel-bezerra has quit IRC12:09
*** hrybacki has joined #openstack-keystone12:10
*** gabriel-bezerra has joined #openstack-keystone12:11
masahitotomoiaga: you mean I must change the option in keystone.conf not in auth_token.py, don't you?12:12
tomoiagamasahito: if you want to set a custom timeout than yes, do not edit source files. All auth_token.py does is to read that value from keystone.conf12:13
masahitotomoiaga: I tried to change the option in auth_token.py to int value then other component like nova didin't start.12:14
masahitotomoiaga: OK. I try to set the time out in keystone.conf12:14
tomoiagamasahito: well, I am not sure how you changed it, that's why it's not a good idea to change source files if you can edit the config12:15
masahitotomoiaga: when I was searching what kind of option dose keystone have,12:18
masahitotomoiaga: I found the option. And I tried to custum this.12:18
tomoiagamasahito: if you want to change the value in auth_token.py (not recommended) you need to change the line: http_connect_timeout_cfg = self._conf_get('http_connect_timeout') to http_connect_timeout_cfg = 10  (or another number for the timeout)12:19
masahitotomoiaga: After challenging custumizing this, nova and other component didn't start. So I questioned this.12:20
tomoiagamasahito: changing http_connect_timeout in keystone.conf under [keystone_autotoken] should not affect nova in any way (or other services for that matter)12:20
*** hrybacki_ has joined #openstack-keystone12:33
*** dims has quit IRC12:33
*** dims has joined #openstack-keystone12:33
*** hrybacki has quit IRC12:36
masahitotomoiaga: thx!! I can change the config using your advice.12:46
tomoiagamasahito: no problem12:46
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Bump hacking to 0.9.x series  https://review.openstack.org/10732812:47
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Use keystoneclient.exceptions instead of keystone.apiclient.exceptions.  https://review.openstack.org/10867512:48
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Bump hacking to 0.9.x series  https://review.openstack.org/10732812:51
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Removed keystone.apiclient  https://review.openstack.org/10792612:59
*** rwsu has joined #openstack-keystone13:08
*** gabriel-bezerra has quit IRC13:09
*** gabriel-bezerra has joined #openstack-keystone13:09
*** bknudson has quit IRC13:10
*** akscram has quit IRC13:11
*** stevemar has joined #openstack-keystone13:16
*** nkinder has quit IRC13:18
*** russellb has joined #openstack-keystone13:20
russellbdolphm: o/  just wanted to check in on juno-213:20
russellbdolphm: looks like there's one bp left (api validation) ... it doesn't look very close to merging.  thoughts?13:20
russellbdolphm: you've also got one wishlist bug, want to block on that?13:20
*** radez_g0n3 is now known as radez13:22
*** bknudson has joined #openstack-keystone13:29
*** ukalifon1 has joined #openstack-keystone13:31
*** bklei has quit IRC13:34
*** lbragstad has joined #openstack-keystone13:42
*** lbragstad has quit IRC13:43
*** lbragstad has joined #openstack-keystone13:43
*** ajayaa has quit IRC13:45
dolphmrussellb: o/13:48
dolphmrussellb: hoping to get the primary patch on api validation merged today - the rest can wait for j3 if necessary (they're also much simpler)13:48
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/10621013:48
russellbdolphm: o/13:48
russellbdolphm: ok, cool13:48
dolphmrussellb: the wishlist bug i believe already merged, but maybe the bot was asleep13:48
*** gabriel-bezerra has quit IRC13:48
dolphmrussellb: i'll correct the status if os13:49
dolphmrussellb: or push it13:49
russellbfor api validation, are you referring to https://review.openstack.org/#/c/86483/ ?13:49
russellbthat you want to get in?13:49
*** gabriel-bezerra has joined #openstack-keystone13:50
russellbdolphm: yeah, i don't see a bot update on the bug at least13:50
russellblast was just you saying "Moved to wishlist since we haven't merged a working per-domain-identity backend implementation yet."13:50
dolphmrussellb: updated the wishlist bug13:51
russellbanother bug down13:51
russellbdolphm: i'll keep an eye out on the api validation patches, and will sync with you again tomorrow13:52
russellbfeel free to ping me anytime if there's anything i can do13:52
dolphmrussellb: ack13:52
*** bklei has joined #openstack-keystone13:53
morganfainbergdolphm, just commented on the API validation base impl patch13:54
morganfainbergdolphm, but tbh, i'd be fine with it going in as is.13:54
openstackgerritDolph Mathews proposed a change to openstack/identity-api: revise stability deadline to end of j3  https://review.openstack.org/10870113:54
morganfainbergdolphm, also issued a recheck, looks like the console logs got stupid.13:54
morganfainbergunrelated to implementation validation: https://review.openstack.org/#/c/102041/ this *isn't* related to the revoked call itself, some other call is doing that (probably a mass token revocation on a regular interval)13:55
dolphmmorganfainberg: i'm fine to improve the error feedback later, but wanted to take a quick stab at getting something more useful out of jsonschema this morning13:56
morganfainbergdolphm, i'll rescind my -1 if you think the add index migration isn't something that operators will balk at, but i really would rather not migrate the token table at this point.13:56
hrybacki_morganfainberg: are Jamie's comments (at the bottom of https://review.openstack.org/#/c/108210/) referring to the same script you were yesterday?13:56
morganfainbergdolphm, ++, sounds good, ping me when you want me to poke at that validation impl again13:56
dolphmmorganfainberg: well, if that's your concern, justin is an operator lol13:57
morganfainbergdolphm, true.13:57
morganfainbergdolphm, i *really* don't want to touch the token table :P13:57
morganfainbergi would also rather know why that query is being made that often not assume it is because revoked call is bad.13:58
* morganfainberg is about at the limit of digging into it for the sake of not migrating the token table.13:58
dolphmmorganfainberg: just truncate the table first :P13:59
morganfainbergdolphm, LOL13:59
stevemarso silly question, if i have a session object for keystoneclient, how can i get a 'client', so i can list projects and such?14:00
morganfainberghrybacki_, no jamie is saying regenerate the sample cms files as well14:00
dolphmmorganfainberg: but seriously, i wouldn't mind a truncate operation between every major release; i'll put it in the release notes as "reduced disk usage by several petabytes"14:00
morganfainberghrybacki_, if you follow the steps he put in the comment and include that in the commit it should resolve his -114:01
morganfainbergdolphm, that would work for me.14:01
hrybacki_morganfainberg: ++14:01
hrybacki_thank you!14:01
dolphmstevemar: there's docs!14:01
morganfainbergtruncate keystone.assignment -- ooops14:01
morganfainbergdolphm, if we're going to do that lets do that *before* this migration.14:02
dolphmstevemar: or maybe just docstrings14:02
stevemardolphm, do you know where either are located?14:02
dolphmstevemar: but basically pass the session to a client object14:02
stevemardolphm, right, i thought it was something like that14:03
dolphmstevemar: usage documentation *should* be here: http://docs.openstack.org/developer/python-keystoneclient/ (wink wink jamielennox|away)14:03
dolphmbut there's not, so i can't advocate for anyone to use sessions14:03
fish_hrm, I want to use barbican and authenticate against keystone. things start to make sense slowly but now I'm stuck because barbican setup scripts expect a admin role which I don't have. any docs on how to create that?14:04
*** nkinder has joined #openstack-keystone14:04
dolphmmorganfainberg: also, i've spent like 6 hours over the last few days digging into build failures in jenkins logs... all the ones i've looked at (no matter how they bubble up to tempest) seem to be caused by message delivery failures14:05
marekddolphm: stevemar morganfainberg: appreciate your eyes on this: https://review.openstack.org/#/c/108611/1/specs/juno/keystone-websso.rst14:05
morganfainbergdolphm, like celiometer not getting a message from nova?14:05
stevemardolphm, i'll toss something up today for that, in meetings for the next few hours :\14:05
dolphmmorganfainberg: is nova-agent on the bus?14:05
stevemarmarekd, it's already an open tab in chrome, it'll get looked at today14:05
morganfainbergdolphm, think so.14:05
dolphmmorganfainberg: that's kind of what it looked like, but i don't know nova well enough to say14:06
morganfainbergdolphm, not 100% sure.14:06
marekdstevemar: sure. I didn't include required changes for django-openstack-auth, do horizons have their specs?14:06
*** chandankumar has joined #openstack-keystone14:06
dolphmmorganfainberg: nova trying to send messages *somewhere*, and giving up the boot when message delivery failures occurred14:06
stevemarmarekd, i believe they do14:07
morganfainbergquick sanity check: Model for unifying token v2 and v3 (similar to what is in keystoneclient, eventually to be aligned between the two) - should that go in keystone/models/keystone_token.py or in keystone/token/models.py14:07
morganfainbergstevemar, dolphm, ^14:07
dolphmmorganfainberg: anyway, i'm almost wondering if the majority of our gate failures are caused by rabbit14:07
dolphmmorganfainberg: the second14:07
morganfainbergdolphm, wouldn't surprise me. rabbit in some configurations is awful.14:07
morganfainbergdolphm, ++ that was what i was thinking.14:07
morganfainbergwonder if kombu or rabbit went stupid on us14:08
dolphmmorganfainberg: know if zeromq is more reliable?14:08
morganfainbergdolphm, last i heard zeromq was not very reliable in OpenStack14:08
dolphmmorganfainberg: i just mean zeromq itself14:09
dolphmmorganfainberg: support is broken in icehouse, afaik14:09
morganfainbergmy experience with zeromq has been headaches with saltstack14:09
morganfainbergso i don't know overall reliability14:09
dolphmmorganfainberg: lol14:10
dolphmmorganfainberg: re-reading this bug https://bugs.launchpad.net/keystone/+bug/1332666 ...14:11
uvirtbotLaunchpad bug 1332666 in keystone "Keystone token poor performance. Need index on user_id" [Medium,In progress]14:11
dolphmmorganfainberg: that query should never be emitted for GET /v3/revoked, right?14:11
dolphmerr /v2.0/revoked14:11
morganfainbergas far as i can tell, we don't do that query on /v2.0/revoked14:11
dolphmthat just looks like token validation to me14:11
morganfainbergexcept, i am not seeing that query on token validation either14:11
morganfainbergthe only time we do a filter by user_id is on delete_tokens14:12
*** gabriel-bezerra has quit IRC14:12
*** gabriel-bezerra has joined #openstack-keystone14:12
morganfainbergwhich would imply some kind of revoke tokens for user / trust / etc14:12
dolphmmorganfainberg: are you running with uuid?14:13
stevemarmorganfainberg, the second option14:13
dolphmmorganfainberg: but it's not a delete..? unless we're doing a select & delete :(14:13
morganfainbergshouldn't matter, .get_token() is by token id which is indexed14:13
dstanekcatching up..... dolphm: i don't think zmq has the reliability of rabbit14:13
stevemarmarekd, ping?14:14
dolphmdstanek: i.e. it's worse than rabbit?14:14
*** cjellick has joined #openstack-keystone14:14
*** cjellick has quit IRC14:15
morganfainbergdolphm, yeah i don't know why they've correlated /v2.0/revoked to what amounts to a delete_tokens call. something is wonky with that bug report.14:15
*** gabriel-bezerra has quit IRC14:15
dstanekdolphm: in my experience it's much faster for realtime messaging - but doesn't have all of the reliablilty/clustering14:15
dstanekdolphm: depends on your usecase14:15
*** gabriel-bezerra has joined #openstack-keystone14:15
*** cjellick has joined #openstack-keystone14:15
marekdstevemar: ding dong14:16
dolphmdstanek: that was basically my intuition, but i don't know a damn thing about it14:16
dolphmif anyone uses ack, i just discovered -Q and <314:17
*** andreaf_ has quit IRC14:17
*** andreaf has quit IRC14:17
*** andreaf has joined #openstack-keystone14:18
lbragstadper the api validation discussion: http://paste.openstack.org/show/87619/14:18
lbragstadthose ^ are the values provided in the exception that dstanek mentioned14:18
stevemarmarekd, trying to use your list projects and domain patch14:18
*** ukalifon1 has quit IRC14:19
marekdstevemar: ++14:19
stevemari'm creating a client based on the session of an unscopedsamlplugin, is that the right idea?14:19
marekdstevemar: i think so. the idea here is to store unscoped token and later send it in X-Auth-Token in the HTTP header14:20
stevemarmarekd, did you get it working in your env?14:21
stevemarmarekd, http://paste.openstack.org/show/87621/14:22
dolphmwhy have we defined a private method in the token persistence driver interface lol14:22
marekdstevemar: hmm, let me see that.14:23
dstaneklbragstad: is that the jsonschema exception you are dissecting?14:23
lbragstaddstanek: yep14:23
lbragstadex.instance is what ever the user put in14:24
lbragstadthat failed the validation14:24
dstaneklbragstad: i'm not really sure what to do here, but it would be nice to give the user as much information as possible14:26
lbragstaddstanek: I agree14:27
*** mrmoje has joined #openstack-keystone14:27
*** andreaf_ has joined #openstack-keystone14:28
*** andreaf_ has quit IRC14:28
lbragstadright now, we try to pull out the property that failed validation and the value (ex.instance)14:28
lbragstadif we can't do that, we just pass the message,14:28
*** topol has joined #openstack-keystone14:29
lbragstadwhich is pretty much the same thing.14:29
lbragstaddstanek: morganfainberg had a suggestion that might be an option too?14:31
dstaneklbragstad: yeah, i agree with morganfainberg's comment on handling at the wsgi layer - beyond that i don't know how to present that information14:33
dstaneklbragstad: someone must have an example of really good error messaging14:33
lbragstaddstanek: I used a similar format to what nova's v3 api had14:34
lbragstadI think I changed it though, based on bknudson's comment in the spec14:34
*** david-lyle has joined #openstack-keystone14:35
bknudsonto be consistent with other error messages it should be mostly useless.14:35
* lbragstad ba dum pshh14:36
dstanekbknudson: i nearly spit out my coffee just now14:37
stevemarclassic bknudson14:44
*** bvandenh has quit IRC14:45
*** lbragstad has quit IRC14:46
dstanekmorganfainberg: after our conversation at the summit i was motivated to crank out a real quick prototype of a jsonschema object model14:46
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: CRUD grant don't check user_id and group_id  https://review.openstack.org/10797314:48
*** chandankumar has quit IRC14:48
*** tziOm has quit IRC14:49
openstackgerritA change was merged to openstack/identity-api: Update OS-EP-FILTER API  https://review.openstack.org/10629214:49
dolphmbknudson: hat tip, sir14:50
dolphmdstanek: it looks like ex.message is sufficient to me14:51
*** tziOm has joined #openstack-keystone14:51
*** vhoward has joined #openstack-keystone14:52
*** thedodd has joined #openstack-keystone14:54
*** ayoung has joined #openstack-keystone14:55
*** lbragstad has joined #openstack-keystone14:56
dstanekI'm totally fine with that. I have one more issue left in that before I +2.14:56
dstanekdolphm: i remember seeing a comment from you about adding py3 testing support...do we want that here?14:56
*** shausy2 has quit IRC14:57
lbragstaddstanek: speaking of py33, I added test_validation.py to those tests,15:02
lbragstadbreaks on i18n15:02
dolphmdstanek: i was going to put up a patch to enable py3 and see what broke. i have py34 here so tox balks for me now :(15:02
dolphmneed a vm...15:02
dolphmlbragstad: i didn't see py33 issues outside of test_validation, so i'm fine to skip it for the moment and add later15:03
lbragstaddolphm: http://logs.openstack.org/83/86483/29/check/gate-keystone-python33/908ce52/console.html15:03
lbragstadyeah, it only looks like i18n stuff15:03
dstanekdolphm: i just added a py33 issue to the review15:03
dstanekotherwise i'd +2 it now15:03
dolphmlbragstad: oh that's a strange failure though...15:03
dolphmmorganfainberg: you good with skipping i18n for now? ^15:04
dolphmerr skipping py33 support in test_validation15:04
lbragstaddstanek: I'll respin15:04
dstaneki can post a patch in a few minutes to get it working on py3315:04
lbragstadnothing else in py33 testing uses i18n?15:04
dolphmlbragstad: that failure doesn't look like your fault15:04
dstaneklbragstad: probably not15:04
dolphmlbragstad: can you repro that locally?15:05
lbragstadwell, we are using i18n in the validation module15:05
lbragstadI'd need to set up a py 33 env15:05
*** chandankumar has joined #openstack-keystone15:07
*** richm has joined #openstack-keystone15:07
*** joesavak has joined #openstack-keystone15:08
dstanekit looks like introducing i18n creates failures in other places15:09
dstaneklbragstad: are you planning to respin because of my comment? i think i can retract my -1 and fix the py3 issue in another patch15:13
dstaneklbragstad: you've opened a can of worms for me15:13
morganfainbergdolphm, yeah good with skipping i18n if needed.15:13
lbragstaddstanek: :)15:13
lbragstaddstanek: I can respin my review15:14
dstaneklbragstad: no need for me15:14
lbragstadbuilding a py33 virtualenv at the moment15:14
dolphmdstanek: morganfainberg: +2 from me then https://review.openstack.org/#/c/86483/15:15
dolphmlbragstad: if this starts gating, be sure to propose subsequent patches with --no-rebase to avoid resetting the gate15:16
dolphmlbragstad: subsequent patches to dependent reviews*15:16
morganfainbergdolphm, dstanek, lbragstad, +2 from me provided dstanek is ok with it15:16
lbragstaddolphm: sounds good15:17
morganfainberg(I didn't +A)15:17
dstanekmorganfainberg: i just commented on all of the things and gave it a +215:17
morganfainbergdstanek, cool15:17
lbragstadit will be easier to do the dependent patches now, since they don't all have to be linear15:17
nkinderany cores (other than morganfainberg) care to give a quick review to https://review.openstack.org/#/c/103325/ ?15:17
morganfainbergdstanek, dolphm, just hit +A15:17
nkinder...not that I don't like morganfainberg.  He's just reviewed it already. ;)15:17
lbragstadnkinder: I was taking a look at that yesterday,15:17
nkinderlbragstad: cool.  Any questions on anything?15:18
morganfainbergnkinder, awww. *sniffle* I liked the implication you just didn't want my input :P15:18
lbragstadnkinder: not off the top of my head, I think it looks good, I was going to defer to someone who has a little more ldap knowledge than myself15:18
*** gabriel-bezerra has quit IRC15:18
* morganfainberg might be a bit loopy looking at token code -- without coffee15:18
morganfainberglbragstad, this one is less about ldap and more about NoneType.lowere() desn't work15:19
*** gabriel-bezerra has joined #openstack-keystone15:19
*** tziOm has quit IRC15:19
morganfainberglbragstad, the attributes explicitly mapped to None are always going to be None in the dict, so calling .lower() on them raises an exception15:19
morganfainbergsince they're not a string value15:19
morganfainbergrevert the changes to the ldap.core15:20
morganfainbergand run the new test15:20
morganfainbergyou'll see how it fails15:20
morganfainbergit's consistent fake ldap or normal ldap (doesn't have anything to do with ldap in this case, just with our attribute mapping)15:20
*** tziOm has joined #openstack-keystone15:21
*** thedodd has quit IRC15:29
nkinderlbragstad: yeah, what morganfainberg says is correct15:29
*** thedodd has joined #openstack-keystone15:32
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Endpoint policy extension  https://review.openstack.org/9984215:39
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Endpoint policy extension  https://review.openstack.org/9984215:43
henrynashayoung: I’m not sure if I have misunderstood what you had in mind for endpoint policy…..see what you think of the spec I just posted: https://review.openstack.org/9984215:44
ayounghenrynash, anything will be an improvement.  Looking now15:45
ayounghenrynash, "set of endpoints"  I assume that is just an implicit set, and not a new entity we are creating.  Right?15:46
henrynashayoung: you mean liek a region? If so, yes15:46
henrynashayoung: I AM proposing a group of endpoints…basically re-using the work on endpint filtering15:47
henrynashayoung: which was the real thing I was concerned about…since that didn’t seem to be what you had been thinking15:47
ayounghenrynash, hmmmm.  We already have another form of endpoint grouping going in.  it is going to get confusing, as one endpoint could be in multiple groups15:47
ayoungand the same is true of "sets"15:47
ayoungwe need a way to unambiguosly say "this is the right policy for this endpoint"15:48
henrynashayoung: I don’t mean to use the same phyiscal groups15:48
openstackgerritHarry Rybacki proposed a change to openstack/keystonemiddleware: Example JSON files should be human-readable  https://review.openstack.org/10821115:48
ayounghenrynash, lets maybe turn the terminology around15:48
ayoungcall them policy groups?15:48
henrynashayoung: Ok15:48
ayoungand a policy group covers services and endpoints?15:49
henrynashayoung: yes15:49
ayoungan endpoint will always resolve to a single policy group15:49
henrynashayoung: yes15:49
ayoungwe have a default policy group, and explicit assignment15:49
ayounganything more implicit will be added later15:49
henrynashayoung: I think we should allow region15:49
henrynashayoung: I think you said that an endpoint can be in more than region, but I didn’t udnerstand that…15:50
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Example JSON files should be human-readable  https://review.openstack.org/10821015:50
ayounghenrynash, if an endpoint cannot be assigned to multiple regions, then regions are the right abstraction.  I didn't think that was true, though15:50
henrynashayoung: I don’t think taht was true15:50
henrynashayoung: well an endpoint has a single regon_id field15:50
ayounghenrynash, that might work15:51
ayoungif we say that is the primary region, and only the primary region is covered buy the policy15:51
ayounghenrynash, I'd like to run any region type stuff past Jay Pipes, but I think policy and regions would be a natural combination if we can make it clean15:52
henrynashayoung: sounds liek a good thing to do15:52
bknudsontrying to run tests for havana and all the keystoneclient tests are failing because stevedore isn't installed.15:53
ayounghenrynash, join #openstack-dev and we'll see if we can find Pipes.15:53
dstanekif anyone has a few minutes to kill i have a few easy reviews starting at https://review.openstack.org/#/c/108405/15:55
lbragstaddstanek: what was the issue with https://review.openstack.org/#/c/108406/1/tox.ini ?16:00
henrynashayoung: sorry,I need to drop off…but this looks like a godod direction…I’ll be back on later16:01
ayounghenrynash, I'll comment about regions on the review16:01
bknudsontests pass when I add stevedore to test-requirements.txt16:01
bknudsonI picked a victim to recheck no bug in stable/havana gerrit... will post the change to stable/havana if it fails the same way16:02
dolphmproposed renaming the Identity program to the TripleA program, and adopting pycadf https://review.openstack.org/#/c/108739/16:02
dolphmtopol: morganfainberg: ^16:03
topoldolphm, COOL!!!16:03
morganfainbergdolphm, ++ would we also adopt policy under that rename?16:03
morganfainbergdolphm, or does policy still fall outside of AAA?16:03
henrynashdolphm: sorry, I will miss the irc meeting tonight..will be in transit16:03
dolphminterestingly, there are only 8 contributors to openstack/pycadf with about 60 commits16:04
morganfainbergsince policy is part of authorization16:04
dolphmmorganfainberg: policy is still incubated in oslo16:04
morganfainbergdolphm, right, i mean planning wise16:04
morganfainbergdolphm, policy should graduate in Kilo16:04
dolphmmorganfainberg: if we want to push for it to be released, i think it'd make sense to move it to triplea16:04
*** hrybacki_ is now known as hrybacki16:04
dolphmhenrynash: ack16:05
topoldolphm I have Tong Li on my team maintaining pycadf and giving it love and care now16:05
morganfainbergdolphm, yah, i want it graduated in Kilo, i think it's another library that could be really ugly to get updates out in the case of a CVE16:05
* lbragstad keeps reading triplea as tripleo 16:05
dolphmtopol: as of recently? they're not on my list of 816:05
morganfainbergor some gap (not that i see it at the moment)16:05
bknudsonwe should be major league not triple a16:05
dolphmbknudson: lol.16:06
topoldolphm, yes he picked it up for me when Gordon left IBM16:06
bknudsonGordon doesn't get to work on it anymore?16:06
topolbknudson, he does16:07
dolphmtopol: my list of 8, fwiw http://pasteraw.com/g0ztedxpamkal4xnhdvk1aavg5dx7no16:07
topolbknudson but I dont give him direction any more16:07
dolphmgordon has definitely contributed the most16:08
topoldolphm and I suspect he will continue to do so16:08
morganfainbergdolphm, commented on the patch ^16:08
ayoungdolphm, do you have any real objection to https://review.openstack.org/#/c/107873/  or is just that you want better documentation?  I left the exisitng mechanism in place (the one that allows for defining a Method by Python classname)  becuase it was there, and the tests use it, but I would have probably preferred to yank it.  I kept that patch minimal, but there is nothing  different in the documentation of what is supported, jus16:08
ayoungt that we don't *force* a method attribute onto a plugin any more.16:08
morganfainbergdolphm, i'm in support of it16:08
ayoungIf you want to go further, I'm all for it, but this is a minimal viable patch.16:09
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove `with_lockmode` use from Trust SQL backend.  https://review.openstack.org/9705916:10
dolphmayoung: pulling the existing approach would break backwards compatitiblity16:10
dolphmayoung: and yes, it just needs docs16:10
topoldolphm, saw your list. yes Tong will start showing up on the contribution list16:10
*** gabriel-bezerra has quit IRC16:10
dolphmayoung: you can deprecate the existing approach if you feel that's appropriate16:10
dolphmtopol: same list by commits http://pasteraw.com/ibz6ahxd9ql8yytw7sh0ef8u35hjdwz16:10
*** gabriel-bezerra has joined #openstack-keystone16:11
topoldolphm. yep. make sense.16:12
dolphmtopol: where did gordon go btw?16:12
topoldolphm enovance now red hat16:12
topoldolphm, so I am happy keystone is going to adopt pycadf and just want to let you know we will continue to support/maintian it. thats all16:15
morganfainbergdolphm, for specs, we should answer Kristy's question, how do we mark a spec as "review for K"? https://review.openstack.org/#/c/100279/16:16
morganfainbergmake a kilo directory and have it targeted there (and just linger until we're ready?)16:17
* dolphm is second guessing this whole TripleA thing because i type "TriplaA" half the time16:17
dolphmmorganfainberg: ++ make a kilo dir16:17
dolphmmorganfainberg: ooooOOOOoh16:17
topoldolphm :-)16:17
*** xianghui has quit IRC16:20
*** mrmoje has quit IRC16:21
*** afazekas has quit IRC16:21
*** marcoemorais has joined #openstack-keystone16:22
morganfainbergdolphm, http://triplea.sourceforge.net/mywiki16:22
dolphmmorganfainberg: yeah we're adopting that too16:22
dolphmmorganfainberg: and changing the license from GPL16:23
morganfainbergright ASLv216:23
*** tomoiaga has quit IRC16:28
topolso dolphm, will you make an announce on the mailing list regading tripleA?16:29
dolphmtopol: i'd like to have two smaller discussions first - one in our #openstack-meeting and one in oslo's meeting (since we'd be moving pycadf)16:30
dolphmtopol: then raise to the mailing list, then ask for TC blessing16:30
topoldolphm, SOUNDS GREAT!!!16:31
*** gyee has joined #openstack-keystone16:34
*** lbragstad has quit IRC16:35
openstackgerritA change was merged to openstack/keystone: Initial implementation of validator  https://review.openstack.org/8648316:36
openstackgerritA change was merged to openstack/keystone: Implicitly ignore attributes that are mapped to None in LDAP  https://review.openstack.org/10332516:37
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/10620816:40
*** dims has quit IRC16:46
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy  https://review.openstack.org/10101716:46
*** thedodd has quit IRC16:48
*** thedodd has joined #openstack-keystone16:49
*** lbragstad has joined #openstack-keystone16:51
*** lbragstad has quit IRC16:52
openstackgerritArun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling.  https://review.openstack.org/9530016:52
*** hrybacki has quit IRC16:56
*** thedodd has quit IRC17:01
openstackgerritA change was merged to openstack/keystone: Regenerate sample config file  https://review.openstack.org/10840517:03
openstackgerritA change was merged to openstack/keystone: Fixed tox cover environment to share venv  https://review.openstack.org/10840617:04
*** lbragstad has joined #openstack-keystone17:05
openstackgerritA change was merged to openstack/keystone: Adds coverage report to py33 test runs  https://review.openstack.org/10840717:05
stevemarmarekd, ping?17:05
*** amerine has quit IRC17:13
*** amerine has joined #openstack-keystone17:13
marekdstevemar: hey17:16
marekdsorry, had to leave for an hour.17:16
marekdi am looking at this error, i recall i had it working.17:17
stevemarmarekd, np, did you get back to my question? about using the project list? i was in a bunch of meetings17:17
marekdstevemar:  ^^17:17
dstanekhow do you 'unstick' a review? just post a comment? https://review.openstack.org/#/c/102735/717:17
marekddstanek: from the next-review? :P17:18
*** harlowja_away is now known as harlowja17:19
dstanekah, nm - rebase will likely fail now anyway17:22
arunkantayoung and AAA core: Made some change on https://review.openstack.org/95300 based on earlier review comments..can you please review it17:22
dstanekmarekd: :-P17:28
openstackgerritA change was merged to openstack/keystone: Mark the 'check_vX_token' methods deprecated  https://review.openstack.org/10756017:28
*** gokrokve has joined #openstack-keystone17:29
marekddstanek: i sometimes have the same problem :P17:30
marekd(if your question was about next-review :P)17:31
ayoungarunkant, I'd like to let Yorik give it a thumbs up regardless.  It looks like he put a lot of effort in to reviewing it.  I'm not nearly as picky as many other people,  so I'm sure if h likes it, I'll be OK with it.17:32
ayoungarunkant, its on my list of starred reviews, though.  I'll keep an eye on it17:32
*** htruta has joined #openstack-keystone17:33
dstaneklbragstad: i think these last few patches will go much faster now that the approach is solidified in your original commit17:34
*** chandankumar has quit IRC17:34
lbragstaddstanek: agreed, working on the assignment validation patch now17:34
dstaneklbragstad: cool, i'm looking at the next one17:34
lbragstaddstanek: thanks for the reviews, I appreciate it17:35
*** gabriel-bezerra has quit IRC17:35
*** gabriel-bezerra has joined #openstack-keystone17:35
dstaneklbragstad: what is the reasoning behind having parent_region_id either a string or null?17:40
lbragstadparent_region_id can be null,17:40
arunkantthanks ayoung. I was hoping to get core reviewer(s) blessing on this as well. Will keep addressing any further comment Yuriy may have.17:41
dstaneklbragstad: is that not true of the other optional fields?17:42
lbragstaddstanek: digging17:44
dstaneklbragstad: to me that implies that parent_region can be a string, null or left out entirely17:45
lbragstadi think, if we wanted to only have parent_region_id be of type 'string'17:46
lbragstadvalidation would still work if we didn't provide parent_region_id in the request,17:46
lbragstadand if we did provide a string as the parent_region_id17:46
lbragstadbut it wouldn't pass validation if we set parent_region_id = None in the request.17:47
dstaneklbragstad: exactly17:47
dstaneklbragstad: i was looking in the v3 docs to see if there was something may be this one different, but couldn't find anything17:47
lbragstadso, I'll fix that to fail validation if parent_region_id is None17:48
dstaneklbragstad: it's probably more correct than some of the others because that's what you need to do in an update to clear the field17:48
lbragstadif parent_region_id is provided in the request, it must be a string17:48
lbragstaddstanek: oh, pass in None...17:49
dstaneklbragstad: right, that's why i think you need to to be a string or a null17:49
lbragstadok, so apply that to other optional arguments17:49
lbragstadto allow a user to pass in None to clear the field17:50
lbragstaddstanek: that is what you mean right?17:52
*** rodrigods has joined #openstack-keystone17:52
openstackgerritArun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling.  https://review.openstack.org/9530017:54
dstaneklbragstad: yes, we should probably have a test case showing that behavior17:56
lbragstaddstanek: ok, I'll get that added.17:56
*** gokrokve has quit IRC18:00
*** jamielennox|away is now known as jamielennox18:09
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy  https://review.openstack.org/10101718:12
*** gabriel-bezerra has quit IRC18:15
*** gabriel-bezerra has joined #openstack-keystone18:16
afaranhaWhats the difference between Grant and RoleAssignment, in keystone the method list_grants only reads from the db and returns the role assignment, and the get_roles_for_user_and_project gets the projects that an user has a role but using _get_metadata. What's the difference between both? Can we just migrate get_roles_for_user_and_project to list_grants?18:19
*** bklei has quit IRC18:25
*** thedodd has joined #openstack-keystone18:27
*** lbragsta_ has joined #openstack-keystone18:27
*** lbragstad has quit IRC18:30
*** dims has joined #openstack-keystone18:30
*** lbragsta_ has quit IRC18:31
*** nkinder has quit IRC18:32
*** lbragstad has joined #openstack-keystone18:32
*** mrmoje has joined #openstack-keystone18:33
*** marcoemorais has quit IRC18:33
*** lbragstad has quit IRC18:34
*** lbragstad has joined #openstack-keystone18:34
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain  https://review.openstack.org/10719418:35
*** lbragstad has quit IRC18:39
*** lbragstad has joined #openstack-keystone18:40
*** afazekas has joined #openstack-keystone18:44
*** nkinder has joined #openstack-keystone18:44
*** shakamunyi has joined #openstack-keystone18:56
*** marcoemorais has joined #openstack-keystone18:57
*** david-lyle has quit IRC18:59
*** kwss_ has joined #openstack-keystone19:00
*** lbragstad has quit IRC19:03
*** marcoemorais has quit IRC19:07
*** lbragstad has joined #openstack-keystone19:08
*** marcoemorais has joined #openstack-keystone19:08
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds several more test modules that pass on Py3  https://review.openstack.org/10273519:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes test_exceptions.py for Python3  https://review.openstack.org/10273719:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes test_wsgi for Python3  https://review.openstack.org/10273619:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Disables LDAP unit tests  https://review.openstack.org/10880819:11
openstackgerritDavid Stanek proposed a change to openstack/keystone: Reduces the amount of mocked imports for Python 3  https://review.openstack.org/10880919:11
openstackgerritDavid Stanek proposed a change to openstack/keystone: Add the new oslo.i18n as a dependency for Python 3  https://review.openstack.org/10881019:11
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes a capitalization issue  https://review.openstack.org/10881119:11
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain  https://review.openstack.org/10719419:13
*** marcoemorais has quit IRC19:13
*** lbragstad has quit IRC19:22
*** lbragstad has joined #openstack-keystone19:24
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: generic-mapping-federation  https://review.openstack.org/10430119:28
openstackgerritA change was merged to openstack/keystone: Updated from global requirements  https://review.openstack.org/10620819:28
*** marcoemorais has joined #openstack-keystone19:31
*** david-lyle has joined #openstack-keystone19:34
dolphmjamielennox: building the milestone now: https://launchpad.net/python-keystoneclient/+milestone/0.10.019:35
marekdstevemar: had time to look at keystone websso?19:35
jamielennoxdolphm: cheers19:35
dstanekbknudson: checking out those comments now19:35
stevemarmarekd, not yet19:35
dolphmmarekd: the second change here hasn't merged- https://blueprints.launchpad.net/python-keystoneclient/+spec/add-saml2-cli-authentication19:36
dolphmmarekd: is it necessary for the bp?19:36
marekdstevemar: understood. i was just hoping for live commit-comment-commit ping-pong.19:36
marekddolphm: let me check.19:36
gyeekwss, you have the code for generic mapping I can look at?19:36
dolphmmarekd: it looks like the answer is yes19:37
marekddolphm: plugins are technically indepdent, but functionally unscoped token only is pointless.19:37
dolphmjamielennox: this patch is why i didn't release last week https://review.openstack.org/#/c/99704/19:38
marekddolphm: ++19:38
jamielennoxdolphm: yea, the SAML stuff is going to be caught a little mid-cycle but that should be ok to say not ready until 0.1119:38
dolphmjamielennox: so you recommend cutting 0.10.0 without https://review.openstack.org/#/c/99704/ ?19:39
dolphmjamielennox: and bumping the bp to 0.11.0 ?19:39
stevemardolphm, i think it's OK to do so, we can always release 0.11.0 when it's ready (or revocation events are ready)19:40
jamielennoxdolphm: oh, wasn't sure if cutting the blueprint was a "it's done" moment19:40
jamielennoxum, if we release 0.11 in a week i don't think it matters19:40
jamielennoxi wasn't sure how close that review was to merging19:40
stevemarkwss_, marekd i don't like the name 'mapped' as a plugin :(19:40
ayoungOK,  what am I missing.  connection = mysql://root:keystone@  but db_syn is erroring out with  "Access denied for user 'keystone'@'localhost' (using password: YES)") None None19:40
kwss_stevemar, noone likes it whatever I call it :( what would you choose?19:41
dolphmjamielennox: you've followed that review closer than i have!19:41
ayoungmapped is the right name stevemar19:41
marekdayoung: --19:41
stevemarkwss_, haha, i dunno external is already taken19:41
jamielennoxdolphm: i had a -1 a few days ago, hadn't seen since19:41
stevemarayoung, meh, it still seems weird19:42
jamielennoxdolphm: i tried to build an environment that i could actually test these out with and failed19:42
jamielennoxso i'm just going on looks19:42
kwss_stevemar, ayoung can we compromise and call it external-mapped? :P19:42
ayoungthe plugins are for authentication methods, though, so I am not certain that the Federation stuff even blongs in there19:42
ayoungkwss_, I've been thinking about this.19:42
*** shakamunyi has quit IRC19:42
dolphmjamielennox: marekd: alright, i'll bump the saml2 cli bp to 0.11.0 and get 0.10.0 onto pypi right now19:42
marekddolphm: makes sense.19:42
gyeestevemar, kwss_, what's wrong with just calling it federated plugin19:42
stevemardolphm, you just made mhu a happy man19:42
ayoungI need to be able to tell the client what to do, hence my current review request to remove the "method" froom the auth plugins19:43
kwss_gyee, ask ayoung lol19:43
stevemargyee, i like federated,19:43
gyeekwss_, you have the url for the code changes for the generic map?19:43
ayoungthe federated plugin basically is saying "I'm going to deliver a handful os standard values"  right?19:43
jamielennoxi thought we'd gone away from trying to jam federation through the existing auth plugins?19:43
jamielennoxmake it it's own apache 'landing page'19:43
ayoungjamielennox, that is my thinking, but I want to get the issue clear here now that we have kwss_ handy19:44
marekdgyee: you are talking about simplified mapping ?19:44
marekdgyee: why would you need that?19:44
kwss_gyee, https://review.openstack.org/#/c/105597/19:44
ayoungkwss_, so in your view, the "federated" plugin would handle  what values?19:44
gyeemarekd, I need it to do the x.509 cert auth19:44
jamielennoxmarekd: it doesn't change the mapping syntax it just makes it more common amongst plugins19:44
gyeeayoung, it handles mapping like what it does today19:44
marekdjamielennox: sorry, i don't follow what topic you are referring to right now ;/19:45
kwss_ayoung, the protocol used, which can then determine how to extract assertion data, then shove whatever comes out through mapping19:45
marekdgyee: but simplified mapping or reengineered federation?19:45
jamielennoxmarekd: the server side mapping one19:45
kwss_ayoung protocol+idp*19:45
ayoungkwss_, "the protocol used" is exactly what the auth plugin mechanism is to do.  That does not belong to "federated"19:45
gyeemarekd, actually I need both19:45
ayoungkwss_, the only thing that I would agree is IdP19:45
marekdgyee, but why simplified mappings?19:46
ayoungIdP is used to look up the mappings.19:46
gyeemarekd, so I can add x.509 as an IdP19:46
ayounggyee, ARGH19:46
kwss_gyee, marekd is talking about a different spec19:46
ayoungno x.509 is not an IdP19:46
*** gabriel-bezerra has quit IRC19:46
marekdjamielennox: ahh, one global mapping ruleset instead of mapping tied to idP?19:46
gyeeayoung, its the same mechanism19:46
kwss_marekd, gyee is talking about applying mapping generically across federation protocols19:46
ayoungit is a mechanism.  If anything should be a method it is "X.509"19:46
gyeefederation is a concept19:47
gyeeI never look at it as a protocol19:47
ayounggyee, It could potentially ber definied by the mapping plugin.19:47
*** gabriel-bezerra has joined #openstack-keystone19:47
jamielennoxmarekd: no i don't think so, just removing the mechanism from saml a bit such that it can be shared by things like X50919:47
marekdjamielennox, gyee: https://review.openstack.org/#/c/100280/ yeah, i thought you wanted this.19:47
marekdwhich was -2d during the hackthathon.19:47
marekdi also started wondering why would you want to have it back.19:48
ayoungright...OK,  kwss_ the only data we need to standardize from a Federation perspective is how to look up the IdP.  That really is not an Authentication  issue, but rather assumes authentication has taken place,  and is the start of the authorization process.19:48
jamielennoxmarekd: no, don't know that one19:48
marekdjamielennox: ack.19:48
marekdjamielennox: anyways, https://review.openstack.org/#/c/99704 i think i addressed your comments here.19:49
ayoungkwss_, did you see the proof of concept I did using the SAML plugin and mod_identity_lookup?  It was an Kerberos authentication19:49
gyeemarekd, lemme take a look at that review again19:49
ayoungIN that case, the "method" should have been Kerberos19:49
marekdalso, regarding that review: https://review.openstack.org/#/c/106751/ i left one comment for you.19:49
marekdjamielennox: ^^19:49
kwss_ayoung, I remember looking at it but do you have a link so I can refresh my memory?19:49
ayoungkwss_, coming right up...19:50
ayoungkwss_, http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/19:50
ayoungits a lot of code, don't try to read the whole thing...19:51
ayounglet me focus you down to where things matter19:51
ayoungkwss_, look for the part "Here is how I fetch a token."19:52
* ayoung needs to do a better job at internal anchors19:52
ayoung'{ "auth": { "identity": { "methods": ["saml2"], "saml2":{"identity_provider":"sssd", "protocol":"kerberos"}}, "scope": { "project": { "domain": { "name": "Default" }, "name": "Castle" } } } }'19:52
kwss_ayoung, so that's roughly what I wanted to do with the federation plugin, except using saml2 for kerberos?19:53
ayoungkwss_,   so that really should just read  "methods": ["kerberos"], "kerberos:{}19:53
ayoungkwss_, for the Kerberos/SSSD/mod_lookup_identity case, the Keystone server already has enough information to look up the idp19:53
gyeemethod should be federated, and IdP is kerberos19:53
jamielennoxmarekd: commented, nit about pulling out _BaseSamlAuth2 - otherwise i'm +219:53
marekdgyee: jamielennox looking.19:53
*** gabriel-bezerra has quit IRC19:53
ayoungI suspect that is the case across the board:  that information does not need to be in the token request itself19:53
kwss_ayoung, so the switching on protocol should happen in the federated extension? where the auth_payload is inserted?19:54
ayoungkwss_, So the "kerberos" method should be mapped to the federated extension19:54
*** CraigALee has joined #openstack-keystone19:54
ayoungkwss_, look at this patch....19:54
*** gabriel-bezerra has joined #openstack-keystone19:54
ayoungkwss_, that means that any "external" authentication method caould then be serviced by the same plugin19:55
ayoungthen the question is reduced down to "what do we do about the identity_provider value?"19:55
jamielennoxayoung: isn't that a seperate issue from federation though?19:56
*** gabriel-bezerra has quit IRC19:56
ayoungI can see passing IdP to the  Federated extension, but by the time the token request comes in, it should be unnecessary, as the SAML (or whatever) is in the environment when the token request comes in19:56
*** gabriel-bezerra has joined #openstack-keystone19:57
* dolphm is finally filling out his expense report for his trip to the valencia19:57
kwss_ayoung, it's needed for mapping though19:57
kwss_ayoung, the federation extension inserts the auth_payload for the authenticate call, I don't see a problem with passing in the idp inside this19:59
jamielennoxdolphm: so about AUTH_INTERFACE, do you see another way around that?19:59
ayoungkwss_, OK,  lets assume for a moment that there is no way around that.  I would still say that is not an authZ issue, or method, but  since that is the only real plugin we have, lets go with it.  What that is saying is "apply the mapping rules from identity_provider="X""  and thus it should be  method="mapping"  mapping: {"identity_provider" :"X"}20:00
kwss_ayoung, currently, the attribute extraction is done in the saml2 plugin, so it needs to know what protocol was used in case the extraction is handled differently20:01
kwss_regardless of what it's named20:01
ayoungSAML would have been unpacked into Environment Variables by the time it hits the mapping plugin.  In the case where SAML is handled in the Keystone server(which, as you recall, I dislike intensely) that would be a separate plugin.20:02
ayoungMapping is common behavior.  SAML is protocol specific20:02
kwss_ayoung, saml is yes but it might not be the case for other protocols20:02
kwss_ayoung, additionally I think we should get the user_id from the asserted data, and this might be set differently depending on the protocol20:03
ayoungkwss_, ok,  lets split this into two:  first, the SAML processing.  This can be handled either externall (mod_shib) or by a plugin inside of Keystone.20:04
ayoungSecond is converting from the values extracted by that process to Keystone values20:05
ayoungthis really needs to be a pipeline.20:05
ayoungTHe Federation stuff has to follow after the unpacking20:05
ayoungand I think we lack an abstraction for that right now....Although we've been saying for years we want the token creation process to be a pipeline20:05
*** lbragstad has quit IRC20:06
raildomorganfainberg: If you have some free time, you could review this spec? https://review.openstack.org/#/c/101017/ :-D20:06
ayoungkwss_, is the "idP" value in the token request a hard and fast requirement, or is it something that can be extracted from somewhere else in the request?20:06
*** hrybacki has joined #openstack-keystone20:07
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel  https://review.openstack.org/10691720:07
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module  https://review.openstack.org/10756120:07
jamielennoxayoung: are we supporting the case where this can be processed within keystone?20:07
ayoungjamielennox, I would say "yes" in the abstract, but not implement that up front20:07
*** lbragstad has joined #openstack-keystone20:08
ayoungjamielennox, I would say that, if Kent wants to support SAML in Keystone, they should be able to do so, but use common Mapping code20:08
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Scope unscoped saml2 tokens.  https://review.openstack.org/9970420:08
marekdjamielennox: ^^ fixed20:08
jamielennoxright, but are you talking about a custom implementation that just does what mod_shib does, or having an auth_plugin for everything20:09
jamielennoxbecause forcing this through auth_methods is bad20:09
kwss_ayoung, if the mapping policy always links to an idp, then we need the idp to perform mapping, I don't care where it comes from, only that we can apply mapping in a standard way regardless of protocols20:09
dolphmjamielennox: https://pypi.python.org/pypi/python-keystoneclient/20:09
jamielennoxdolphm: woohoo!20:09
ayoungjamielennox, I want mod_shib, mod_idenityt_lookup , or whatever, to use the same code in Keystone;  assuming the mapping is done, and take it from there20:09
ayoungbut the mod_id_lookup case would be methods: [kerberos]20:09
ayoungand mod shib soulbe be method: SAML20:10
ayoungmapping is constant.  and needs to happen after authentication20:10
jamielennoxayoung: why does a mod_XXX require a method?20:10
ayoungjamielennox, becuase you said it had to.  You wrote the client plugin model, rmember?20:10
kwss_ayoung, what about other protocols which don't have an apache plugin? should they handle mapping differently?20:10
marekdayoung: but we can make one plugin, that accepts various methods (saml2, kerberos) and loads smaller subplugins.20:11
kwss_marekd, exactly20:11
marekdand the mapping can be left in the outer plugins.20:11
ayoungkwss_, the method is for the client to figure out how to talk to the server as well as codify what data needs  to be delivered.  The server side implementation is hidden from view20:11
jamielennoxayoung: federation is going to have to work completely differently20:11
marekdsomething like kwss_ proposed in re-engineered federation.20:11
ayoungjamielennox, that is why I am trying to extract the mapping part from the rest of the SAML handshake20:11
ayoungmarekd, there are two steps:  one is to unmarshall the variables, and the second is to map them20:12
dolphmjamielennox: so releasing keystonemiddleware will default everyone to use v3 - i'm thinking we should wait until after the milestone for that20:12
ayoungunmarshalling is protocol specific.  Mapping is agnostic20:12
jamielennoxso i said 'kerberos' as the method because we are pushing it through /auth/tokens and we need to be able to look up the correct plugin to load20:12
marekdayoung: ++20:12
ayoungjamielennox, what we need is a way to say "after you go through the set of methiods, run the mapping plugin"20:13
marekdlet's than make one 'wrapper plugin' that includes protocol agnostic characteristics (mapping) and loads, if required, smaller protocol-specific plugins.20:13
ayoungjamielennox, example:  X509 client cert and Kerberos, MFA20:13
dolphmmorganfainberg: we have no hudson bot on keystonemiddleware :(20:13
jamielennoxayoung: so back one step, why does a call to /OS-FEDERATION/identity_providers/{idp}/protocols/{p} go through methods at all?20:14
ayoungClient cert does not need to affect the request body, but does need to set up the HTTPS connection with client cert.  Kerberos needs to set the Negotiate header20:14
*** fausto has joined #openstack-keystone20:14
jamielennoxdolphm: yea, that makes sense to wait, i was going to propose a change to bump global requirements but thought we might want to wait and make sure we didn't break the gate20:14
ayoungthe mapping needs to be smart enough to handle the values that are set by both methods, plus whatever comes from LDAP via mod_lookup_identity20:14
kwss_ayoung, so pull the attribute extraction up to the federated extension which has the protocol/idp and then push it down through mapping and into token creation, ignoring authenticate20:14
ayoungkwss_, well, attribute extension is far more likely to be done in HTTPD via a mod20:15
ayoungmod_uaht_kerb and mod_nss in my case20:15
ayoungmod_auth_kerb and mod_nss20:15
kwss_ayoung, the mapping shouldn't have to have logic to handle multiple protocols, it should just get a set of attributes and map them to keystone groups etc.20:16
morganfainbergdolphm, yeah trying to figure that out, haven't been able to20:16
ayoungkwss_, right...that is why I want that separate from the protocol specific portion.  Mapping is a server side configuration, not something that needs to be explicit in the request20:16
dolphmmorganfainberg: time or infra afk?20:16
morganfainbergdolphm, a little of both20:16
ayoungkwss_, so back to my Proof of concept, look at the keystone.conf section20:17
ayoungI had20:17
ayoungdrop the "external" part20:17
ayoungand replace saml2 with Kerberos20:17
ayoungso it should read something like20:17
kwss_ok, but what if the protocol you want to add doesn't store the attributes in the environment?20:18
ayoungkwss_, then you would need a custom plugin to do that marshalling, so  it would become20:19
*** CraigALee has quit IRC20:19
ayoungmake that20:19
ayoungwith SamlMapped being new code that handles unmarshalling SAML, and then calls the Mapped plugin20:20
kwss_ayoung, so then it has to duplicate the calls to map the attributes, or uses a subclass and the base Mapped class has a map call or something?20:20
ayoungyou need the SAML unmarshalling regardless.  the Mapping then just becomes a reusable resource20:20
ayoungNot duplicate, subclass20:20
ayoungor, we can do it as a pipeline, but that implies that mapping has to happen after SAML, and I would argue that should not be in the "methods" collection.20:21
ayoungAs running Mappiong before SAML would be bogus20:21
ayoungkwss_, I would think that, under the current technology, it would be paste-api  configured20:21
ayoungI could see something like this:20:21
kwss_ayoung, that works for me, it isn't much different, but can we guarantee to get a user_id from the attributes if they are all extracted in the same way?20:21
bknudsondstanek: you were looking at https://review.openstack.org/#/c/102737/ ? otherwise it's fine with me and I'll +A it.20:22
kwss_ayoung, I think we should be able to map on the user_id, which we can't do if the mapping layer determines it20:22
jamielennoxdolphm: so do you know of a solution for AUTH_INTERFACE?20:23
ayoungkwss_, http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini  lets assume we take the /auth suburl out of /main, so that it has its own pipeline20:23
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini#n102  would then have an additional20:23
dstanekbknudson: yes, i was just writing my comment on it20:23
ayoung    /v3/auth = api_v3_auth  or something20:23
ayoungkwss_, then the confitguration for api_v3_auth would be20:23
ayoungstarting with http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini#n87  ...20:24
morganfainbergdolphm, this might be related https://review.openstack.org/#/c/108830/20:24
dolphmjamielennox: slash, do we need an unscoped catalog, right?20:24
dolphmjamielennox: i need coffee and i'll be right back :)20:25
ayoungpipeline = sizelimit url_normalize  xml_body_v3 json_body  auth_filter  mapping_filter  token_signing   auth_v320:25
jamielennoxdolphm: well if we have an unscoped catalog then i don't need to worry about AUTH_INTERFACE at all because there will always be a URL that i can use20:26
dolphmmorganfainberg: oh shit, maybe we can fix identity-api here too! :D20:26
jamielennoxdolphm: that would be great, however we're going to need to be able to use AUTH as a fallback20:26
ayoungkwss_, I wrote a pipeline on a whiteboard back in January.  Looks like this  http://t.co/e8ISv55e3920:26
dolphmjamielennox: but that's only going forward. you still need to consider today's case of no unscoped catalog20:26
jamielennoxdolphm: right20:26
kwss_ayoung, that's pretty hard to read but I get what you're saying I think20:27
ayoungkwss_, but there was no mapping in there.20:27
dolphmjamielennox: /me runs to get coffee, and then i want to walk through what URLs the plugin needs, and what URLs the session needs, and where each should get them20:27
jamielennoxdolphm: yep, was expecting you to go and just reply to these when you got back :)20:28
kwss_ayoung, whether we handle the attribute extraction in the pipeline, or in a subclass of the Mapped plugin, I don't mind, I just have these aims:20:28
ayoungkwss_, cool.20:28
kwss_1. attributes should be extracted separately, and in a protocol specific way (if necessary)20:29
kwss_2. A user_id should be extracted among the attributes, in a protocol specific way (if necessary)20:29
kwss_3. Everything should then go through mapping20:30
*** radez is now known as radez_g0n320:31
ayoungkwss_, ++20:31
*** gabriel-bezerra has quit IRC20:31
kwss_ayoung, if you want to point out where our ideas conflict in the review, I'm happy to make changes, as long as we reach the same point in the end20:32
ayoungkwss_, as I said, "Federated" is not a method, nor is it a protocol, so that needs to go.20:32
kwss_ayoung, I already changed it to mapped20:32
ayoungthe implementation is that "everything goes through mapping"  needs to be clarified:  that is not part of the explicit token request20:33
hrybackijamielennox: I shot you an email with some issues I ran into btw20:33
*** gabriel-bezerra has joined #openstack-keystone20:33
ayoungkwss_, I think that the IdP should be extracted in the mapping section.  I am not convinced it has any place in the token request itself20:33
ayoungthe user shouldnot be telling you what IdP to use20:34
jamielennoxhrybacki: i've seen an email there - i've been saving it till after the run of meetings otherwise i'll forget it20:34
ayoungthat should be deduced from the assertion20:34
hrybackijamielennox: thanks :)20:34
kwss_ayoung, yes I agree, in SAML we should have access to the issuer which should match the IdP ID20:34
*** bklei has joined #openstack-keystone20:35
ayoungkwss_, so we can drop even the mapped plugin.  It will be code implemented by keystone/token/providers/.... , not the auth plugin20:36
kwss_ayoung, I hate to bail on you but I've been working over 12 hours now and I'd like to catch some time with the kid before bedtime, can we continue this tomorrow?20:36
ayoungkwss_, I know how that goes.  I think we are good20:37
ayoungthis was the important point to get across20:37
kwss_ayoung, thanks for the enlightening discussion, I think we're making headway :)20:37
kwss_have a good evening all :)20:37
*** kwss_ has quit IRC20:38
*** gabriel-bezerra has quit IRC20:38
*** gabriel-bezerra has joined #openstack-keystone20:39
dolphmjamielennox: https://etherpad.openstack.org/p/keystoneclient-urls20:39
jamielennoxdolphm: ok...20:43
morganfainbergdolphm, all fixed once tha tpatch merges, just confirmed with fungi20:46
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions  https://review.openstack.org/10883920:48
dolphmjamielennox: pop quiz: name everything the session gets out of the auth plugin?20:48
jamielennoxendpoints and tokens20:50
jamielennoxthere is a slightly recursive nature there in that the auth plugin uses the session to get the token but it shouldn't impact anything20:50
dolphmjamielennox: why should the auth plugin be responsible for scoped tokens?20:50
dolphmjamielennox: those don't vary per auth method20:50
dolphmjamielennox: that's not recursive, that's cyclical!20:51
jamielennoxdolphm: so in the case of horizon for example you want to be able to use one session with multiple auth plugins20:51
jamielennoxthats why you can override auth= on request20:51
jamielennoxdolphm: plugins don't save a reference to the session they just get provided it in case they need to do http calls20:52
dolphmjamielennox: i assume the session provides a reference to itself to the plugin, right?20:53
*** lbragstad has quit IRC20:53
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Hierarchical Projects  https://review.openstack.org/10884120:54
jamielennoxdolphm: yes https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L447-L45420:54
*** david-lyle has quit IRC21:00
dolphmjamielennox: need more of these docs btw, otherwise all this is useless https://review.openstack.org/#/c/108839/21:03
marekddolphm: morganfainberg ayoung: in case you have few spare minutes, please take a look at: https://review.openstack.org/#/c/108611/21:04
dolphmmarekd: are you planning to implement that in juno or K?21:04
marekdi was hoping for juno. there is already something implemented.21:05
jamielennoxdolphm: right, i got the basic ones merged now but i need to red a chuk of the old docs21:05
dolphmjamielennox: red?21:05
marekddolphm: it's more making it 'mergable' (so clean the code) abut prior to that just get YOUR approval.21:05
dolphmmarekd: ack21:06
marekddolphm: see references at the bottom. (we talked about that at the hackathon)21:06
*** lbragstad has joined #openstack-keystone21:06
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions  https://review.openstack.org/10883921:07
*** lbragstad has quit IRC21:08
*** gabriel-bezerra has quit IRC21:14
*** gabriel-bezerra has joined #openstack-keystone21:14
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Hierarchical Projects  https://review.openstack.org/10884121:15
*** lbragstad has joined #openstack-keystone21:19
dolphmjamielennox: so you always have the auth plugin handling token scoping, right?21:21
dolphmjamielennox: even rescoping?21:21
jamielennoxdolphm: scoping happens depending on if you provide project_id/domain_id to the plugin21:22
jamielennoxrescoping is not yet an explicit operation, you can do it with v3.Token21:23
openstackgerritgordon chung proposed a change to openstack/keystonemiddleware: add audit middleware  https://review.openstack.org/10295821:26
dolphmjamielennox: does session instantiate a v3.Token instance itself?21:30
dolphmjamielennox: if not, do you think it should21:30
jamielennoxdolphm: no, there is nothing like that yet21:30
jamielennoxso what are you trying to do21:31
*** david-lyle has joined #openstack-keystone21:31
jamielennoxi've been of the opinion i need a resciope() function for a while21:31
jamielennoxit would essentially be21:31
jamielennoxreturn v3.Token(token=session.get_token(old_plugin), project_id=XXXX)21:31
jamielennoxbut we've never had the concept of automatic scoping21:32
*** shakamunyi has joined #openstack-keystone21:33
*** joesavak has quit IRC21:34
dolphmjamielennox: i'm thinking it shouldn't be an explicit operation21:34
jamielennox... how do you think that will work?21:34
dolphmjamielennox: it should either be a session attribute (session.project_scope or something) or it should be a hidden cache with a bunch of scoped tokens, and exposed as a request method to re-scope ("i want to make this request to this service in this scope")21:35
dolphmjamielennox: so, either i maintain a session per scope myself, or the session has a default scope, and i have to tell it when i want to perform an operation in a different scope?21:35
jamielennoxso i had thought of having session maintain a bunch of plugins, it was decided that having users manage that instead and be able to pass auth= was better21:37
jamielennoxbut i dont know if session scope makes sense21:37
dolphmjamielennox: that's what i'm trying to think through; i don't think the auth plugin should be responsible for scope... if anything, it should try to produce an unscoped token21:38
openstackgerritA change was merged to openstack/keystone: Disables LDAP unit tests  https://review.openstack.org/10880821:38
stevemardolphm, i'm going to use id's, did you want full id's?21:39
dolphmjamielennox: an unscoped token is basically the output of authentication, where there is no authorization; the session should be responsible for turning established authentication into actionable authorization21:39
dolphmstevemar: instead of project_name = 'demo' ?21:39
jamielennoxsession is generally just transport21:40
dolphmstevemar: rewrite the doc later :P follow it's conventions first21:40
dolphmjamielennox: well it's a proxy for transport, right?21:40
dolphmjamielennox: it wraps a request with authN/Z and sends it on it's way21:41
*** david-lyle has quit IRC21:41
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions  https://review.openstack.org/10883921:41
jamielennoxbut that doesnt lend itself to dealing with scoping of auth right?21:41
openstackgerritA change was merged to openstack/keystone: Reduces the amount of mocked imports for Python 3  https://review.openstack.org/10880921:42
openstackgerritA change was merged to openstack/keystone: Adds several more test modules that pass on Py3  https://review.openstack.org/10273521:42
*** zzzeek has joined #openstack-keystone21:42
openstackgerritA change was merged to openstack/keystone: Fixes test_wsgi for Python3  https://review.openstack.org/10273621:42
zzzeekhi, is rodrigo duarte here ?21:42
openstackgerritA change was merged to openstack/keystone: Fixes test_exceptions.py for Python3  https://review.openstack.org/10273721:42
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel  https://review.openstack.org/10691721:43
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel  https://review.openstack.org/10691721:43
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module  https://review.openstack.org/10756121:43
dolphmjamielennox: why not?21:45
*** david-lyle has joined #openstack-keystone21:46
dolphmjamielennox: i need usage docs to illustrate where we're at in terms of use cases like "i want to make the same sequence of requests with 3 different projects"21:47
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: SAML2 wrapper plugin for full federation authN  https://review.openstack.org/10675121:51
*** bklei has quit IRC21:51
marekdjamielennox: stevemar: I wanted to talk about this review: https://review.openstack.org/#/c/107231/ . It's okay to remove it from setup.cfg so it cannot be a standalone plugin, but i'd rather leave get_options() as I am using this method within a wrapper plugin in https://review.openstack.org/106751 .21:52
dolphmlbragstad: /me comes up for air21:55
dolphmlbragstad: have updates for api validation? anything i can do to help?21:55
lbragstaddolphm: got pulled in a few meetings, working on the assignment api patch,21:56
*** shakamunyi has quit IRC21:56
dolphmlbragstad: i'm not doing anything else but api-validation until we cut juno-2 =) let me know what i can do21:56
lbragstaddolphm: what about dstanek's comment here.21:56
lbragstadfirst comment21:56
*** amcrn has joined #openstack-keystone21:57
dolphmlbragstad: did you cut the hex_uuid validator?21:57
lbragstadI can push a patch to parameter_types.py that will essentially consist of 'type': 'string'21:57
dolphmparameter type*21:57
dstaneklbragstad: i noticed a lot of duplication because of the id types21:57
dolphmlbragstad: actually, when would we be validation IDs?21:57
*** topol has quit IRC21:58
dolphmlbragstad: on POST /v3/regions we allow user-defined IDs, and a couple calls in OS-FEDERATION, but i think that's it21:58
*** gabriel-bezerra has quit IRC21:58
dolphmthere's like 3 total21:58
dstanekdolphm: foreign key ids too21:58
dolphmdstanek: aah.21:58
dstaneklbragstad: nice job btw ... i like the pattern for how this works21:59
*** gabriel-bezerra has joined #openstack-keystone21:59
dolphmlbragstad: dstanek: how about this then? '^[a-zA-Z0-9-]*$'21:59
dolphmdstanek: ++21:59
lbragstaddstanek: thanks!22:00
lbragstaduuid, I want to say there is a jsonschema format validator for that22:00
*** gabriel-bezerra has quit IRC22:00
dolphmlbragstad: but we don't use plain uuids22:00
dstanekdolphm: that would be fine for me - i'm also fine if it's just a string22:00
dolphmdstanek: i'd rather bake in some url safety22:00
dolphmdstanek: avoid spaces and things that need to be encoded22:00
lbragstaddolphm: yeah, we would have to be careful with the pattern22:00
*** gabriel-bezerra has joined #openstack-keystone22:01
lbragstadmorganfainberg: had a case about that earlier22:01
dolphmhell, '^[a-z0-9-]*$' works for me :P22:01
dolphmor make it configurable and default to that22:01
lbragstadthat will still fit the 'default' use case for regions22:02
dolphm[validation] id_regex22:02
lbragstadbefore, I think I was checking the lenght22:02
*** rwsu has quit IRC22:02
lbragstadand that was a little too strict,22:02
bknudsonfound an odd issue running with db2...22:02
bknudsonwhen checking against the revocation events22:02
bknudsonthe expiration time has the accuracy down to nanoseconds.22:03
bknudsonand then it says tokens are revoked when they're not22:03
dolphmbknudson: are the nanoseconds 0?22:03
dolphmbknudson: like 12.123456000?22:03
bknudsonso mysql has 'expires_at=2014-07-22 22:55:53':22:04
bknudsonwhereas db2 has 'expires_at=2014-07-22 22:58:44.322976'22:04
dolphmbknudson: oh, db2 is correct then :P22:04
dolphmalso, i don't know my decimals, apparently22:05
bknudsonmicroseconds not nanoseconds22:05
dolphmbknudson: ah ++22:05
bknudsonI wonder if I can make mysql more accurate...22:06
bknudsonshould be easy to make things less accurate22:06
dolphmbknudson: IIRC, it depends on the version of mysql...22:06
dstaneklbragstad: that's a good question...lengths on IDs22:06
lbragstadthat's the way I had it when I started this.22:07
dolphmbknudson: MySQL 5.6.4 and up expands fractional seconds support for TIME, DATETIME, and TIMESTAMP values, with up to microseconds (6 digits) precision22:07
dolphmbknudson: which is why we chose microseconds ^^22:07
dolphmbknudson: what version are you on?22:07
bknudsonmysql  Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.222:07
lbragstaddstanek: for project_create you want domain_id: parameter_types.hex_uuid22:07
dolphmlbragstad: cap IDs at 64 chars22:07
bknudsonthis is my ubuntu 12.0422:07
dstaneklbragstad: hold on - i'm lost in a sea of your reviews - let me find the first one22:08
lbragstaddolphm: ok, I'll build that into hex_uuid22:08
dolphmbknudson: with clock drift it's all fruitless anyway!22:08
lbragstaddstanek: https://review.openstack.org/#/c/86484/33/keystone/assignment/schema.py22:08
*** gabriel-bezerra has quit IRC22:09
dolphmlbragstad: id_string is probably a better name than hex_uuid, considering it should allow non-hex for regions, idps and protocols22:09
dstaneklbragstad: if that is an ID we generate then i think yes22:09
lbragstadbut capped at 64 characters22:09
bknudsondolphm: for some reason revocation events marks more tokens as revoked when the accuracy goes up22:09
bknudsonwhich seems weird... you'd think fewer tokens would be revoked22:10
dstanekdolphm: i liked hex_uuid because it only allowed hex character22:10
*** gabriel-bezerra has joined #openstack-keystone22:10
bknudsonbut maybe it's more the truncation of the timestamp to the nearest second rather than the accuracy22:10
dolphmlbragstad: http://pasteraw.com/54a34clquvocsyyvhnykl5ik6ycwdjx :)22:11
dolphmbknudson: the ones between .000000 and .999999 ? that's up to an additional second worth of tokens that can be revoked22:12
dolphmdstanek: that's the reason i don't like hex_uuid; i'd prefer one rule for all ID values22:12
dolphmlbragstad: i'll be back on later tonight to do some reviews; parallelize as much as you can and we'll cut j2 in the morning with whatever we've got22:14
lbragstaddolphm: sounds good, thanks!22:15
dstanekdolphm: the reason i like hex is that the IDs we create can't have certain characters in them so you shouldn't be able to specify that in a foreign key field22:15
dolphmdstanek: but user-defined region IDs, user-defined identity provider IDs, and user defined protocol IDs can have more character than just hex22:15
dolphmdstanek: and the use/application of user-defined IDs is likely to expand further22:16
dstanekdolphm: yeah, that's why i was asking for another id type; i figured be strict now and relax it later - the otherway around is usually harder22:16
dolphmdstanek: lbragstad: also, you already need to support hyphens, because it's possible that we've migrated tenant IDs from diablo / essex forward which are just str(uuid.uuid4())22:17
lbragstadyep '^[a-fA-F0-9-]*$'22:17
lbragstaddolphm: writing test cases to support that22:17
dolphmlbragstad: and a-z not just a-f22:18
lbragstadah, right22:18
dolphmlbragstad: also, this is just my personal preference, but i wouldn't bother with uppercase characters unless we have a strong use case for them; case sensitivity just confuses people, so enforcing one case makes things easier22:19
lbragstadI want to say that is what morganfainberg was talking about22:19
lbragstadwhen I was having this discussion with him22:19
morganfainberglbragstad, dolphm, works for me, but we should make sure all IDs are emitted lower then?22:20
morganfainberg*should* be the case.22:20
dstanekdolphm: what about existing IDs?22:20
morganfainberglbragstad, dolphm, also for domain don't forget we have a non-uuid domain_id ('default')22:20
dolphmdstanek: that's why i was suggesting we make the regex configurable (keystone.conf [validation] id_string_regex, and just have a strict default22:21
dolphmmorganfainberg: ++ my default regex suggestion is '^[a-z0-9-]*$' and 1-64 chars22:21
dstanekyeah, i can see that22:22
zzzeekis it normal to get a lot of failures running keystone tests regarding comparison of XML documents to each other, ordering of nodes?22:23
dstaneki still don't like that invalid data can get through22:23
*** dims_ has joined #openstack-keystone22:23
dstanekzzzeek: nope, let me take a look22:23
zzzeek File "keystone/tests/test_versions.py", line 378, in test_public_versions  -> MismatchError: expected = (some XML that differs in the order of some of the <tags>)22:23
dolphmwe have an xml comparison thing to specifically ignore that22:24
zzzeekdstanek: OK well, this is a fedora 20 machien that i just installed the libxml2 and all that on, …ok22:24
dolphm(ignore element order)22:24
zzzeekdstanek: my build here might be off22:24
dolphmalright i'm out22:24
*** dims has quit IRC22:24
dstanekzzzeek: do you have the full output of the message?22:24
zzzeeki have a crapload of output let me put it up somewhere22:24
zzzeekdstanek: http://paste.openstack.org/show/87664/22:26
zzzeekdstanek: this too: File "keystone/tests/test_v3_catalog.py", line 32, in test_get_catalog_project_scoped_token -> MismatchError: ['catalog', 'links'] != [u'links', u'catalog']22:26
*** david-lyle has quit IRC22:29
dstanekzzzeek: i'll take a look in just a sec - chrome is freezing on me22:30
zzzeekdstanek: no hurry, the paste also gets chopped off but you get the picture…..22:30
gyeedolphm, did you just cut a keystoneclient release?22:33
jamielennoxgyee: yes22:33
gyeecongrats, looks like we just broke horizon gates22:33
gyeeUserManager interface got changed22:34
jamielennoxthats there own stupid fault22:34
*** david-lyle has joined #openstack-keystone22:34
*** stevemar has quit IRC22:35
gyeedavid-lyle, you have anything nice to say to jamielennox? :D22:35
jamielennoxbroken by https://review.openstack.org/#/c/104766/22:36
jamielennoxhorizon is using keystone managers seperate from tthe client22:36
gyeeyeah man, why can Horizon stick to the program?22:36
jamielennoxactually it appears to be because they are constructing user objects in testing directly22:37
*** gabriel-bezerra has quit IRC22:37
jamielennoxand so they construct a fake manager to link it to22:37
gyeeyeah, for testing only22:38
jamielennoxalso - this needs to be a gate test22:38
*** gabriel-bezerra has joined #openstack-keystone22:38
gyeejamielennox, you mean add horizon gate to python-keystoneclient?22:39
jamielennoxeither way22:39
jamielennoxhorizon should test master22:39
david-lyleHorizon does test master22:40
jamielennoxmaybe we should test keystoneclient against a few things in its gate22:40
gyeedavid-lyle, then how did that one got merged?22:40
david-lylewell we have dependencies, they pull from the pypi mirrors, your change isn't uploaded to pypi mirror... because it's a change22:41
gyeebut we don't upload master to pipy though22:41
david-lylegyee, I see your point22:42
dstanekdavid-lyle: they meant test against master ksc22:42
gyeeonly when we cut the cheese22:42
gyeeI mean release22:42
david-lylebut you are likely to break master22:42
david-lylethat's why we use stable releases22:42
dstanekdavid-lyle: if you are using anything other than the public API then yes for sure22:43
david-lyleI'm not sure we're allowed by the greater openstack infra system to use git dependencies in Horizon22:43
jamielennoxdstanek: unfortunately public is loosely defined22:43
jamielennoxdavid-lyle: no, but i think you can set up something special for gate22:43
dstanekwe actually test keystone against multiple version of the ksc22:43
jamielennoxdstanek: not that we recommend that22:44
dstanekjamielennox: no, but against master for sure22:44
dstanekno reason to be caught off guard when a change happens22:44
*** thedodd has quit IRC22:45
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add string id type validation  https://review.openstack.org/10886222:45
jamielennoxdavid-lyle: so i'm just testing replacing UserManager(None) with just None in keystone_data.py22:45
*** huats has quit IRC22:45
*** huats has joined #openstack-keystone22:46
jamielennoxthe only reason a manager should be needed by a resource is if you do user_resource.update() or user_resource.delete() or something22:46
gyeewe can't mock it?22:47
*** topol has joined #openstack-keystone22:49
jamielennoxgyee: we can, i just want to see if the tests need it22:49
jamielennoxi don't think i've ever run horizon tests beforre22:49
bknudsonturns out when we have low accuracy tempest works and unit tests fail :(22:50
*** ayoung has quit IRC22:51
bknudsonmaybe the tempest test is incorrect...22:51
jamielennoxdavid-lyle: is there a bug filed yet or should I?22:51
*** huats has quit IRC22:52
*** huats has joined #openstack-keystone22:52
*** huats has quit IRC22:52
*** huats has joined #openstack-keystone22:52
bknudsontempest is testing that you can revoke a token created from an unscoped token and the unscoped token is still valid22:53
david-lylejamielennox: none that I know of, but may be on recheck page22:55
*** zzzeek has quit IRC22:57
*** bknudson has quit IRC22:57
jamielennoxdavid-lyle: https://review.openstack.org/#/c/108865/ and https://bugs.launchpad.net/horizon/+bug/134723622:57
uvirtbotLaunchpad bug 1347236 in horizon "Tests fail due to keystoneclient 0.10 release" [Undecided,In progress]22:57
*** fausto has quit IRC22:57
*** nkinder has quit IRC22:59
*** hrybacki has quit IRC23:01
*** henrynash has quit IRC23:01
*** xianghui has joined #openstack-keystone23:05
*** zzzeek has joined #openstack-keystone23:09
*** zzzeek has quit IRC23:14
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Move fake session to HTTPClient  https://review.openstack.org/10886823:17
*** topol has quit IRC23:19
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain  https://review.openstack.org/10719423:20
david-lylejamielennox: passes the horizon jobs that were failing, thanks23:25
jamielennoxdavid-lyle: np - sorry about breaking them initially23:26
david-lylewe were doing something stupid there to begin with, but a better integration test strategy for the clients and other openstack maintained dependencies is needed23:27
*** xianghui has quit IRC23:30
jamielennoxdavid-lyle: yea, i've started doing fixutres for the basic keystoneclient stuff like auth and discovery as that's easy to get wrong23:36
*** xianghui has joined #openstack-keystone23:36
jamielennoxi agree the clients should probably be providing there own test objects23:36
*** david-lyle has quit IRC23:38
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add string id type validation  https://review.openstack.org/10886223:39
*** lbragstad has quit IRC23:40
*** oomichi has joined #openstack-keystone23:50
*** richm has left #openstack-keystone23:51
*** xianghuihui has joined #openstack-keystone23:51
*** xianghui has quit IRC23:54
openstackgerritJamie Lennox proposed a change to openstack/keystone-specs: Explicity request an unscoped token  https://review.openstack.org/10807123:57
*** amcrn has quit IRC23:58
*** xianghuihui has quit IRC23:59

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