| jamielennox | ayoung: mind if i cleanup https://review.openstack.org/#/c/108071/1/specs/juno/explicit-unscoped.rst | 00:00 |
|---|---|---|
| openstackgerrit | Jamie Lennox proposed a change to openstack/keystone-specs: Explicity request an unscoped token https://review.openstack.org/108071 | 00:25 |
| *** hrybacki has joined #openstack-keystone | 00:26 | |
| *** dims has joined #openstack-keystone | 00:29 | |
| *** ncoghlan is now known as ncoghlan_afk | 00:29 | |
| *** dims has quit IRC | 00:34 | |
| *** david-lyle has joined #openstack-keystone | 00:35 | |
| ayoung | jamielennox, no problem at all. | 00:38 |
| jamielennox | ayoung: good, i posted it already :) | 00:38 |
| ayoung | jamielennox, 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 IRC | 00:39 | |
| jamielennox | ayoung: yea, i posted a response to that | 00:39 |
| jamielennox | basically i'm fine with that if there is some precendence | 00:39 |
| jamielennox | do we do that anywhere already? | 00:39 |
| ayoung | jamielennox, no. But the service catalog was only in the token itself due to the need to replicate the validate call | 00:40 |
| jamielennox | ayoung: no that's not true, if i pass my token to nova and nova calls glance it should call "my" glance | 00:40 |
| ayoung | since only keystone itself can ever consume an unscoped token, there is no reason for it to need to return a catalog in validate | 00:40 |
| ayoung | not an unscoped token | 00:40 |
| jamielennox | but i agree that in an unscoped token there's not really a need to embed the catalog | 00:41 |
| ayoung | jamielennox, that used to happen in the "validate" call | 00:41 |
| jamielennox | ayoung: oh for UUID tokens - yea that makes sense | 00:43 |
| jamielennox | ah the good old days | 00:43 |
| ayoung | jamielennox, 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 covers | 00:44 |
| jamielennox | ayoung: should i make that clear in the blueprint or look to in the api review? | 00:44 |
| jamielennox | actually never mind me - there is no api review for this | 00:44 |
| jamielennox | ayoung: only issue with that would be dealing constructing the plugins, i've resisted the concept of a big plugin factory | 00:45 |
| ayoung | Yeah, 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 httpclient | 00:46 |
| jamielennox | yep, but it's not just that because it includes it token and v2 or if token and v3 | 00:49 |
| *** ncoghlan_afk is now known as ncoghlan | 00:50 | |
| ayoung | jamielennox, if a v3 client.Cliet were passed a v2 token, wouldn't that be ok, and same for the reverse? | 00:52 |
| jamielennox | ayoung: yes | 00:52 |
| jamielennox | it's more about what is available | 00:52 |
| jamielennox | see for example: https://review.openstack.org/#/c/81147/ | 00:53 |
| ayoung | I like that jamielennox | 00:56 |
| jamielennox | i think that one will be really useful for CLI and CONF files | 00:56 |
| jamielennox | it's where all this auth plugin and discovery stuff starts to come together | 00:57 |
| ayoung | I think Horizon should use it | 00:57 |
| ayoung | yepo | 00:57 |
| ayoung | I might just pull that in to my horizon work | 00:57 |
| jamielennox | it's almost unecessary because it mostly relies on whether you provide domain information, but still useful | 00:57 |
| jamielennox | and importantly the auth_url that you pass it is unversioned | 00:57 |
| *** ncoghlan is now known as ncoghlan_afk | 01:00 | |
| ayoung | jamielennox, its that last part that is messing me up. the client.Client code should probably use it. | 01:01 |
| jamielennox | so what are you doing that needs client.Client() ? | 01:02 |
| jamielennox | if you have discoverable auth do you need discoverable client? | 01:03 |
| jamielennox | ayoung: what's the policy on changing backend APIs? | 01:03 |
| *** gmurphy has quit IRC | 01:08 | |
| ayoung | jamielennox, client.Client is called from Horizon | 01:08 |
| ayoung | I'll pass a link here in a second | 01:08 |
| *** gmurphy has joined #openstack-keystone | 01:09 | |
| ayoung | jamielennox, http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py#n168 | 01:12 |
| jamielennox | ayoung: that looks version specific to me | 01:13 |
| ayoung | jamielennox, yes, it is. That is why I was saying client.Client, but I realize that might not have been clear. | 01:17 |
| ayoung | I meant specifically the versioned, so | 01:17 |
| ayoung | from v2 import client.... | 01:18 |
| jamielennox | ah right, no we have a keystoneclient.client.Client() which does discovery | 01:18 |
| jamielennox | i thought you meant that | 01:18 |
| ayoung | not one from keystoneclient.client | 01:18 |
| ayoung | jamielennox, so would it make sense to make those plugin and session aware? | 01:18 |
| ayoung | jamielennox, 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 |
| jamielennox | ayoung: so if you have a session and a auth plugin at that point then you're fine - v2/v3 auth won't matter | 01:19 |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone: JSON-Home for V3 https://review.openstack.org/103983 | 01:19 |
| *** ncoghlan_afk is now known as ncoghlan | 01:24 | |
| *** marcoemorais has quit IRC | 01:27 | |
| ayoung | jamielennox, 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 plugin | 01:27 |
| *** dims has joined #openstack-keystone | 01:30 | |
| jamielennox | ayoung: i tried that initially - it's just way to hard to keep the backwards compatability correct | 01:31 |
| ayoung | hmmm. probably true | 01:31 |
| jamielennox | our 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 work | 01:31 |
| jamielennox | it made the base client just layers of redirection values | 01:32 |
| ayoung | jamielennox, I've already had to hack keystone, client, and DOA. I was hoping to avoid hacking Horizon as well. Quite foolish to think I could | 01:32 |
| jamielennox | so clean break, if you pass session then you get new behaviour, if you don't you get old behaviour | 01:32 |
| jamielennox | i've done that even more strictly in novaclient and cinderclient | 01:32 |
| ayoung | OK... | 01:33 |
| ayoung | lets see what happens when I pip install -e horizon then as a first step... | 01:33 |
| *** dims has quit IRC | 01:34 | |
| ayoung | ugh....this not be cheap.... | 01:44 |
| jamielennox | horizon install? | 01:45 |
| *** mberlin1 has quit IRC | 01:49 | |
| *** radez is now known as radez_g0n3 | 01:50 | |
| *** mberlin has joined #openstack-keystone | 01:50 | |
| *** ncoghlan has quit IRC | 01:50 | |
| *** ncoghlan has joined #openstack-keystone | 01:51 | |
| *** jamielennox has quit IRC | 01:52 | |
| *** diegows has quit IRC | 01:52 | |
| *** dims has joined #openstack-keystone | 01:56 | |
| *** jamielennox has joined #openstack-keystone | 01:56 | |
| *** oomichi has joined #openstack-keystone | 02:32 | |
| *** xianghui has quit IRC | 03:00 | |
| *** Chicago has joined #openstack-keystone | 03:01 | |
| *** xianghui has joined #openstack-keystone | 03:05 | |
| *** richm has left #openstack-keystone | 03:14 | |
| *** dims has quit IRC | 03:25 | |
| *** hrybacki has quit IRC | 03:36 | |
| *** amcrn has quit IRC | 03:45 | |
| *** cjellick_ has joined #openstack-keystone | 04:01 | |
| *** chandankumar has joined #openstack-keystone | 04:03 | |
| *** cjellick has quit IRC | 04:04 | |
| *** stevemar has joined #openstack-keystone | 04:04 | |
| stevemar | jamielennox, ping | 04:05 |
| jamielennox | stevemar: hello | 04:05 |
| stevemar | jamielennox, just a quick q | 04:05 |
| stevemar | why did you move things around line 220 here: https://review.openstack.org/#/c/108221/2/openstackclient/tests/identity/v3/test_identity_provider.py | 04:05 |
| *** cjellick_ has quit IRC | 04:06 | |
| *** shakamunyi has joined #openstack-keystone | 04:06 | |
| jamielennox | stevemar: i don't remember - i think i would have been trying to reuse it and then scrapped that change | 04:06 |
| *** gabriel-bezerra has quit IRC | 04:06 | |
| jamielennox | yea, i think i was having some issues when i was trying to have a federation mock, which then had a sub identity_providers mock | 04:07 |
| stevemar | jamielennox, it's cool, as long as i wasn't missing something | 04:07 |
| *** gabriel-bezerra has joined #openstack-keystone | 04:07 | |
| stevemar | it's cool, +A | 04:07 |
| jamielennox | that didn't work so i ended up with the FakeFederationManager | 04:07 |
| stevemar | i tried it out with federation extension enabled | 04:07 |
| stevemar | and it worked (yay) | 04:07 |
| *** jamielennox_ has joined #openstack-keystone | 04:08 | |
| *** ncoghlan_ has joined #openstack-keystone | 04:08 | |
| *** shakamunyi has quit IRC | 04:08 | |
| *** ncoghlan__ has joined #openstack-keystone | 04:08 | |
| *** jamielenno| has joined #openstack-keystone | 04:09 | |
| jamielenno| | stevemar: cheers | 04:09 |
| jamielenno| | bah - wtf is happening with my connection | 04:09 |
| stevemar | jamielenno|, it's dying, there are three of you now | 04:10 |
| *** gabriel-bezerra has quit IRC | 04:10 | |
| *** gabriel-bezerra has joined #openstack-keystone | 04:10 | |
| *** jamielennox has quit IRC | 04:12 | |
| *** jamielenno| is now known as jamielennox | 04:12 | |
| *** jamielennox_ has quit IRC | 04:12 | |
| *** ncoghlan has quit IRC | 04:12 | |
| *** ncoghlan_ has quit IRC | 04:12 | |
| openstackgerrit | Arun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling. https://review.openstack.org/95300 | 04:15 |
| jamielennox | stevemar: what did you setup your local federation env with? i tried a few things and now realize how crap ECP is | 04:15 |
| openstackgerrit | Steve Martinelli proposed a change to openstack/keystone-specs: Specification for OpenID Connect https://review.openstack.org/107890 | 04:19 |
| openstackgerrit | Steve Martinelli proposed a change to openstack/keystone-specs: Specification for OpenID Connect https://review.openstack.org/107890 | 04:20 |
| jamielennox | stevemar: also just for my curiosity with oauth and openid connect are you persisting data to the keystone db? | 04:20 |
| jamielennox | my understanding of SAML federation is that it is a purely ephemeral user id, can you do that with oauth or openid? | 04:21 |
| stevemar | jamielennox, my local federation env, for real testing of SSO and ECP authN, i use tivoli federated identity manager | 04:21 |
| stevemar | had someone from that team help me with the setup, it really helped | 04:22 |
| stevemar | for oauth, thats just delegation, the only thing i persist to the keystone dbs are the request and access token information | 04:22 |
| jamielennox | stevemar: yep - i didn't think we did oauth from external idp | 04:22 |
| stevemar | i think / hope that openid connect will be the same as saml, it'll all be ephemeral | 04:23 |
| jamielennox | is oauth (/2) possible in that way? | 04:23 |
| stevemar | jamielennox, openid connect is all the goodness of oauth2 and more | 04:26 |
| stevemar | jamielennox, oauth2 by itself is just another delegation protocol, like oauth1 or trusts. | 04:26 |
| *** gabriel-bezerra has quit IRC | 04:26 | |
| *** gabriel-bezerra has joined #openstack-keystone | 04:27 | |
| stevemar | openid was being developed, then they threw in some oauth2 and called it openid connect :P | 04:27 |
| jamielennox | but oauth2 can obviously delegate to a new user | 04:27 |
| stevemar | ye[ | 04:28 |
| stevemar | yep* | 04:28 |
| jamielennox | taking eg google | 04:28 |
| jamielennox | you could signing with oauth(/2), you wouldn't actually need any permissions on google's services but it would provide auth | 04:28 |
| jamielennox | you have the same problem with role mapping | 04:28 |
| jamielennox | but if it boils down to a user_id what do you need to save locally? | 04:29 |
| jamielennox | it's still kind of useless because all this is web driven - but just for interest | 04:29 |
| stevemar | jamielennox, shouldn't save anything locally about the user | 04:29 |
| stevemar | the mapping should give the user roles | 04:30 |
| stevemar | jamielennox, yeah, thats the trouble with these things, all web driven | 04:30 |
| jamielennox | ok, 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 useful | 04:31 |
| *** alex_xu has joined #openstack-keystone | 04:31 | |
| *** cjellick has joined #openstack-keystone | 04:32 | |
| stevemar | jamielennox, correct, oauth by itself is just delegation | 04:32 |
| stevemar | jamielennox, out of curiosity, do you know if auth token mangles the catalog and removes endpoint ids? (super specific question) | 04:33 |
| jamielennox | stevemar: auth_token shouldn't mangle it, i don't know off the top of my head if endpoint ids are in the catalog | 04:33 |
| jamielennox | i think they are for v3 but not for v2 | 04:33 |
| jamielennox | but i'd check that | 04:34 |
| stevemar | jamielennox, for v3 they are, (according to the API spec) | 04:34 |
| stevemar | but i'm wondering if they are there for templated catalog? | 04:34 |
| jamielennox | stevemar: yea, i remember discussing that though and we decided they shouldn't be | 04:34 |
| jamielennox | but then this endpoint enforcement thing came up and we will need them | 04:34 |
| *** ajayaa has joined #openstack-keystone | 04:34 | |
| jamielennox | stevemar: i think no, because there is no actual v3 templated response. It just takes the v2 catalog and transforms it | 04:35 |
| jamielennox | stevemar: oh - wait | 04:35 |
| jamielennox | stevemar: yes, auth_token mangles the catalog | 04:35 |
| jamielennox | it turns v3 catalog into v2 catalog | 04:35 |
| stevemar | jamielennox, yes, this guy here https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L385 | 04:36 |
| * jamielennox wrote that and should remember this stuff | 04:36 | |
| stevemar | jamielennox, haha | 04:36 |
| stevemar | jamielennox, happens | 04:36 |
| jamielennox | why do you need endpoint ids? | 04:37 |
| stevemar | jamielennox, the code i'm looking at is going through the endpoints in the catalog and checking ['endpoints'][0]['id'] | 04:38 |
| stevemar | but failing on the id part | 04:38 |
| jamielennox | also another question - in mapping you have a locals list and a remote list, does it make sense to have multiple local entries? | 04:38 |
| stevemar | but _v3_to_v2_catalog shouldn't mangle the id's - right? | 04:39 |
| jamielennox | stevemar: it might not pick them up | 04:39 |
| stevemar | jamielennox, iirc the kent folk were saying we should have it that way | 04:39 |
| *** cjellick has quit IRC | 04:40 | |
| jamielennox | stevemar: so i just got a v2 token and it appears there is an endpoint id in the token | 04:41 |
| jamielennox | it's a bit weird though because it's closer to a service id | 04:41 |
| jamielennox | in v2 an endpoint consists of a public, internal and admin URL | 04:42 |
| jamielennox | whereby in v3 each of those would have a different id | 04:42 |
| *** gabriel-bezerra has quit IRC | 04:42 | |
| stevemar | let me try running CatalogConversionTests in ksclient | 04:43 |
| *** gabriel-bezerra has joined #openstack-keystone | 04:43 | |
| stevemar | jamielennox, bah, no id there, might be a limitation of the fixture though | 04:47 |
| jamielennox | stevemar: i expect i just never tested that the id went through | 04:47 |
| stevemar | let me find out why they might need it... i suspect they don't but will complain that i should fix it | 04:48 |
| jamielennox | if you look at the way it's written it picks out the v3 parts it wants | 04:48 |
| jamielennox | also given that you'd compress 3 ids down to one i don't know what the right value would be | 04:48 |
| *** amcrn has joined #openstack-keystone | 04:49 | |
| jamielennox | oh, there is a legacy_endpoint_id that is used for v2, otherwise it uses v3 endpoint id per url | 04:49 |
| stevemar | jamielennox, where do you see that part? | 04:50 |
| jamielennox | looking at the database and memory | 04:50 |
| jamielennox | (my memory) | 04:50 |
| jamielennox | i'm just looking now to see if legacy_endpoint_id is part of the catalo g | 04:51 |
| stevemar | jamielennox, i just searched for legacy_endpoint_id no results :( | 04:51 |
| jamielennox | think you mispelt then, i get a few | 04:52 |
| jamielennox | mostly keystone/catalog/controllers.p | 04:52 |
| jamielennox | y | 04:52 |
| stevemar | oh i was looking in client | 04:53 |
| *** dims has joined #openstack-keystone | 04:54 | |
| jamielennox | stevemar: nope, no legacy_endpoint_id emitted | 04:56 |
| jamielennox | stevemar: v2 http://paste.openstack.org/show/87531/ | 04:58 |
| jamielennox | v3: http://paste.openstack.org/show/87530/. | 04:58 |
| *** gabriel-bezerra has quit IRC | 04:58 | |
| *** amcrn has quit IRC | 04:59 | |
| jamielennox | using the same user/pass/project | 04:59 |
| stevemar | jamielennox, if i am invoking nova image-list, shouldn't that hit keystoneclient.middleware? (trying to debug) | 04:59 |
| jamielennox | i expect so | 04:59 |
| *** dims has quit IRC | 04:59 | |
| jamielennox | but see anyway that the ids between v2 and v3 aren't the same - so we can't jsut convert one to the other | 04:59 |
| *** gabriel-bezerra has joined #openstack-keystone | 04:59 | |
| stevemar | so in auth_token_middleware, the convert v3_to_v2 method, we just don't add them? | 05:00 |
| jamielennox | yep | 05:01 |
| stevemar | no information is better than misinformation i suppose | 05:01 |
| jamielennox | stevemar: i'm still lost as to why you care about endpoint id? | 05:01 |
| stevemar | jamielennox, i don't care, someone else does. | 05:02 |
| jamielennox | ok, so why they care? | 05:02 |
| stevemar | auditing tools | 05:02 |
| stevemar | they have an id field to fill in! thus we must have an id | 05:02 |
| jamielennox | lol, but it's the catalog - why would you need to log that? | 05:03 |
| stevemar | i have noooo idea | 05:08 |
| jamielennox | ok, so back to mapping for just a sec, locals list and remotes list, what happens if you have mutliple local entries? | 05:10 |
| stevemar | sure | 05:11 |
| stevemar | let me try and remember... | 05:11 |
| jamielennox | yea, the mapping syntax is described nowhere | 05:11 |
| stevemar | jamielennox, i always default back to the fixtures | 05:13 |
| stevemar | https://github.com/openstack/keystone/blob/master/keystone/tests/mapping_fixtures.py#L23 | 05:13 |
| stevemar | right right, i remember now | 05:13 |
| stevemar | it's if you want to apply several local ones at once | 05:13 |
| jamielennox | so i can understand mapping to serveral groups, but there is users mixed in there as well | 05:14 |
| stevemar | jamielennox, so in that example (RULES_SMALL), we could have a single rule to just map users | 05:14 |
| jamielennox | there'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 die | 05:14 |
| stevemar | jamielennox, we do blow up if the user is specified more than once | 05:15 |
| stevemar | but yes | 05:15 |
| *** gabriel-bezerra has quit IRC | 05:15 | |
| jamielennox | is the somewhat unusual syntax because it gets copied straight into a token? | 05:16 |
| *** gabriel-bezerra has joined #openstack-keystone | 05:17 | |
| *** bvandenh has joined #openstack-keystone | 05:19 | |
| stevemar | jamielennox, more or less, we take the user and group ids and slot them into a token | 05:20 |
| stevemar | an unscoped token* | 05:20 |
| *** chandankumar has quit IRC | 05:25 | |
| *** arborism has joined #openstack-keystone | 05:32 | |
| *** shausy has joined #openstack-keystone | 05:33 | |
| ajayaa | ayoung: How do I enable caching for catalog/assignment while running unit tests? | 05:42 |
| *** bvandenh has quit IRC | 05:44 | |
| ajayaa | jamielennox, | 05:45 |
| jamielennox | ajayaa: i don't know of the top of my head - but i don't think you should | 05:45 |
| jamielennox | the unit tests are written for very specific scenarios - if you cache within them they won't work | 05:46 |
| ajayaa | I am working on the blueprint "add caching layer in keystone." | 05:46 |
| ajayaa | I have added the caching layer for catalog. But I need to write tests for it. | 05:46 |
| *** stevemar has quit IRC | 05:47 | |
| jamielennox | ajayaa: oh, right - um i think you'll want to set the value in CONF but i don't know what that value is | 05:47 |
| jamielennox | i'd check out morganfainberg's existing tests | 05:48 |
| ajayaa | I 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 |
| ajayaa | http://pastebin.com/zuawmeFR | 05:50 |
| ajayaa | jamielennox, 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 |
| ajayaa | It* | 05:51 |
| jamielennox | ajayaa: that doesn't look like you've turned the cache on though | 05:52 |
| jamielennox | hmm, guess you must have otherwise it'd skip | 05:52 |
| jamielennox | ajayaa: i really don't know sorry | 05:53 |
| ajayaa | okay, jamielennox | 05:53 |
| ajayaa | jamielennox, at what time can I get hold of morganfainberg? | 05:53 |
| jamielennox | umm, up till about 4 hours ago - i don't know about start | 05:54 |
| jamielennox | he's in san fransisco - but he works long hours | 05:54 |
| *** ncoghlan__ is now known as ncoghlan_afk | 05:54 | |
| *** k4n0 has joined #openstack-keystone | 05:59 | |
| *** chandankumar has joined #openstack-keystone | 06:01 | |
| *** soulxu1404_ has joined #openstack-keystone | 06:02 | |
| *** alex_xu has quit IRC | 06:02 | |
| *** tomoiaga has joined #openstack-keystone | 06:02 | |
| *** soulxu1404_ is now known as alex_xu | 06:05 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/106939 | 06:06 |
| *** ncoghlan_afk is now known as ncoghlan__ | 06:07 | |
| openstackgerrit | guang-yee proposed a change to openstack/keystone: X.509 SSL certificate authentication plugin https://review.openstack.org/103736 | 06:10 |
| openstackgerrit | guang-yee proposed a change to openstack/keystone-specs: X.509 SSL certificate authentication https://review.openstack.org/105913 | 06:14 |
| *** henrynash has joined #openstack-keystone | 06:15 | |
| *** gyee has quit IRC | 06:17 | |
| *** ncoghlan__ is now known as ncoghlan_afk | 06:17 | |
| *** andreaf has quit IRC | 06:22 | |
| *** alex_xu has quit IRC | 06:34 | |
| *** chandankumar has quit IRC | 06:39 | |
| *** alex_xu has joined #openstack-keystone | 06:51 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/keystone: Add restricted catalog to unscoped token https://review.openstack.org/108592 | 06:51 |
| *** arborism has quit IRC | 06:52 | |
| *** dims has joined #openstack-keystone | 06:57 | |
| *** dims has quit IRC | 07:02 | |
| *** harlowja is now known as harlowja_away | 07:04 | |
| *** ncoghlan_afk is now known as ncoghlan__ | 07:20 | |
| *** gabriel-bezerra has quit IRC | 07:20 | |
| *** gabriel-bezerra has joined #openstack-keystone | 07:21 | |
| *** jamielennox is now known as jamielennox|away | 07:31 | |
| *** alex_xu has quit IRC | 07:34 | |
| *** k4n0 has quit IRC | 07:51 | |
| openstackgerrit | Bob Thyne proposed a change to openstack/identity-api: Update OS-EP-FILTER API https://review.openstack.org/106292 | 07:55 |
| *** dims has joined #openstack-keystone | 07:58 | |
| *** alex_xu has joined #openstack-keystone | 07:59 | |
| *** afazekas has joined #openstack-keystone | 08:01 | |
| *** gabriel-bezerra has quit IRC | 08:01 | |
| *** gabriel-bezerra has joined #openstack-keystone | 08:02 | |
| *** dims has quit IRC | 08:03 | |
| *** k4n0 has joined #openstack-keystone | 08:04 | |
| *** bvandenh has joined #openstack-keystone | 08:12 | |
| *** andreaf has joined #openstack-keystone | 08:18 | |
| *** alex_xu has quit IRC | 08:18 | |
| openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 08:25 |
| *** alex_xu has joined #openstack-keystone | 08:30 | |
| *** k4n0 has quit IRC | 08:32 | |
| openstackgerrit | Marek Denis proposed a change to openstack/keystone-specs: Keystone WebSSO https://review.openstack.org/108611 | 08:42 |
| *** k4n0 has joined #openstack-keystone | 08:49 | |
| *** henrynash has quit IRC | 08:53 | |
| *** dims has joined #openstack-keystone | 08:58 | |
| *** dims has quit IRC | 09:04 | |
| *** alex_xu has quit IRC | 09:12 | |
| *** ncoghlan__ has quit IRC | 09:17 | |
| *** k4n0 has quit IRC | 09:19 | |
| *** openstackgerrit has quit IRC | 09:31 | |
| *** openstackgerrit has joined #openstack-keystone | 09:32 | |
| *** k4n0 has joined #openstack-keystone | 09:38 | |
| *** cjellick has joined #openstack-keystone | 09:38 | |
| *** cjellick has quit IRC | 09:42 | |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Use immutable arg rather mutable arg https://review.openstack.org/103801 | 09:50 |
| *** hyakuhei has quit IRC | 09:54 | |
| *** csd has quit IRC | 09:54 | |
| *** anteaya has quit IRC | 09:54 | |
| *** csd has joined #openstack-keystone | 09:55 | |
| *** hyakuhei has joined #openstack-keystone | 09:55 | |
| *** anteaya has joined #openstack-keystone | 09:56 | |
| *** oomichi has quit IRC | 09:59 | |
| *** dims has joined #openstack-keystone | 09:59 | |
| *** dims has quit IRC | 10:04 | |
| openstackgerrit | Kristy Siu proposed a change to openstack/keystone-specs: Specification for IETF ABFAB federation https://review.openstack.org/108631 | 10:07 |
| *** diegows has joined #openstack-keystone | 10:59 | |
| *** masahito has joined #openstack-keystone | 11:13 | |
| masahito | hi there!! | 11:16 |
| masahito | I have a question about usage of keystoneclient. | 11:16 |
| masahito | how do I customize an option value "http_connect_timeout" in auth_token.py? | 11:21 |
| masahito | I think it is a Int value but the code in the master repo shows Bool value. | 11:22 |
| *** k4n0 has quit IRC | 11:28 | |
| *** dims has joined #openstack-keystone | 11:32 | |
| *** shausy has quit IRC | 11:37 | |
| *** shausy2 has joined #openstack-keystone | 11:37 | |
| *** henrynash has joined #openstack-keystone | 11:46 | |
| masahito | umm... anyone isn't in this channel now. | 11:47 |
| *** xianghui has quit IRC | 11:47 | |
| *** ayoung has quit IRC | 11:47 | |
| tomoiaga | masahito: http://docs.openstack.org/trunk/config-reference/content/keystone-configuration-file.html | 11:51 |
| tomoiaga | masahito: look for http_connect_timeout | 11:51 |
| masahito | tomoiaga: thanks for answering | 11:53 |
| tomoiaga | masahito: 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 example | 11:54 |
| tomoiaga | masahito: also note that the value needs to be set unde [keystone_authtoken] in the keystone.conf file | 11:55 |
| *** xianghui has joined #openstack-keystone | 12:00 | |
| *** gabriel-bezerra has quit IRC | 12:09 | |
| *** hrybacki has joined #openstack-keystone | 12:10 | |
| *** gabriel-bezerra has joined #openstack-keystone | 12:11 | |
| masahito | tomoiaga: you mean I must change the option in keystone.conf not in auth_token.py, don't you? | 12:12 |
| tomoiaga | masahito: 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.conf | 12:13 |
| masahito | tomoiaga: I tried to change the option in auth_token.py to int value then other component like nova didin't start. | 12:14 |
| masahito | tomoiaga: OK. I try to set the time out in keystone.conf | 12:14 |
| tomoiaga | masahito: 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 config | 12:15 |
| masahito | tomoiaga: when I was searching what kind of option dose keystone have, | 12:18 |
| masahito | tomoiaga: I found the option. And I tried to custum this. | 12:18 |
| tomoiaga | masahito: 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 |
| masahito | tomoiaga: After challenging custumizing this, nova and other component didn't start. So I questioned this. | 12:20 |
| tomoiaga | masahito: 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-keystone | 12:33 | |
| *** dims has quit IRC | 12:33 | |
| *** dims has joined #openstack-keystone | 12:33 | |
| *** hrybacki has quit IRC | 12:36 | |
| masahito | tomoiaga: thx!! I can change the config using your advice. | 12:46 |
| tomoiaga | masahito: no problem | 12:46 |
| openstackgerrit | Christian Berendt proposed a change to openstack/python-keystoneclient: Bump hacking to 0.9.x series https://review.openstack.org/107328 | 12:47 |
| openstackgerrit | Christian Berendt proposed a change to openstack/python-keystoneclient: Use keystoneclient.exceptions instead of keystone.apiclient.exceptions. https://review.openstack.org/108675 | 12:48 |
| openstackgerrit | Christian Berendt proposed a change to openstack/python-keystoneclient: Bump hacking to 0.9.x series https://review.openstack.org/107328 | 12:51 |
| openstackgerrit | Christian Berendt proposed a change to openstack/python-keystoneclient: Removed keystone.apiclient https://review.openstack.org/107926 | 12:59 |
| *** rwsu has joined #openstack-keystone | 13:08 | |
| *** gabriel-bezerra has quit IRC | 13:09 | |
| *** gabriel-bezerra has joined #openstack-keystone | 13:09 | |
| *** bknudson has quit IRC | 13:10 | |
| *** akscram has quit IRC | 13:11 | |
| *** stevemar has joined #openstack-keystone | 13:16 | |
| *** nkinder has quit IRC | 13:18 | |
| *** russellb has joined #openstack-keystone | 13:20 | |
| russellb | dolphm: o/ just wanted to check in on juno-2 | 13:20 |
| russellb | dolphm: looks like there's one bp left (api validation) ... it doesn't look very close to merging. thoughts? | 13:20 |
| russellb | dolphm: you've also got one wishlist bug, want to block on that? | 13:20 |
| *** radez_g0n3 is now known as radez | 13:22 | |
| *** bknudson has joined #openstack-keystone | 13:29 | |
| *** ukalifon1 has joined #openstack-keystone | 13:31 | |
| *** bklei has quit IRC | 13:34 | |
| *** lbragstad has joined #openstack-keystone | 13:42 | |
| *** lbragstad has quit IRC | 13:43 | |
| *** lbragstad has joined #openstack-keystone | 13:43 | |
| *** ajayaa has quit IRC | 13:45 | |
| dolphm | russellb: o/ | 13:48 |
| dolphm | russellb: 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 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/106210 | 13:48 |
| russellb | dolphm: o/ | 13:48 |
| russellb | dolphm: ok, cool | 13:48 |
| dolphm | russellb: the wishlist bug i believe already merged, but maybe the bot was asleep | 13:48 |
| *** gabriel-bezerra has quit IRC | 13:48 | |
| dolphm | russellb: i'll correct the status if os | 13:49 |
| dolphm | russellb: or push it | 13:49 |
| russellb | for api validation, are you referring to https://review.openstack.org/#/c/86483/ ? | 13:49 |
| russellb | that you want to get in? | 13:49 |
| *** gabriel-bezerra has joined #openstack-keystone | 13:50 | |
| russellb | dolphm: yeah, i don't see a bot update on the bug at least | 13:50 |
| russellb | last was just you saying "Moved to wishlist since we haven't merged a working per-domain-identity backend implementation yet." | 13:50 |
| dolphm | russellb: updated the wishlist bug | 13:51 |
| russellb | yay | 13:51 |
| russellb | another bug down | 13:51 |
| russellb | dolphm: i'll keep an eye out on the api validation patches, and will sync with you again tomorrow | 13:52 |
| russellb | feel free to ping me anytime if there's anything i can do | 13:52 |
| dolphm | russellb: ack | 13:52 |
| *** bklei has joined #openstack-keystone | 13:53 | |
| morganfainberg | dolphm, just commented on the API validation base impl patch | 13:54 |
| morganfainberg | dolphm, but tbh, i'd be fine with it going in as is. | 13:54 |
| openstackgerrit | Dolph Mathews proposed a change to openstack/identity-api: revise stability deadline to end of j3 https://review.openstack.org/108701 | 13:54 |
| morganfainberg | dolphm, also issued a recheck, looks like the console logs got stupid. | 13:54 |
| morganfainberg | unrelated 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 |
| dolphm | morganfainberg: 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 morning | 13:56 |
| morganfainberg | dolphm, 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 |
| morganfainberg | dolphm, ++, sounds good, ping me when you want me to poke at that validation impl again | 13:56 |
| dolphm | morganfainberg: well, if that's your concern, justin is an operator lol | 13:57 |
| morganfainberg | dolphm, true. | 13:57 |
| morganfainberg | dolphm, i *really* don't want to touch the token table :P | 13:57 |
| morganfainberg | i 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 | |
| dolphm | morganfainberg: just truncate the table first :P | 13:59 |
| morganfainberg | dolphm, LOL | 13:59 |
| stevemar | so 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 |
| morganfainberg | hrybacki_, no jamie is saying regenerate the sample cms files as well | 14:00 |
| dolphm | morganfainberg: 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 |
| morganfainberg | hrybacki_, if you follow the steps he put in the comment and include that in the commit it should resolve his -1 | 14:01 |
| morganfainberg | dolphm, that would work for me. | 14:01 |
| hrybacki_ | morganfainberg: ++ | 14:01 |
| hrybacki_ | thank you! | 14:01 |
| dolphm | stevemar: there's docs! | 14:01 |
| morganfainberg | truncate keystone.assignment -- ooops | 14:01 |
| morganfainberg | dolphm, if we're going to do that lets do that *before* this migration. | 14:02 |
| dolphm | stevemar: or maybe just docstrings | 14:02 |
| stevemar | dolphm, do you know where either are located? | 14:02 |
| dolphm | stevemar: but basically pass the session to a client object | 14:02 |
| stevemar | ah | 14:03 |
| stevemar | dolphm, right, i thought it was something like that | 14:03 |
| dolphm | stevemar: usage documentation *should* be here: http://docs.openstack.org/developer/python-keystoneclient/ (wink wink jamielennox|away) | 14:03 |
| dolphm | but there's not, so i can't advocate for anyone to use sessions | 14: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-keystone | 14:04 | |
| dolphm | morganfainberg: 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 failures | 14:05 |
| marekd | dolphm: stevemar morganfainberg: appreciate your eyes on this: https://review.openstack.org/#/c/108611/1/specs/juno/keystone-websso.rst | 14:05 |
| morganfainberg | dolphm, like celiometer not getting a message from nova? | 14:05 |
| stevemar | dolphm, i'll toss something up today for that, in meetings for the next few hours :\ | 14:05 |
| dolphm | morganfainberg: is nova-agent on the bus? | 14:05 |
| stevemar | marekd, it's already an open tab in chrome, it'll get looked at today | 14:05 |
| morganfainberg | dolphm, think so. | 14:05 |
| dolphm | morganfainberg: that's kind of what it looked like, but i don't know nova well enough to say | 14:06 |
| morganfainberg | dolphm, not 100% sure. | 14:06 |
| marekd | stevemar: sure. I didn't include required changes for django-openstack-auth, do horizons have their specs? | 14:06 |
| *** chandankumar has joined #openstack-keystone | 14:06 | |
| dolphm | morganfainberg: nova trying to send messages *somewhere*, and giving up the boot when message delivery failures occurred | 14:06 |
| stevemar | marekd, i believe they do | 14:07 |
| morganfainberg | quick 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.py | 14:07 |
| morganfainberg | stevemar, dolphm, ^ | 14:07 |
| dolphm | morganfainberg: anyway, i'm almost wondering if the majority of our gate failures are caused by rabbit | 14:07 |
| dolphm | morganfainberg: the second | 14:07 |
| morganfainberg | dolphm, wouldn't surprise me. rabbit in some configurations is awful. | 14:07 |
| morganfainberg | dolphm, ++ that was what i was thinking. | 14:07 |
| morganfainberg | wonder if kombu or rabbit went stupid on us | 14:08 |
| dolphm | morganfainberg: know if zeromq is more reliable? | 14:08 |
| morganfainberg | dolphm, last i heard zeromq was not very reliable in OpenStack | 14:08 |
| dolphm | morganfainberg: i just mean zeromq itself | 14:09 |
| dolphm | morganfainberg: support is broken in icehouse, afaik | 14:09 |
| morganfainberg | my experience with zeromq has been headaches with saltstack | 14:09 |
| morganfainberg | so i don't know overall reliability | 14:09 |
| dolphm | morganfainberg: lol | 14:10 |
| dolphm | morganfainberg: re-reading this bug https://bugs.launchpad.net/keystone/+bug/1332666 ... | 14:11 |
| uvirtbot | Launchpad bug 1332666 in keystone "Keystone token poor performance. Need index on user_id" [Medium,In progress] | 14:11 |
| dolphm | morganfainberg: that query should never be emitted for GET /v3/revoked, right? | 14:11 |
| dolphm | err /v2.0/revoked | 14:11 |
| morganfainberg | nope | 14:11 |
| morganfainberg | as far as i can tell, we don't do that query on /v2.0/revoked | 14:11 |
| dolphm | that just looks like token validation to me | 14:11 |
| morganfainberg | except, i am not seeing that query on token validation either | 14:11 |
| morganfainberg | the only time we do a filter by user_id is on delete_tokens | 14:12 |
| *** gabriel-bezerra has quit IRC | 14:12 | |
| morganfainberg | afaict | 14:12 |
| *** gabriel-bezerra has joined #openstack-keystone | 14:12 | |
| morganfainberg | which would imply some kind of revoke tokens for user / trust / etc | 14:12 |
| dolphm | morganfainberg: are you running with uuid? | 14:13 |
| stevemar | morganfainberg, the second option | 14:13 |
| dolphm | morganfainberg: but it's not a delete..? unless we're doing a select & delete :( | 14:13 |
| morganfainberg | shouldn't matter, .get_token() is by token id which is indexed | 14:13 |
| dstanek | catching up..... dolphm: i don't think zmq has the reliability of rabbit | 14:13 |
| stevemar | marekd, ping? | 14:14 |
| dolphm | dstanek: i.e. it's worse than rabbit? | 14:14 |
| *** cjellick has joined #openstack-keystone | 14:14 | |
| *** cjellick has quit IRC | 14:15 | |
| morganfainberg | dolphm, 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 IRC | 14:15 | |
| dstanek | dolphm: in my experience it's much faster for realtime messaging - but doesn't have all of the reliablilty/clustering | 14:15 |
| dstanek | dolphm: depends on your usecase | 14:15 |
| *** gabriel-bezerra has joined #openstack-keystone | 14:15 | |
| *** cjellick has joined #openstack-keystone | 14:15 | |
| marekd | stevemar: ding dong | 14:16 |
| dolphm | dstanek: that was basically my intuition, but i don't know a damn thing about it | 14:16 |
| dolphm | if anyone uses ack, i just discovered -Q and <3 | 14:17 |
| *** andreaf_ has quit IRC | 14:17 | |
| *** andreaf has quit IRC | 14:17 | |
| *** andreaf has joined #openstack-keystone | 14:18 | |
| lbragstad | per the api validation discussion: http://paste.openstack.org/show/87619/ | 14:18 |
| lbragstad | those ^ are the values provided in the exception that dstanek mentioned | 14:18 |
| stevemar | marekd, trying to use your list projects and domain patch | 14:18 |
| *** ukalifon1 has quit IRC | 14:19 | |
| marekd | stevemar: ++ | 14:19 |
| stevemar | i'm creating a client based on the session of an unscopedsamlplugin, is that the right idea? | 14:19 |
| marekd | stevemar: i think so. the idea here is to store unscoped token and later send it in X-Auth-Token in the HTTP header | 14:20 |
| stevemar | marekd, did you get it working in your env? | 14:21 |
| stevemar | marekd, http://paste.openstack.org/show/87621/ | 14:22 |
| dolphm | why have we defined a private method in the token persistence driver interface lol | 14:22 |
| marekd | stevemar: hmm, let me see that. | 14:23 |
| dstanek | lbragstad: is that the jsonschema exception you are dissecting? | 14:23 |
| lbragstad | dstanek: yep | 14:23 |
| lbragstad | ex.instance is what ever the user put in | 14:24 |
| lbragstad | that failed the validation | 14:24 |
| dstanek | lbragstad: i'm not really sure what to do here, but it would be nice to give the user as much information as possible | 14:26 |
| lbragstad | dstanek: I agree | 14:27 |
| *** mrmoje has joined #openstack-keystone | 14:27 | |
| *** andreaf_ has joined #openstack-keystone | 14:28 | |
| *** andreaf_ has quit IRC | 14:28 | |
| lbragstad | right now, we try to pull out the property that failed validation and the value (ex.instance) | 14:28 |
| lbragstad | if we can't do that, we just pass the message, | 14:28 |
| *** topol has joined #openstack-keystone | 14:29 | |
| lbragstad | which is pretty much the same thing. | 14:29 |
| lbragstad | dstanek: morganfainberg had a suggestion that might be an option too? | 14:31 |
| dstanek | lbragstad: yeah, i agree with morganfainberg's comment on handling at the wsgi layer - beyond that i don't know how to present that information | 14:33 |
| dstanek | lbragstad: someone must have an example of really good error messaging | 14:33 |
| lbragstad | dstanek: I used a similar format to what nova's v3 api had | 14:34 |
| lbragstad | I think I changed it though, based on bknudson's comment in the spec | 14:34 |
| *** david-lyle has joined #openstack-keystone | 14:35 | |
| bknudson | to be consistent with other error messages it should be mostly useless. | 14:35 |
| * lbragstad ba dum pshh | 14:36 | |
| dstanek | bknudson: i nearly spit out my coffee just now | 14:37 |
| stevemar | classic bknudson | 14:44 |
| *** bvandenh has quit IRC | 14:45 | |
| *** lbragstad has quit IRC | 14:46 | |
| dstanek | morganfainberg: after our conversation at the summit i was motivated to crank out a real quick prototype of a jsonschema object model | 14:46 |
| dstanek | https://etherpad.openstack.org/p/jsonschema-objects | 14:46 |
| morganfainberg | cool | 14:47 |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: CRUD grant don't check user_id and group_id https://review.openstack.org/107973 | 14:48 |
| *** chandankumar has quit IRC | 14:48 | |
| *** tziOm has quit IRC | 14:49 | |
| openstackgerrit | A change was merged to openstack/identity-api: Update OS-EP-FILTER API https://review.openstack.org/106292 | 14:49 |
| dolphm | bknudson: hat tip, sir | 14:50 |
| dolphm | dstanek: it looks like ex.message is sufficient to me | 14:51 |
| *** tziOm has joined #openstack-keystone | 14:51 | |
| *** vhoward has joined #openstack-keystone | 14:52 | |
| *** thedodd has joined #openstack-keystone | 14:54 | |
| *** ayoung has joined #openstack-keystone | 14:55 | |
| *** lbragstad has joined #openstack-keystone | 14:56 | |
| dstanek | I'm totally fine with that. I have one more issue left in that before I +2. | 14:56 |
| dstanek | dolphm: i remember seeing a comment from you about adding py3 testing support...do we want that here? | 14:56 |
| *** shausy2 has quit IRC | 14:57 | |
| lbragstad | dstanek: speaking of py33, I added test_validation.py to those tests, | 15:02 |
| lbragstad | breaks on i18n | 15:02 |
| dolphm | dstanek: 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 |
| dolphm | need a vm... | 15:02 |
| dolphm | lbragstad: i didn't see py33 issues outside of test_validation, so i'm fine to skip it for the moment and add later | 15:03 |
| lbragstad | dolphm: http://logs.openstack.org/83/86483/29/check/gate-keystone-python33/908ce52/console.html | 15:03 |
| lbragstad | yeah, it only looks like i18n stuff | 15:03 |
| dstanek | dolphm: i just added a py33 issue to the review | 15:03 |
| dstanek | otherwise i'd +2 it now | 15:03 |
| dolphm | lbragstad: oh that's a strange failure though... | 15:03 |
| dolphm | morganfainberg: you good with skipping i18n for now? ^ | 15:04 |
| dolphm | err skipping py33 support in test_validation | 15:04 |
| lbragstad | dstanek: I'll respin | 15:04 |
| dstanek | i can post a patch in a few minutes to get it working on py33 | 15:04 |
| lbragstad | nothing else in py33 testing uses i18n? | 15:04 |
| dolphm | lbragstad: that failure doesn't look like your fault | 15:04 |
| dstanek | lbragstad: probably not | 15:04 |
| lbragstad | ok | 15:05 |
| dolphm | lbragstad: can you repro that locally? | 15:05 |
| lbragstad | well, we are using i18n in the validation module | 15:05 |
| lbragstad | I'd need to set up a py 33 env | 15:05 |
| *** chandankumar has joined #openstack-keystone | 15:07 | |
| *** richm has joined #openstack-keystone | 15:07 | |
| *** joesavak has joined #openstack-keystone | 15:08 | |
| dstanek | it looks like introducing i18n creates failures in other places | 15:09 |
| dstanek | lbragstad: are you planning to respin because of my comment? i think i can retract my -1 and fix the py3 issue in another patch | 15:13 |
| dstanek | lbragstad: you've opened a can of worms for me | 15:13 |
| morganfainberg | dolphm, yeah good with skipping i18n if needed. | 15:13 |
| lbragstad | dstanek: :) | 15:13 |
| lbragstad | dstanek: I can respin my review | 15:14 |
| dstanek | lbragstad: no need for me | 15:14 |
| lbragstad | building a py33 virtualenv at the moment | 15:14 |
| dolphm | dstanek: morganfainberg: +2 from me then https://review.openstack.org/#/c/86483/ | 15:15 |
| dolphm | lbragstad: if this starts gating, be sure to propose subsequent patches with --no-rebase to avoid resetting the gate | 15:16 |
| dolphm | lbragstad: subsequent patches to dependent reviews* | 15:16 |
| morganfainberg | dolphm, dstanek, lbragstad, +2 from me provided dstanek is ok with it | 15:16 |
| lbragstad | dolphm: sounds good | 15:17 |
| morganfainberg | (I didn't +A) | 15:17 |
| dstanek | morganfainberg: i just commented on all of the things and gave it a +2 | 15:17 |
| morganfainberg | dstanek, cool | 15:17 |
| lbragstad | it will be easier to do the dependent patches now, since they don't all have to be linear | 15:17 |
| nkinder | any cores (other than morganfainberg) care to give a quick review to https://review.openstack.org/#/c/103325/ ? | 15:17 |
| morganfainberg | dstanek, dolphm, just hit +A | 15:17 |
| nkinder | ...not that I don't like morganfainberg. He's just reviewed it already. ;) | 15:17 |
| lbragstad | nkinder: I was taking a look at that yesterday, | 15:17 |
| nkinder | lbragstad: cool. Any questions on anything? | 15:18 |
| morganfainberg | nkinder, awww. *sniffle* I liked the implication you just didn't want my input :P | 15:18 |
| lbragstad | nkinder: 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 myself | 15:18 |
| *** gabriel-bezerra has quit IRC | 15:18 | |
| * morganfainberg might be a bit loopy looking at token code -- without coffee | 15:18 | |
| morganfainberg | lbragstad, this one is less about ldap and more about NoneType.lowere() desn't work | 15:19 |
| *** gabriel-bezerra has joined #openstack-keystone | 15:19 | |
| *** tziOm has quit IRC | 15:19 | |
| morganfainberg | lbragstad, the attributes explicitly mapped to None are always going to be None in the dict, so calling .lower() on them raises an exception | 15:19 |
| morganfainberg | since they're not a string value | 15:19 |
| lbragstad | right, | 15:19 |
| lbragstad | ok | 15:19 |
| morganfainberg | revert the changes to the ldap.core | 15:20 |
| morganfainberg | and run the new test | 15:20 |
| morganfainberg | you'll see how it fails | 15:20 |
| morganfainberg | it'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 |
| lbragstad | ok | 15:21 |
| *** tziOm has joined #openstack-keystone | 15:21 | |
| *** thedodd has quit IRC | 15:29 | |
| nkinder | lbragstad: yeah, what morganfainberg says is correct | 15:29 |
| *** thedodd has joined #openstack-keystone | 15:32 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone-specs: Endpoint policy extension https://review.openstack.org/99842 | 15:39 |
| openstackgerrit | henry-nash proposed a change to openstack/keystone-specs: Endpoint policy extension https://review.openstack.org/99842 | 15:43 |
| henrynash | ayoung: 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/99842 | 15:44 |
| ayoung | henrynash, anything will be an improvement. Looking now | 15:45 |
| ayoung | henrynash, "set of endpoints" I assume that is just an implicit set, and not a new entity we are creating. Right? | 15:46 |
| henrynash | ayoung: you mean liek a region? If so, yes | 15:46 |
| henrynash | ayoung: I AM proposing a group of endpoints…basically re-using the work on endpint filtering | 15:47 |
| henrynash | ayoung: which was the real thing I was concerned about…since that didn’t seem to be what you had been thinking | 15:47 |
| ayoung | henrynash, hmmmm. We already have another form of endpoint grouping going in. it is going to get confusing, as one endpoint could be in multiple groups | 15:47 |
| ayoung | and the same is true of "sets" | 15:47 |
| ayoung | we need a way to unambiguosly say "this is the right policy for this endpoint" | 15:48 |
| henrynash | ayoung: I don’t mean to use the same phyiscal groups | 15:48 |
| openstackgerrit | Harry Rybacki proposed a change to openstack/keystonemiddleware: Example JSON files should be human-readable https://review.openstack.org/108211 | 15:48 |
| ayoung | henrynash, lets maybe turn the terminology around | 15:48 |
| ayoung | call them policy groups? | 15:48 |
| henrynash | ayoung: Ok | 15:48 |
| ayoung | and a policy group covers services and endpoints? | 15:49 |
| henrynash | ayoung: yes | 15:49 |
| ayoung | an endpoint will always resolve to a single policy group | 15:49 |
| henrynash | ayoung: yes | 15:49 |
| ayoung | we have a default policy group, and explicit assignment | 15:49 |
| ayoung | anything more implicit will be added later | 15:49 |
| henrynash | ayoung: I think we should allow region | 15:49 |
| henrynash | ayoung: I think you said that an endpoint can be in more than region, but I didn’t udnerstand that… | 15:50 |
| openstackgerrit | Harry Rybacki proposed a change to openstack/python-keystoneclient: Example JSON files should be human-readable https://review.openstack.org/108210 | 15:50 |
| ayoung | henrynash, if an endpoint cannot be assigned to multiple regions, then regions are the right abstraction. I didn't think that was true, though | 15:50 |
| henrynash | ayoung: I don’t think taht was true | 15:50 |
| henrynash | ayoung: well an endpoint has a single regon_id field | 15:50 |
| ayoung | henrynash, that might work | 15:51 |
| ayoung | if we say that is the primary region, and only the primary region is covered buy the policy | 15:51 |
| ayoung | henrynash, 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 clean | 15:52 |
| henrynash | ayoung: sounds liek a good thing to do | 15:52 |
| bknudson | trying to run tests for havana and all the keystoneclient tests are failing because stevedore isn't installed. | 15:53 |
| ayoung | henrynash, join #openstack-dev and we'll see if we can find Pipes. | 15:53 |
| dstanek | if anyone has a few minutes to kill i have a few easy reviews starting at https://review.openstack.org/#/c/108405/ | 15:55 |
| lbragstad | dstanek: what was the issue with https://review.openstack.org/#/c/108406/1/tox.ini ? | 16:00 |
| henrynash | ayoung: sorry,I need to drop off…but this looks like a godod direction…I’ll be back on later | 16:01 |
| ayoung | henrynash, I'll comment about regions on the review | 16:01 |
| bknudson | tests pass when I add stevedore to test-requirements.txt | 16:01 |
| bknudson | I picked a victim to recheck no bug in stable/havana gerrit... will post the change to stable/havana if it fails the same way | 16:02 |
| dolphm | proposed renaming the Identity program to the TripleA program, and adopting pycadf https://review.openstack.org/#/c/108739/ | 16:02 |
| dolphm | topol: morganfainberg: ^ | 16:03 |
| topol | dolphm, COOL!!! | 16:03 |
| morganfainberg | dolphm, ++ would we also adopt policy under that rename? | 16:03 |
| morganfainberg | dolphm, or does policy still fall outside of AAA? | 16:03 |
| henrynash | dolphm: sorry, I will miss the irc meeting tonight..will be in transit | 16:03 |
| dolphm | interestingly, there are only 8 contributors to openstack/pycadf with about 60 commits | 16:04 |
| morganfainberg | since policy is part of authorization | 16:04 |
| dolphm | morganfainberg: policy is still incubated in oslo | 16:04 |
| morganfainberg | dolphm, right, i mean planning wise | 16:04 |
| morganfainberg | dolphm, policy should graduate in Kilo | 16:04 |
| dolphm | morganfainberg: if we want to push for it to be released, i think it'd make sense to move it to triplea | 16:04 |
| *** hrybacki_ is now known as hrybacki | 16:04 | |
| dolphm | henrynash: ack | 16:05 |
| topol | dolphm I have Tong Li on my team maintaining pycadf and giving it love and care now | 16:05 |
| morganfainberg | dolphm, 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 CVE | 16:05 |
| * lbragstad keeps reading triplea as tripleo | 16:05 | |
| dolphm | topol: as of recently? they're not on my list of 8 | 16:05 |
| morganfainberg | or some gap (not that i see it at the moment) | 16:05 |
| bknudson | we should be major league not triple a | 16:05 |
| dolphm | bknudson: lol. | 16:06 |
| topol | dolphm, yes he picked it up for me when Gordon left IBM | 16:06 |
| bknudson | Gordon doesn't get to work on it anymore? | 16:06 |
| topol | bknudson, he does | 16:07 |
| dolphm | topol: my list of 8, fwiw http://pasteraw.com/g0ztedxpamkal4xnhdvk1aavg5dx7no | 16:07 |
| topol | bknudson but I dont give him direction any more | 16:07 |
| dolphm | gordon has definitely contributed the most | 16:08 |
| topol | dolphm and I suspect he will continue to do so | 16:08 |
| morganfainberg | dolphm, commented on the patch ^ | 16:08 |
| ayoung | dolphm, 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, jus | 16:08 |
| ayoung | t that we don't *force* a method attribute onto a plugin any more. | 16:08 |
| morganfainberg | dolphm, i'm in support of it | 16:08 |
| ayoung | If you want to go further, I'm all for it, but this is a minimal viable patch. | 16:09 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove `with_lockmode` use from Trust SQL backend. https://review.openstack.org/97059 | 16:10 |
| dolphm | ayoung: pulling the existing approach would break backwards compatitiblity | 16:10 |
| dolphm | ayoung: and yes, it just needs docs | 16:10 |
| topol | dolphm, saw your list. yes Tong will start showing up on the contribution list | 16:10 |
| *** gabriel-bezerra has quit IRC | 16:10 | |
| dolphm | ayoung: you can deprecate the existing approach if you feel that's appropriate | 16:10 |
| dolphm | topol: same list by commits http://pasteraw.com/ibz6ahxd9ql8yytw7sh0ef8u35hjdwz | 16:10 |
| *** gabriel-bezerra has joined #openstack-keystone | 16:11 | |
| topol | dolphm. yep. make sense. | 16:12 |
| dolphm | topol: where did gordon go btw? | 16:12 |
| topol | dolphm enovance now red hat | 16:12 |
| topol | dolphm, 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 all | 16:15 |
| morganfainberg | dolphm, 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 |
| morganfainberg | make 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 time | 16:17 | |
| dolphm | morganfainberg: ++ make a kilo dir | 16:17 |
| morganfainberg | TilapiA? | 16:17 |
| dolphm | morganfainberg: ooooOOOOoh | 16:17 |
| topol | dolphm :-) | 16:17 |
| *** xianghui has quit IRC | 16:20 | |
| *** mrmoje has quit IRC | 16:21 | |
| *** afazekas has quit IRC | 16:21 | |
| *** marcoemorais has joined #openstack-keystone | 16:22 | |
| morganfainberg | dolphm, http://triplea.sourceforge.net/mywiki | 16:22 |
| dolphm | morganfainberg: yeah we're adopting that too | 16:22 |
| morganfainberg | LOL | 16:22 |
| morganfainberg | sweet | 16:22 |
| dolphm | morganfainberg: and changing the license from GPL | 16:23 |
| morganfainberg | ahaha | 16:23 |
| morganfainberg | right ASLv2 | 16:23 |
| *** tomoiaga has quit IRC | 16:28 | |
| topol | so dolphm, will you make an announce on the mailing list regading tripleA? | 16:29 |
| dolphm | topol: 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 |
| dolphm | topol: then raise to the mailing list, then ask for TC blessing | 16:30 |
| topol | dolphm, SOUNDS GREAT!!! | 16:31 |
| *** gyee has joined #openstack-keystone | 16:34 | |
| *** lbragstad has quit IRC | 16:35 | |
| openstackgerrit | A change was merged to openstack/keystone: Initial implementation of validator https://review.openstack.org/86483 | 16:36 |
| openstackgerrit | A change was merged to openstack/keystone: Implicitly ignore attributes that are mapped to None in LDAP https://review.openstack.org/103325 | 16:37 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/106208 | 16:40 |
| *** dims has quit IRC | 16:46 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy https://review.openstack.org/101017 | 16:46 |
| *** thedodd has quit IRC | 16:48 | |
| *** thedodd has joined #openstack-keystone | 16:49 | |
| *** lbragstad has joined #openstack-keystone | 16:51 | |
| *** lbragstad has quit IRC | 16:52 | |
| openstackgerrit | Arun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling. https://review.openstack.org/95300 | 16:52 |
| *** hrybacki has quit IRC | 16:56 | |
| *** thedodd has quit IRC | 17:01 | |
| openstackgerrit | A change was merged to openstack/keystone: Regenerate sample config file https://review.openstack.org/108405 | 17:03 |
| openstackgerrit | A change was merged to openstack/keystone: Fixed tox cover environment to share venv https://review.openstack.org/108406 | 17:04 |
| *** lbragstad has joined #openstack-keystone | 17:05 | |
| openstackgerrit | A change was merged to openstack/keystone: Adds coverage report to py33 test runs https://review.openstack.org/108407 | 17:05 |
| stevemar | marekd, ping? | 17:05 |
| *** amerine has quit IRC | 17:13 | |
| *** amerine has joined #openstack-keystone | 17:13 | |
| marekd | stevemar: hey | 17:16 |
| marekd | sorry, had to leave for an hour. | 17:16 |
| marekd | i am looking at this error, i recall i had it working. | 17:17 |
| stevemar | marekd, np, did you get back to my question? about using the project list? i was in a bunch of meetings | 17:17 |
| marekd | stevemar: ^^ | 17:17 |
| dstanek | how do you 'unstick' a review? just post a comment? https://review.openstack.org/#/c/102735/7 | 17:17 |
| marekd | dstanek: from the next-review? :P | 17:18 |
| *** harlowja_away is now known as harlowja | 17:19 | |
| dstanek | ah, nm - rebase will likely fail now anyway | 17:22 |
| arunkant | ayoung and AAA core: Made some change on https://review.openstack.org/95300 based on earlier review comments..can you please review it | 17:22 |
| dstanek | marekd: :-P | 17:28 |
| openstackgerrit | A change was merged to openstack/keystone: Mark the 'check_vX_token' methods deprecated https://review.openstack.org/107560 | 17:28 |
| *** gokrokve has joined #openstack-keystone | 17:29 | |
| marekd | dstanek: i sometimes have the same problem :P | 17:30 |
| marekd | (if your question was about next-review :P) | 17:31 |
| ayoung | arunkant, 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 |
| ayoung | arunkant, its on my list of starred reviews, though. I'll keep an eye on it | 17:32 |
| *** htruta has joined #openstack-keystone | 17:33 | |
| dstanek | lbragstad: i think these last few patches will go much faster now that the approach is solidified in your original commit | 17:34 |
| *** chandankumar has quit IRC | 17:34 | |
| lbragstad | dstanek: agreed, working on the assignment validation patch now | 17:34 |
| dstanek | lbragstad: cool, i'm looking at the next one | 17:34 |
| lbragstad | dstanek: thanks for the reviews, I appreciate it | 17:35 |
| *** gabriel-bezerra has quit IRC | 17:35 | |
| *** gabriel-bezerra has joined #openstack-keystone | 17:35 | |
| dstanek | lbragstad: what is the reasoning behind having parent_region_id either a string or null? | 17:40 |
| lbragstad | parent_region_id can be null, | 17:40 |
| arunkant | thanks 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 |
| dstanek | lbragstad: is that not true of the other optional fields? | 17:42 |
| lbragstad | dstanek: digging | 17:44 |
| dstanek | lbragstad: to me that implies that parent_region can be a string, null or left out entirely | 17:45 |
| lbragstad | right | 17:45 |
| lbragstad | i think, if we wanted to only have parent_region_id be of type 'string' | 17:46 |
| lbragstad | validation would still work if we didn't provide parent_region_id in the request, | 17:46 |
| lbragstad | and if we did provide a string as the parent_region_id | 17:46 |
| lbragstad | but it wouldn't pass validation if we set parent_region_id = None in the request. | 17:47 |
| dstanek | lbragstad: exactly | 17:47 |
| dstanek | lbragstad: i was looking in the v3 docs to see if there was something may be this one different, but couldn't find anything | 17:47 |
| lbragstad | ok | 17:48 |
| lbragstad | so, I'll fix that to fail validation if parent_region_id is None | 17:48 |
| dstanek | lbragstad: it's probably more correct than some of the others because that's what you need to do in an update to clear the field | 17:48 |
| lbragstad | if parent_region_id is provided in the request, it must be a string | 17:48 |
| lbragstad | dstanek: oh, pass in None... | 17:49 |
| dstanek | lbragstad: right, that's why i think you need to to be a string or a null | 17:49 |
| lbragstad | ok, so apply that to other optional arguments | 17:49 |
| lbragstad | to allow a user to pass in None to clear the field | 17:50 |
| lbragstad | dstanek: that is what you mean right? | 17:52 |
| *** rodrigods has joined #openstack-keystone | 17:52 | |
| openstackgerrit | Arun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling. https://review.openstack.org/95300 | 17:54 |
| dstanek | lbragstad: yes, we should probably have a test case showing that behavior | 17:56 |
| lbragstad | dstanek: ok, I'll get that added. | 17:56 |
| *** gokrokve has quit IRC | 18:00 | |
| *** jamielennox|away is now known as jamielennox | 18:09 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy https://review.openstack.org/101017 | 18:12 |
| *** gabriel-bezerra has quit IRC | 18:15 | |
| *** gabriel-bezerra has joined #openstack-keystone | 18:16 | |
| afaranha | Whats 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 IRC | 18:25 | |
| *** thedodd has joined #openstack-keystone | 18:27 | |
| *** lbragsta_ has joined #openstack-keystone | 18:27 | |
| *** lbragstad has quit IRC | 18:30 | |
| *** dims has joined #openstack-keystone | 18:30 | |
| *** lbragsta_ has quit IRC | 18:31 | |
| *** nkinder has quit IRC | 18:32 | |
| *** lbragstad has joined #openstack-keystone | 18:32 | |
| *** mrmoje has joined #openstack-keystone | 18:33 | |
| *** marcoemorais has quit IRC | 18:33 | |
| *** lbragstad has quit IRC | 18:34 | |
| *** lbragstad has joined #openstack-keystone | 18:34 | |
| openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain https://review.openstack.org/107194 | 18:35 |
| *** lbragstad has quit IRC | 18:39 | |
| *** lbragstad has joined #openstack-keystone | 18:40 | |
| *** afazekas has joined #openstack-keystone | 18:44 | |
| *** nkinder has joined #openstack-keystone | 18:44 | |
| *** shakamunyi has joined #openstack-keystone | 18:56 | |
| *** marcoemorais has joined #openstack-keystone | 18:57 | |
| *** david-lyle has quit IRC | 18:59 | |
| *** kwss_ has joined #openstack-keystone | 19:00 | |
| *** lbragstad has quit IRC | 19:03 | |
| *** marcoemorais has quit IRC | 19:07 | |
| *** lbragstad has joined #openstack-keystone | 19:08 | |
| *** marcoemorais has joined #openstack-keystone | 19:08 | |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Adds several more test modules that pass on Py3 https://review.openstack.org/102735 | 19:10 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Fixes test_exceptions.py for Python3 https://review.openstack.org/102737 | 19:10 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Fixes test_wsgi for Python3 https://review.openstack.org/102736 | 19:10 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Disables LDAP unit tests https://review.openstack.org/108808 | 19:11 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Reduces the amount of mocked imports for Python 3 https://review.openstack.org/108809 | 19:11 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Add the new oslo.i18n as a dependency for Python 3 https://review.openstack.org/108810 | 19:11 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Fixes a capitalization issue https://review.openstack.org/108811 | 19:11 |
| openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain https://review.openstack.org/107194 | 19:13 |
| *** marcoemorais has quit IRC | 19:13 | |
| *** lbragstad has quit IRC | 19:22 | |
| *** lbragstad has joined #openstack-keystone | 19:24 | |
| openstackgerrit | Kristy Siu proposed a change to openstack/keystone-specs: generic-mapping-federation https://review.openstack.org/104301 | 19:28 |
| openstackgerrit | A change was merged to openstack/keystone: Updated from global requirements https://review.openstack.org/106208 | 19:28 |
| *** marcoemorais has joined #openstack-keystone | 19:31 | |
| *** david-lyle has joined #openstack-keystone | 19:34 | |
| dolphm | jamielennox: building the milestone now: https://launchpad.net/python-keystoneclient/+milestone/0.10.0 | 19:35 |
| marekd | stevemar: had time to look at keystone websso? | 19:35 |
| jamielennox | dolphm: cheers | 19:35 |
| dstanek | bknudson: checking out those comments now | 19:35 |
| stevemar | marekd, not yet | 19:35 |
| dolphm | marekd: the second change here hasn't merged- https://blueprints.launchpad.net/python-keystoneclient/+spec/add-saml2-cli-authentication | 19:36 |
| dolphm | marekd: is it necessary for the bp? | 19:36 |
| marekd | stevemar: understood. i was just hoping for live commit-comment-commit ping-pong. | 19:36 |
| marekd | dolphm: let me check. | 19:36 |
| gyee | kwss, you have the code for generic mapping I can look at? | 19:36 |
| dolphm | marekd: it looks like the answer is yes | 19:37 |
| marekd | dolphm: plugins are technically indepdent, but functionally unscoped token only is pointless. | 19:37 |
| dolphm | jamielennox: this patch is why i didn't release last week https://review.openstack.org/#/c/99704/ | 19:38 |
| marekd | dolphm: ++ | 19:38 |
| jamielennox | dolphm: yea, the SAML stuff is going to be caught a little mid-cycle but that should be ok to say not ready until 0.11 | 19:38 |
| dolphm | jamielennox: so you recommend cutting 0.10.0 without https://review.openstack.org/#/c/99704/ ? | 19:39 |
| dolphm | jamielennox: and bumping the bp to 0.11.0 ? | 19:39 |
| stevemar | dolphm, 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 |
| jamielennox | dolphm: oh, wasn't sure if cutting the blueprint was a "it's done" moment | 19:40 |
| jamielennox | um, if we release 0.11 in a week i don't think it matters | 19:40 |
| jamielennox | i wasn't sure how close that review was to merging | 19:40 |
| stevemar | kwss_, marekd i don't like the name 'mapped' as a plugin :( | 19:40 |
| ayoung | OK, what am I missing. connection = mysql://root:keystone@127.0.0.1/keystone?charset=utf8 but db_syn is erroring out with "Access denied for user 'keystone'@'localhost' (using password: YES)") None None | 19:40 |
| kwss_ | stevemar, noone likes it whatever I call it :( what would you choose? | 19:41 |
| dolphm | jamielennox: you've followed that review closer than i have! | 19:41 |
| ayoung | mapped is the right name stevemar | 19:41 |
| marekd | ayoung: -- | 19:41 |
| stevemar | kwss_, haha, i dunno external is already taken | 19:41 |
| jamielennox | dolphm: i had a -1 a few days ago, hadn't seen since | 19:41 |
| stevemar | ayoung, meh, it still seems weird | 19:42 |
| jamielennox | dolphm: i tried to build an environment that i could actually test these out with and failed | 19:42 |
| jamielennox | so i'm just going on looks | 19:42 |
| kwss_ | stevemar, ayoung can we compromise and call it external-mapped? :P | 19:42 |
| ayoung | the plugins are for authentication methods, though, so I am not certain that the Federation stuff even blongs in there | 19:42 |
| ayoung | kwss_, I've been thinking about this. | 19:42 |
| *** shakamunyi has quit IRC | 19:42 | |
| dolphm | jamielennox: marekd: alright, i'll bump the saml2 cli bp to 0.11.0 and get 0.10.0 onto pypi right now | 19:42 |
| marekd | dolphm: makes sense. | 19:42 |
| gyee | stevemar, kwss_, what's wrong with just calling it federated plugin | 19:42 |
| stevemar | dolphm, you just made mhu a happy man | 19:42 |
| ayoung | I need to be able to tell the client what to do, hence my current review request to remove the "method" froom the auth plugins | 19:43 |
| kwss_ | gyee, ask ayoung lol | 19:43 |
| stevemar | gyee, i like federated, | 19:43 |
| gyee | kwss_, you have the url for the code changes for the generic map? | 19:43 |
| ayoung | the federated plugin basically is saying "I'm going to deliver a handful os standard values" right? | 19:43 |
| jamielennox | i thought we'd gone away from trying to jam federation through the existing auth plugins? | 19:43 |
| jamielennox | make it it's own apache 'landing page' | 19:43 |
| ayoung | jamielennox, that is my thinking, but I want to get the issue clear here now that we have kwss_ handy | 19:44 |
| marekd | gyee: you are talking about simplified mapping ? | 19:44 |
| marekd | gyee: why would you need that? | 19:44 |
| kwss_ | gyee, https://review.openstack.org/#/c/105597/ | 19:44 |
| ayoung | kwss_, so in your view, the "federated" plugin would handle what values? | 19:44 |
| gyee | marekd, I need it to do the x.509 cert auth | 19:44 |
| jamielennox | marekd: it doesn't change the mapping syntax it just makes it more common amongst plugins | 19:44 |
| gyee | ayoung, it handles mapping like what it does today | 19:44 |
| marekd | jamielennox: 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 mapping | 19:45 |
| marekd | gyee: but simplified mapping or reengineered federation? | 19:45 |
| jamielennox | marekd: the server side mapping one | 19:45 |
| kwss_ | ayoung protocol+idp* | 19:45 |
| ayoung | kwss_, "the protocol used" is exactly what the auth plugin mechanism is to do. That does not belong to "federated" | 19:45 |
| gyee | marekd, actually I need both | 19:45 |
| ayoung | kwss_, the only thing that I would agree is IdP | 19:45 |
| marekd | gyee, but why simplified mappings? | 19:46 |
| ayoung | IdP is used to look up the mappings. | 19:46 |
| gyee | marekd, so I can add x.509 as an IdP | 19:46 |
| ayoung | gyee, ARGH | 19:46 |
| kwss_ | gyee, marekd is talking about a different spec | 19:46 |
| ayoung | no x.509 is not an IdP | 19:46 |
| *** gabriel-bezerra has quit IRC | 19:46 | |
| marekd | jamielennox: ahh, one global mapping ruleset instead of mapping tied to idP? | 19:46 |
| gyee | ayoung, its the same mechanism | 19:46 |
| kwss_ | marekd, gyee is talking about applying mapping generically across federation protocols | 19:46 |
| ayoung | it is a mechanism. If anything should be a method it is "X.509" | 19:46 |
| gyee | federation is a concept | 19:47 |
| gyee | I never look at it as a protocol | 19:47 |
| ayoung | gyee, It could potentially ber definied by the mapping plugin. | 19:47 |
| *** gabriel-bezerra has joined #openstack-keystone | 19:47 | |
| jamielennox | marekd: no i don't think so, just removing the mechanism from saml a bit such that it can be shared by things like X509 | 19:47 |
| marekd | jamielennox, gyee: https://review.openstack.org/#/c/100280/ yeah, i thought you wanted this. | 19:47 |
| marekd | which was -2d during the hackthathon. | 19:47 |
| marekd | i also started wondering why would you want to have it back. | 19:48 |
| ayoung | right...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 |
| jamielennox | marekd: no, don't know that one | 19:48 |
| marekd | jamielennox: ack. | 19:48 |
| marekd | jamielennox: anyways, https://review.openstack.org/#/c/99704 i think i addressed your comments here. | 19:49 |
| ayoung | kwss_, did you see the proof of concept I did using the SAML plugin and mod_identity_lookup? It was an Kerberos authentication | 19:49 |
| gyee | marekd, lemme take a look at that review again | 19:49 |
| ayoung | IN that case, the "method" should have been Kerberos | 19:49 |
| ayoung | http://adam.younglogic.com/?p=3175&preview=true | 19:49 |
| marekd | also, regarding that review: https://review.openstack.org/#/c/106751/ i left one comment for you. | 19:49 |
| marekd | jamielennox: ^^ | 19:49 |
| kwss_ | ayoung, I remember looking at it but do you have a link so I can refresh my memory? | 19:49 |
| ayoung | kwss_, coming right up... | 19:50 |
| ayoung | kwss_, http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/ | 19:50 |
| ayoung | its a lot of code, don't try to read the whole thing... | 19:51 |
| ayoung | let me focus you down to where things matter | 19:51 |
| ayoung | kwss_, look for the part "Here is how I fetch a token." | 19:52 |
| * ayoung needs to do a better job at internal anchors | 19: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 |
| ayoung | kwss_, so that really should just read "methods": ["kerberos"], "kerberos:{} | 19:53 |
| ayoung | kwss_, for the Kerberos/SSSD/mod_lookup_identity case, the Keystone server already has enough information to look up the idp | 19:53 |
| gyee | method should be federated, and IdP is kerberos | 19:53 |
| jamielennox | marekd: commented, nit about pulling out _BaseSamlAuth2 - otherwise i'm +2 | 19:53 |
| marekd | gyee: jamielennox looking. | 19:53 |
| *** gabriel-bezerra has quit IRC | 19:53 | |
| ayoung | I suspect that is the case across the board: that information does not need to be in the token request itself | 19:53 |
| kwss_ | ayoung, so the switching on protocol should happen in the federated extension? where the auth_payload is inserted? | 19:54 |
| ayoung | kwss_, So the "kerberos" method should be mapped to the federated extension | 19:54 |
| *** CraigALee has joined #openstack-keystone | 19:54 | |
| ayoung | kwss_, look at this patch.... | 19:54 |
| *** gabriel-bezerra has joined #openstack-keystone | 19:54 | |
| ayoung | https://review.openstack.org/#/c/107873/ | 19:55 |
| ayoung | kwss_, that means that any "external" authentication method caould then be serviced by the same plugin | 19:55 |
| ayoung | then the question is reduced down to "what do we do about the identity_provider value?" | 19:55 |
| jamielennox | ayoung: isn't that a seperate issue from federation though? | 19:56 |
| *** gabriel-bezerra has quit IRC | 19:56 | |
| ayoung | I 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 in | 19:56 |
| *** gabriel-bezerra has joined #openstack-keystone | 19:57 | |
| * dolphm is finally filling out his expense report for his trip to the valencia | 19:57 | |
| kwss_ | ayoung, it's needed for mapping though | 19: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 this | 19:59 |
| jamielennox | dolphm: so about AUTH_INTERFACE, do you see another way around that? | 19:59 |
| ayoung | kwss_, 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 differently | 20:01 |
| kwss_ | regardless of what it's named | 20:01 |
| ayoung | SAML 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 |
| ayoung | Mapping is common behavior. SAML is protocol specific | 20:02 |
| kwss_ | ayoung, saml is yes but it might not be the case for other protocols | 20: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 protocol | 20:03 |
| ayoung | kwss_, 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 |
| ayoung | Second is converting from the values extracted by that process to Keystone values | 20:05 |
| ayoung | this really needs to be a pipeline. | 20:05 |
| ayoung | THe Federation stuff has to follow after the unpacking | 20:05 |
| ayoung | and 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 pipeline | 20:05 |
| *** lbragstad has quit IRC | 20:06 | |
| raildo | morganfainberg: If you have some free time, you could review this spec? https://review.openstack.org/#/c/101017/ :-D | 20:06 |
| ayoung | kwss_, 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-keystone | 20:07 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel https://review.openstack.org/106917 | 20:07 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module https://review.openstack.org/107561 | 20:07 |
| jamielennox | ayoung: are we supporting the case where this can be processed within keystone? | 20:07 |
| ayoung | jamielennox, I would say "yes" in the abstract, but not implement that up front | 20:07 |
| *** lbragstad has joined #openstack-keystone | 20:08 | |
| ayoung | jamielennox, I would say that, if Kent wants to support SAML in Keystone, they should be able to do so, but use common Mapping code | 20:08 |
| openstackgerrit | Marek Denis proposed a change to openstack/python-keystoneclient: Scope unscoped saml2 tokens. https://review.openstack.org/99704 | 20:08 |
| marekd | jamielennox: ^^ fixed | 20:08 |
| jamielennox | right, but are you talking about a custom implementation that just does what mod_shib does, or having an auth_plugin for everything | 20:09 |
| jamielennox | because forcing this through auth_methods is bad | 20: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 protocols | 20:09 |
| dolphm | jamielennox: https://pypi.python.org/pypi/python-keystoneclient/ | 20:09 |
| jamielennox | dolphm: woohoo! | 20:09 |
| ayoung | jamielennox, 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 there | 20:09 |
| ayoung | but the mod_id_lookup case would be methods: [kerberos] | 20:09 |
| ayoung | and mod shib soulbe be method: SAML | 20:10 |
| ayoung | mapping is constant. and needs to happen after authentication | 20:10 |
| jamielennox | ayoung: why does a mod_XXX require a method? | 20:10 |
| ayoung | jamielennox, 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 |
| ayoung | :) | 20:10 |
| marekd | ayoung: but we can make one plugin, that accepts various methods (saml2, kerberos) and loads smaller subplugins. | 20:11 |
| kwss_ | marekd, exactly | 20:11 |
| marekd | and the mapping can be left in the outer plugins. | 20:11 |
| ayoung | kwss_, 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 view | 20:11 |
| jamielennox | ayoung: federation is going to have to work completely differently | 20:11 |
| marekd | something like kwss_ proposed in re-engineered federation. | 20:11 |
| ayoung | jamielennox, that is why I am trying to extract the mapping part from the rest of the SAML handshake | 20:11 |
| ayoung | marekd, there are two steps: one is to unmarshall the variables, and the second is to map them | 20:12 |
| dolphm | jamielennox: so releasing keystonemiddleware will default everyone to use v3 - i'm thinking we should wait until after the milestone for that | 20:12 |
| ayoung | unmarshalling is protocol specific. Mapping is agnostic | 20:12 |
| jamielennox | so 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 load | 20:12 |
| marekd | ayoung: ++ | 20:12 |
| ayoung | jamielennox, what we need is a way to say "after you go through the set of methiods, run the mapping plugin" | 20:13 |
| marekd | let's than make one 'wrapper plugin' that includes protocol agnostic characteristics (mapping) and loads, if required, smaller protocol-specific plugins. | 20:13 |
| ayoung | jamielennox, example: X509 client cert and Kerberos, MFA | 20:13 |
| dolphm | morganfainberg: we have no hudson bot on keystonemiddleware :( | 20:13 |
| jamielennox | ayoung: so back one step, why does a call to /OS-FEDERATION/identity_providers/{idp}/protocols/{p} go through methods at all? | 20:14 |
| ayoung | Client 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 header | 20:14 |
| *** fausto has joined #openstack-keystone | 20:14 | |
| jamielennox | dolphm: 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 gate | 20:14 |
| ayoung | the mapping needs to be smart enough to handle the values that are set by both methods, plus whatever comes from LDAP via mod_lookup_identity | 20: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 authenticate | 20:14 |
| ayoung | kwss_, well, attribute extension is far more likely to be done in HTTPD via a mod | 20:15 |
| ayoung | mod_uaht_kerb and mod_nss in my case | 20:15 |
| ayoung | mod_auth_kerb and mod_nss | 20: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 |
| morganfainberg | dolphm, yeah trying to figure that out, haven't been able to | 20:16 |
| ayoung | kwss_, 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 request | 20:16 |
| dolphm | morganfainberg: time or infra afk? | 20:16 |
| morganfainberg | dolphm, a little of both | 20:16 |
| ayoung | kwss_, so back to my Proof of concept, look at the keystone.conf section | 20:17 |
| ayoung | I had | 20:17 |
| ayoung | methods=external,password,token,saml2 | 20:17 |
| ayoung | 3saml2=keystone.auth.plugins.saml2.Saml2 | 20:17 |
| ayoung | drop the "external" part | 20:17 |
| ayoung | and replace saml2 with Kerberos | 20:17 |
| ayoung | so it should read something like | 20:17 |
| ayoung | methods=kerberos,password,token | 20:18 |
| ayoung | kerberos==keystone.auth.plugins.mapped.Mapped | 20:18 |
| kwss_ | ok, but what if the protocol you want to add doesn't store the attributes in the environment? | 20:18 |
| ayoung | kwss_, then you would need a custom plugin to do that marshalling, so it would become | 20:19 |
| ayoung | methods=saml,password,token | 20:19 |
| ayoung | samle==keystone.auth.plugins.saml.Saml | 20:19 |
| *** CraigALee has quit IRC | 20:19 | |
| ayoung | make that | 20:19 |
| ayoung | saml==keystone.auth.plugins.saml.SamlMapped | 20:19 |
| ayoung | with SamlMapped being new code that handles unmarshalling SAML, and then calls the Mapped plugin | 20: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 |
| ayoung | you need the SAML unmarshalling regardless. the Mapping then just becomes a reusable resource | 20:20 |
| ayoung | Not duplicate, subclass | 20:20 |
| ayoung | or, 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 |
| ayoung | As running Mappiong before SAML would be bogus | 20:21 |
| ayoung | kwss_, I would think that, under the current technology, it would be paste-api configured | 20:21 |
| ayoung | I 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 |
| bknudson | dstanek: 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 it | 20:22 |
| jamielennox | dolphm: so do you know of a solution for AUTH_INTERFACE? | 20:23 |
| ayoung | kwss_, 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 pipeline | 20:23 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini#n102 would then have an additional | 20:23 |
| dstanek | bknudson: yes, i was just writing my comment on it | 20:23 |
| ayoung | /v3/auth = api_v3_auth or something | 20:23 |
| ayoung | kwss_, then the confitguration for api_v3_auth would be | 20:23 |
| ayoung | starting with http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini#n87 ... | 20:24 |
| morganfainberg | dolphm, this might be related https://review.openstack.org/#/c/108830/ | 20:24 |
| dolphm | jamielennox: slash, do we need an unscoped catalog, right? | 20:24 |
| dolphm | jamielennox: i need coffee and i'll be right back :) | 20:25 |
| ayoung | pipeline = sizelimit url_normalize xml_body_v3 json_body auth_filter mapping_filter token_signing auth_v3 | 20:25 |
| jamielennox | dolphm: 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 use | 20:26 |
| dolphm | morganfainberg: oh shit, maybe we can fix identity-api here too! :D | 20:26 |
| jamielennox | dolphm: that would be great, however we're going to need to be able to use AUTH as a fallback | 20:26 |
| ayoung | kwss_, I wrote a pipeline on a whiteboard back in January. Looks like this http://t.co/e8ISv55e39 | 20:26 |
| dolphm | jamielennox: but that's only going forward. you still need to consider today's case of no unscoped catalog | 20:26 |
| ayoung | https://twitter.com/admiyoung/status/429060448462577664/photo/1 | 20:26 |
| jamielennox | dolphm: right | 20:26 |
| kwss_ | ayoung, that's pretty hard to read but I get what you're saying I think | 20:27 |
| ayoung | kwss_, but there was no mapping in there. | 20:27 |
| dolphm | jamielennox: /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 them | 20:27 |
| jamielennox | dolphm: 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 |
| ayoung | kwss_, 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 mapping | 20:30 |
| *** radez is now known as radez_g0n3 | 20:31 | |
| ayoung | kwss_, ++ | 20:31 |
| *** gabriel-bezerra has quit IRC | 20: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 end | 20:32 |
| ayoung | kwss_, 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 mapped | 20:32 |
| ayoung | the implementation is that "everything goes through mapping" needs to be clarified: that is not part of the explicit token request | 20:33 |
| hrybacki | jamielennox: I shot you an email with some issues I ran into btw | 20:33 |
| *** gabriel-bezerra has joined #openstack-keystone | 20:33 | |
| ayoung | kwss_, I think that the IdP should be extracted in the mapping section. I am not convinced it has any place in the token request itself | 20:33 |
| ayoung | the user shouldnot be telling you what IdP to use | 20:34 |
| jamielennox | hrybacki: i've seen an email there - i've been saving it till after the run of meetings otherwise i'll forget it | 20:34 |
| ayoung | that should be deduced from the assertion | 20:34 |
| hrybacki | jamielennox: thanks :) | 20:34 |
| kwss_ | ayoung, yes I agree, in SAML we should have access to the issuer which should match the IdP ID | 20:34 |
| *** bklei has joined #openstack-keystone | 20:35 | |
| ayoung | kwss_, so we can drop even the mapped plugin. It will be code implemented by keystone/token/providers/.... , not the auth plugin | 20: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 |
| ayoung | kwss_, I know how that goes. I think we are good | 20:37 |
| ayoung | this was the important point to get across | 20: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 IRC | 20:38 | |
| *** gabriel-bezerra has quit IRC | 20:38 | |
| *** gabriel-bezerra has joined #openstack-keystone | 20:39 | |
| dolphm | jamielennox: https://etherpad.openstack.org/p/keystoneclient-urls | 20:39 |
| jamielennox | dolphm: ok... | 20:43 |
| morganfainberg | dolphm, all fixed once tha tpatch merges, just confirmed with fungi | 20:46 |
| openstackgerrit | Steve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions https://review.openstack.org/108839 | 20:48 |
| dolphm | jamielennox: pop quiz: name everything the session gets out of the auth plugin? | 20:48 |
| jamielennox | endpoints and tokens | 20:50 |
| jamielennox | there is a slightly recursive nature there in that the auth plugin uses the session to get the token but it shouldn't impact anything | 20:50 |
| dolphm | jamielennox: why should the auth plugin be responsible for scoped tokens? | 20:50 |
| dolphm | jamielennox: those don't vary per auth method | 20:50 |
| dolphm | jamielennox: that's not recursive, that's cyclical! | 20:51 |
| jamielennox | dolphm: so in the case of horizon for example you want to be able to use one session with multiple auth plugins | 20:51 |
| jamielennox | thats why you can override auth= on request | 20:51 |
| jamielennox | dolphm: plugins don't save a reference to the session they just get provided it in case they need to do http calls | 20:52 |
| dolphm | jamielennox: i assume the session provides a reference to itself to the plugin, right? | 20:53 |
| *** lbragstad has quit IRC | 20:53 | |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Hierarchical Projects https://review.openstack.org/108841 | 20:54 |
| jamielennox | dolphm: yes https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L447-L454 | 20:54 |
| *** david-lyle has quit IRC | 21:00 | |
| dolphm | jamielennox: need more of these docs btw, otherwise all this is useless https://review.openstack.org/#/c/108839/ | 21:03 |
| marekd | dolphm: morganfainberg ayoung: in case you have few spare minutes, please take a look at: https://review.openstack.org/#/c/108611/ | 21:04 |
| dolphm | marekd: are you planning to implement that in juno or K? | 21:04 |
| marekd | i was hoping for juno. there is already something implemented. | 21:05 |
| jamielennox | dolphm: right, i got the basic ones merged now but i need to red a chuk of the old docs | 21:05 |
| dolphm | jamielennox: red? | 21:05 |
| marekd | dolphm: it's more making it 'mergable' (so clean the code) abut prior to that just get YOUR approval. | 21:05 |
| dolphm | marekd: ack | 21:06 |
| jamielennox | redo | 21:06 |
| marekd | dolphm: see references at the bottom. (we talked about that at the hackathon) | 21:06 |
| *** lbragstad has joined #openstack-keystone | 21:06 | |
| openstackgerrit | Steve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions https://review.openstack.org/108839 | 21:07 |
| *** lbragstad has quit IRC | 21:08 | |
| *** gabriel-bezerra has quit IRC | 21:14 | |
| *** gabriel-bezerra has joined #openstack-keystone | 21:14 | |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Hierarchical Projects https://review.openstack.org/108841 | 21:15 |
| *** lbragstad has joined #openstack-keystone | 21:19 | |
| dolphm | jamielennox: so you always have the auth plugin handling token scoping, right? | 21:21 |
| dolphm | jamielennox: even rescoping? | 21:21 |
| jamielennox | dolphm: scoping happens depending on if you provide project_id/domain_id to the plugin | 21:22 |
| jamielennox | rescoping is not yet an explicit operation, you can do it with v3.Token | 21:23 |
| openstackgerrit | gordon chung proposed a change to openstack/keystonemiddleware: add audit middleware https://review.openstack.org/102958 | 21:26 |
| dolphm | jamielennox: does session instantiate a v3.Token instance itself? | 21:30 |
| dolphm | jamielennox: if not, do you think it should | 21:30 |
| jamielennox | dolphm: no, there is nothing like that yet | 21:30 |
| jamielennox | so what are you trying to do | 21:31 |
| *** david-lyle has joined #openstack-keystone | 21:31 | |
| jamielennox | i've been of the opinion i need a resciope() function for a while | 21:31 |
| jamielennox | it would essentially be | 21:31 |
| jamielennox | return v3.Token(token=session.get_token(old_plugin), project_id=XXXX) | 21:31 |
| jamielennox | but we've never had the concept of automatic scoping | 21:32 |
| *** shakamunyi has joined #openstack-keystone | 21:33 | |
| *** joesavak has quit IRC | 21:34 | |
| dolphm | jamielennox: i'm thinking it shouldn't be an explicit operation | 21:34 |
| jamielennox | ... how do you think that will work? | 21:34 |
| dolphm | jamielennox: 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 |
| dolphm | jamielennox: 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 |
| jamielennox | so 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 better | 21:37 |
| jamielennox | but i dont know if session scope makes sense | 21:37 |
| dolphm | jamielennox: 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 token | 21:38 |
| openstackgerrit | A change was merged to openstack/keystone: Disables LDAP unit tests https://review.openstack.org/108808 | 21:38 |
| stevemar | dolphm, i'm going to use id's, did you want full id's? | 21:39 |
| dolphm | jamielennox: 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 authorization | 21:39 |
| dolphm | stevemar: instead of project_name = 'demo' ? | 21:39 |
| stevemar | yeah | 21:39 |
| jamielennox | session is generally just transport | 21:40 |
| dolphm | stevemar: rewrite the doc later :P follow it's conventions first | 21:40 |
| dolphm | jamielennox: well it's a proxy for transport, right? | 21:40 |
| jamielennox | proxy? | 21:40 |
| dolphm | jamielennox: it wraps a request with authN/Z and sends it on it's way | 21:41 |
| jamielennox | right | 21:41 |
| *** david-lyle has quit IRC | 21:41 | |
| openstackgerrit | Steve Martinelli proposed a change to openstack/python-keystoneclient: Add an example of using v3 client with sessions https://review.openstack.org/108839 | 21:41 |
| jamielennox | but that doesnt lend itself to dealing with scoping of auth right? | 21:41 |
| openstackgerrit | A change was merged to openstack/keystone: Reduces the amount of mocked imports for Python 3 https://review.openstack.org/108809 | 21:42 |
| openstackgerrit | A change was merged to openstack/keystone: Adds several more test modules that pass on Py3 https://review.openstack.org/102735 | 21:42 |
| *** zzzeek has joined #openstack-keystone | 21:42 | |
| openstackgerrit | A change was merged to openstack/keystone: Fixes test_wsgi for Python3 https://review.openstack.org/102736 | 21:42 |
| zzzeek | hi, is rodrigo duarte here ? | 21:42 |
| openstackgerrit | A change was merged to openstack/keystone: Fixes test_exceptions.py for Python3 https://review.openstack.org/102737 | 21:42 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel https://review.openstack.org/106917 | 21:43 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel https://review.openstack.org/106917 | 21:43 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module https://review.openstack.org/107561 | 21:43 |
| dolphm | jamielennox: why not? | 21:45 |
| *** david-lyle has joined #openstack-keystone | 21:46 | |
| dolphm | jamielennox: 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 |
| openstackgerrit | Marek Denis proposed a change to openstack/python-keystoneclient: SAML2 wrapper plugin for full federation authN https://review.openstack.org/106751 | 21:51 |
| *** bklei has quit IRC | 21:51 | |
| marekd | jamielennox: 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 |
| dolphm | lbragstad: /me comes up for air | 21:55 |
| dolphm | lbragstad: have updates for api validation? anything i can do to help? | 21:55 |
| lbragstad | dolphm: got pulled in a few meetings, working on the assignment api patch, | 21:56 |
| *** shakamunyi has quit IRC | 21:56 | |
| dolphm | lbragstad: i'm not doing anything else but api-validation until we cut juno-2 =) let me know what i can do | 21:56 |
| lbragstad | dolphm: what about dstanek's comment here. | 21:56 |
| lbragstad | https://review.openstack.org/#/c/86484/33/keystone/assignment/schema.py | 21:56 |
| lbragstad | first comment | 21:56 |
| *** amcrn has joined #openstack-keystone | 21:57 | |
| dolphm | lbragstad: did you cut the hex_uuid validator? | 21:57 |
| lbragstad | I can push a patch to parameter_types.py that will essentially consist of 'type': 'string' | 21:57 |
| dolphm | parameter type* | 21:57 |
| dstanek | lbragstad: i noticed a lot of duplication because of the id types | 21:57 |
| lbragstad | https://github.com/openstack/keystone/blob/master/keystone/common/validation/parameter_types.py#L31-L36 | 21:57 |
| dolphm | lbragstad: actually, when would we be validation IDs? | 21:57 |
| *** topol has quit IRC | 21:58 | |
| dolphm | lbragstad: on POST /v3/regions we allow user-defined IDs, and a couple calls in OS-FEDERATION, but i think that's it | 21:58 |
| *** gabriel-bezerra has quit IRC | 21:58 | |
| dolphm | there's like 3 total | 21:58 |
| dstanek | dolphm: foreign key ids too | 21:58 |
| dolphm | dstanek: aah. | 21:58 |
| dstanek | lbragstad: nice job btw ... i like the pattern for how this works | 21:59 |
| *** gabriel-bezerra has joined #openstack-keystone | 21:59 | |
| dolphm | lbragstad: dstanek: how about this then? '^[a-zA-Z0-9-]*$' | 21:59 |
| dolphm | dstanek: ++ | 21:59 |
| lbragstad | dstanek: thanks! | 22:00 |
| lbragstad | uuid, I want to say there is a jsonschema format validator for that | 22:00 |
| *** gabriel-bezerra has quit IRC | 22:00 | |
| dolphm | lbragstad: but we don't use plain uuids | 22:00 |
| dstanek | dolphm: that would be fine for me - i'm also fine if it's just a string | 22:00 |
| dolphm | dstanek: i'd rather bake in some url safety | 22:00 |
| dolphm | dstanek: avoid spaces and things that need to be encoded | 22:00 |
| lbragstad | dolphm: yeah, we would have to be careful with the pattern | 22:00 |
| *** gabriel-bezerra has joined #openstack-keystone | 22:01 | |
| lbragstad | morganfainberg: had a case about that earlier | 22:01 |
| dolphm | hell, '^[a-z0-9-]*$' works for me :P | 22:01 |
| dolphm | or make it configurable and default to that | 22:01 |
| lbragstad | that will still fit the 'default' use case for regions | 22:02 |
| dolphm | [validation] id_regex | 22:02 |
| lbragstad | before, I think I was checking the lenght | 22:02 |
| lbragstad | length | 22:02 |
| *** rwsu has quit IRC | 22:02 | |
| lbragstad | and that was a little too strict, | 22:02 |
| bknudson | found an odd issue running with db2... | 22:02 |
| bknudson | when checking against the revocation events | 22:02 |
| bknudson | the expiration time has the accuracy down to nanoseconds. | 22:03 |
| bknudson | and then it says tokens are revoked when they're not | 22:03 |
| dolphm | bknudson: are the nanoseconds 0? | 22:03 |
| dolphm | bknudson: like 12.123456000? | 22:03 |
| bknudson | so mysql has 'expires_at=2014-07-22 22:55:53': | 22:04 |
| bknudson | whereas db2 has 'expires_at=2014-07-22 22:58:44.322976' | 22:04 |
| dolphm | bknudson: oh, db2 is correct then :P | 22:04 |
| dolphm | also, i don't know my decimals, apparently | 22:05 |
| bknudson | microseconds not nanoseconds | 22:05 |
| dolphm | bknudson: ah ++ | 22:05 |
| bknudson | I wonder if I can make mysql more accurate... | 22:06 |
| bknudson | should be easy to make things less accurate | 22:06 |
| dolphm | bknudson: IIRC, it depends on the version of mysql... | 22:06 |
| dstanek | lbragstad: that's a good question...lengths on IDs | 22:06 |
| lbragstad | that's the way I had it when I started this. | 22:07 |
| dolphm | bknudson: MySQL 5.6.4 and up expands fractional seconds support for TIME, DATETIME, and TIMESTAMP values, with up to microseconds (6 digits) precision | 22:07 |
| dolphm | bknudson: which is why we chose microseconds ^^ | 22:07 |
| dolphm | bknudson: what version are you on? | 22:07 |
| bknudson | mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.2 | 22:07 |
| lbragstad | dstanek: for project_create you want domain_id: parameter_types.hex_uuid | 22:07 |
| lbragstad | right? | 22:07 |
| dolphm | lbragstad: cap IDs at 64 chars | 22:07 |
| bknudson | this is my ubuntu 12.04 | 22:07 |
| dstanek | lbragstad: hold on - i'm lost in a sea of your reviews - let me find the first one | 22:08 |
| lbragstad | dolphm: ok, I'll build that into hex_uuid | 22:08 |
| dolphm | bknudson: with clock drift it's all fruitless anyway! | 22:08 |
| lbragstad | dstanek: https://review.openstack.org/#/c/86484/33/keystone/assignment/schema.py | 22:08 |
| gyee | stevemar? | 22:09 |
| *** gabriel-bezerra has quit IRC | 22:09 | |
| dolphm | lbragstad: id_string is probably a better name than hex_uuid, considering it should allow non-hex for regions, idps and protocols | 22:09 |
| dstanek | lbragstad: if that is an ID we generate then i think yes | 22:09 |
| lbragstad | ok | 22:09 |
| lbragstad | but capped at 64 characters | 22:09 |
| bknudson | dolphm: for some reason revocation events marks more tokens as revoked when the accuracy goes up | 22:09 |
| bknudson | which seems weird... you'd think fewer tokens would be revoked | 22:10 |
| dstanek | dolphm: i liked hex_uuid because it only allowed hex character | 22:10 |
| *** gabriel-bezerra has joined #openstack-keystone | 22:10 | |
| bknudson | but maybe it's more the truncation of the timestamp to the nearest second rather than the accuracy | 22:10 |
| dolphm | lbragstad: http://pasteraw.com/54a34clquvocsyyvhnykl5ik6ycwdjx :) | 22:11 |
| dolphm | bknudson: the ones between .000000 and .999999 ? that's up to an additional second worth of tokens that can be revoked | 22:12 |
| dolphm | dstanek: that's the reason i don't like hex_uuid; i'd prefer one rule for all ID values | 22:12 |
| dolphm | lbragstad: 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 got | 22:14 |
| lbragstad | dolphm: sounds good, thanks! | 22:15 |
| dstanek | dolphm: 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 field | 22:15 |
| dolphm | dstanek: but user-defined region IDs, user-defined identity provider IDs, and user defined protocol IDs can have more character than just hex | 22:15 |
| dolphm | dstanek: and the use/application of user-defined IDs is likely to expand further | 22:16 |
| dstanek | dolphm: 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 harder | 22:16 |
| dolphm | dstanek: 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 |
| lbragstad | yep '^[a-fA-F0-9-]*$' | 22:17 |
| lbragstad | dolphm: writing test cases to support that | 22:17 |
| dolphm | lbragstad: and a-z not just a-f | 22:18 |
| lbragstad | ah, right | 22:18 |
| dolphm | lbragstad: 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 easier | 22:19 |
| lbragstad | ok | 22:19 |
| lbragstad | I want to say that is what morganfainberg was talking about | 22:19 |
| lbragstad | when I was having this discussion with him | 22:19 |
| morganfainberg | lbragstad, dolphm, works for me, but we should make sure all IDs are emitted lower then? | 22:20 |
| morganfainberg | *should* be the case. | 22:20 |
| dstanek | dolphm: what about existing IDs? | 22:20 |
| morganfainberg | lbragstad, dolphm, also for domain don't forget we have a non-uuid domain_id ('default') | 22:20 |
| dolphm | dstanek: that's why i was suggesting we make the regex configurable (keystone.conf [validation] id_string_regex, and just have a strict default | 22:21 |
| dolphm | ) | 22:21 |
| dolphm | morganfainberg: ++ my default regex suggestion is '^[a-z0-9-]*$' and 1-64 chars | 22:21 |
| morganfainberg | sure | 22:22 |
| dstanek | yeah, i can see that | 22:22 |
| zzzeek | is it normal to get a lot of failures running keystone tests regarding comparison of XML documents to each other, ordering of nodes? | 22:23 |
| dstanek | i still don't like that invalid data can get through | 22:23 |
| *** dims_ has joined #openstack-keystone | 22:23 | |
| dstanek | zzzeek: nope, let me take a look | 22: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 |
| dolphm | we have an xml comparison thing to specifically ignore that | 22:24 |
| zzzeek | dstanek: OK well, this is a fedora 20 machien that i just installed the libxml2 and all that on, …ok | 22:24 |
| dolphm | (ignore element order) | 22:24 |
| zzzeek | dstanek: my build here might be off | 22:24 |
| dolphm | alright i'm out | 22:24 |
| *** dims has quit IRC | 22:24 | |
| dstanek | zzzeek: do you have the full output of the message? | 22:24 |
| zzzeek | i have a crapload of output let me put it up somewhere | 22:24 |
| zzzeek | dstanek: http://paste.openstack.org/show/87664/ | 22:26 |
| zzzeek | dstanek: 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 IRC | 22:29 | |
| dstanek | zzzeek: i'll take a look in just a sec - chrome is freezing on me | 22:30 |
| zzzeek | dstanek: no hurry, the paste also gets chopped off but you get the picture….. | 22:30 |
| gyee | dolphm, did you just cut a keystoneclient release? | 22:33 |
| jamielennox | gyee: yes | 22:33 |
| gyee | congrats, looks like we just broke horizon gates | 22:33 |
| jamielennox | lol | 22:33 |
| jamielennox | link? | 22:33 |
| gyee | https://review.openstack.org/#/c/91402/ | 22:33 |
| gyee | https://github.com/openstack/python-keystoneclient/commit/dfdb206a664268297a346a4cf899f494f7d236f7 | 22:33 |
| gyee | UserManager interface got changed | 22:34 |
| lbragstad | http://logs.openstack.org/02/91402/5/check/gate-horizon-python26/ecd170a/console.html | 22:34 |
| jamielennox | wtf | 22:34 |
| lbragstad | strange | 22:34 |
| jamielennox | thats there own stupid fault | 22:34 |
| *** david-lyle has joined #openstack-keystone | 22:34 | |
| *** stevemar has quit IRC | 22:35 | |
| gyee | david-lyle, you have anything nice to say to jamielennox? :D | 22:35 |
| jamielennox | broken by https://review.openstack.org/#/c/104766/ | 22:36 |
| jamielennox | horizon is using keystone managers seperate from tthe client | 22:36 |
| gyee | yeah man, why can Horizon stick to the program? | 22:36 |
| gyee | s/can/can't/ | 22:36 |
| jamielennox | actually it appears to be because they are constructing user objects in testing directly | 22:37 |
| *** gabriel-bezerra has quit IRC | 22:37 | |
| jamielennox | and so they construct a fake manager to link it to | 22:37 |
| gyee | yeah, for testing only | 22:38 |
| jamielennox | also - this needs to be a gate test | 22:38 |
| *** gabriel-bezerra has joined #openstack-keystone | 22:38 | |
| gyee | jamielennox, you mean add horizon gate to python-keystoneclient? | 22:39 |
| jamielennox | either way | 22:39 |
| jamielennox | horizon should test master | 22:39 |
| gyee | ++ | 22:39 |
| david-lyle | Horizon does test master | 22:40 |
| jamielennox | maybe we should test keystoneclient against a few things in its gate | 22:40 |
| gyee | david-lyle, then how did that one got merged? | 22:40 |
| david-lyle | well we have dependencies, they pull from the pypi mirrors, your change isn't uploaded to pypi mirror... because it's a change | 22:41 |
| gyee | but we don't upload master to pipy though | 22:41 |
| david-lyle | gyee, I see your point | 22:42 |
| dstanek | david-lyle: they meant test against master ksc | 22:42 |
| gyee | only when we cut the cheese | 22:42 |
| gyee | I mean release | 22:42 |
| david-lyle | but you are likely to break master | 22:42 |
| david-lyle | that's why we use stable releases | 22:42 |
| david-lyle | :D | 22:42 |
| dstanek | david-lyle: if you are using anything other than the public API then yes for sure | 22:43 |
| david-lyle | I'm not sure we're allowed by the greater openstack infra system to use git dependencies in Horizon | 22:43 |
| jamielennox | dstanek: unfortunately public is loosely defined | 22:43 |
| jamielennox | david-lyle: no, but i think you can set up something special for gate | 22:43 |
| dstanek | we actually test keystone against multiple version of the ksc | 22:43 |
| jamielennox | dstanek: not that we recommend that | 22:44 |
| dstanek | jamielennox: no, but against master for sure | 22:44 |
| dstanek | no reason to be caught off guard when a change happens | 22:44 |
| *** thedodd has quit IRC | 22:45 | |
| openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Add string id type validation https://review.openstack.org/108862 | 22:45 |
| jamielennox | david-lyle: so i'm just testing replacing UserManager(None) with just None in keystone_data.py | 22:45 |
| *** huats has quit IRC | 22:45 | |
| *** huats has joined #openstack-keystone | 22:46 | |
| jamielennox | the only reason a manager should be needed by a resource is if you do user_resource.update() or user_resource.delete() or something | 22:46 |
| gyee | we can't mock it? | 22:47 |
| *** topol has joined #openstack-keystone | 22:49 | |
| jamielennox | gyee: we can, i just want to see if the tests need it | 22:49 |
| jamielennox | i don't think i've ever run horizon tests beforre | 22:49 |
| bknudson | turns out when we have low accuracy tempest works and unit tests fail :( | 22:50 |
| *** ayoung has quit IRC | 22:51 | |
| bknudson | maybe the tempest test is incorrect... | 22:51 |
| jamielennox | david-lyle: is there a bug filed yet or should I? | 22:51 |
| *** huats has quit IRC | 22:52 | |
| *** huats has joined #openstack-keystone | 22:52 | |
| *** huats has quit IRC | 22:52 | |
| *** huats has joined #openstack-keystone | 22:52 | |
| bknudson | tempest is testing that you can revoke a token created from an unscoped token and the unscoped token is still valid | 22:53 |
| david-lyle | jamielennox: none that I know of, but may be on recheck page | 22:55 |
| *** zzzeek has quit IRC | 22:57 | |
| *** bknudson has quit IRC | 22:57 | |
| jamielennox | david-lyle: https://review.openstack.org/#/c/108865/ and https://bugs.launchpad.net/horizon/+bug/1347236 | 22:57 |
| uvirtbot | Launchpad bug 1347236 in horizon "Tests fail due to keystoneclient 0.10 release" [Undecided,In progress] | 22:57 |
| *** fausto has quit IRC | 22:57 | |
| *** nkinder has quit IRC | 22:59 | |
| *** hrybacki has quit IRC | 23:01 | |
| *** henrynash has quit IRC | 23:01 | |
| *** xianghui has joined #openstack-keystone | 23:05 | |
| *** zzzeek has joined #openstack-keystone | 23:09 | |
| *** zzzeek has quit IRC | 23:14 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Move fake session to HTTPClient https://review.openstack.org/108868 | 23:17 |
| *** topol has quit IRC | 23:19 | |
| openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain https://review.openstack.org/107194 | 23:20 |
| david-lyle | jamielennox: passes the horizon jobs that were failing, thanks | 23:25 |
| jamielennox | david-lyle: np - sorry about breaking them initially | 23:26 |
| david-lyle | we were doing something stupid there to begin with, but a better integration test strategy for the clients and other openstack maintained dependencies is needed | 23:27 |
| *** xianghui has quit IRC | 23:30 | |
| jamielennox | david-lyle: yea, i've started doing fixutres for the basic keystoneclient stuff like auth and discovery as that's easy to get wrong | 23:36 |
| *** xianghui has joined #openstack-keystone | 23:36 | |
| jamielennox | i agree the clients should probably be providing there own test objects | 23:36 |
| *** david-lyle has quit IRC | 23:38 | |
| openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Add string id type validation https://review.openstack.org/108862 | 23:39 |
| *** lbragstad has quit IRC | 23:40 | |
| *** oomichi has joined #openstack-keystone | 23:50 | |
| *** richm has left #openstack-keystone | 23:51 | |
| *** xianghuihui has joined #openstack-keystone | 23:51 | |
| *** xianghui has quit IRC | 23:54 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/keystone-specs: Explicity request an unscoped token https://review.openstack.org/108071 | 23:57 |
| *** amcrn has quit IRC | 23:58 | |
| *** xianghuihui has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!