*** wwwjfy has joined #openstack-keystone | 00:18 | |
*** markvoelker has joined #openstack-keystone | 00:21 | |
*** lhcheng has joined #openstack-keystone | 00:24 | |
*** ChanServ sets mode: +v lhcheng | 00:24 | |
*** markvoelker has quit IRC | 00:25 | |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: validate_token returns AccessInfo https://review.openstack.org/179486 | 00:27 |
---|---|---|
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Futher refactoring to use AccessInfo https://review.openstack.org/179675 | 00:27 |
*** lhcheng has quit IRC | 00:29 | |
*** henrynash has quit IRC | 00:37 | |
*** henrynash has joined #openstack-keystone | 00:38 | |
*** ChanServ sets mode: +v henrynash | 00:38 | |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Futher refactoring to use AccessInfo https://review.openstack.org/179675 | 00:44 |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo https://review.openstack.org/179676 | 00:44 |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo https://review.openstack.org/179676 | 00:46 |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Futher refactoring to use AccessInfo https://review.openstack.org/179675 | 00:46 |
jamielennox | bknudson: have you had a look at my refactorings on auth_token? | 00:47 |
jamielennox | we seem to have a similar agenda | 00:48 |
bknudson | jamielennox: do you have a link? | 00:48 |
jamielennox | bknudson: starts https://review.openstack.org/#/c/174194/2 | 00:49 |
bknudson | https://review.openstack.org/#/c/174197/ is looking similar! | 00:49 |
jamielennox | bknudson: i was trying to move things around so that auth checking all existed in the validate function | 00:50 |
jamielennox | the enforce endpoint id patch feels like it's in the wrong spot, but it's the only option - so i was trying to make it so AccessInfo was used within the validate function, then move confirm_bind and endpoint enforce into there | 00:51 |
bknudson | jamielennox: with https://review.openstack.org/179486 and https://review.openstack.org/179676 we've got AccessInfo in validate. | 00:53 |
bknudson | it's not difficult to get an AccessInfo, just use the factory | 00:53 |
bknudson | or, keystoneclient validate_token returns an AccessInfo now. | 00:53 |
jamielennox | the factory is one of the first things i fixed with ksa | 00:53 |
jamielennox | yep, so in my refactors i made it so validate returns the accessinfo | 00:54 |
jamielennox | i haven't seen yours yet, i was just letting you know others are out there | 00:54 |
jamielennox | bknudson: ah, cool we get the AccessInfo back directly from the client call | 00:54 |
bknudson | that was one of the things I implemented in the v2 validate_token method to make it easier | 00:55 |
jamielennox | yuk on having to do {'access': access_info} though - if we do the refactor https://review.openstack.org/#/c/174197/4/keystonemiddleware/auth_token/__init__.py first then that becomes easier | 00:56 |
bknudson | I'm expecting that to go away | 00:56 |
*** henrynash has quit IRC | 00:57 | |
bknudson | although we'll always need to serialize the AccessInfo to the cache | 00:57 |
bknudson | and deserialize | 00:57 |
*** henrynash has joined #openstack-keystone | 00:57 | |
*** ChanServ sets mode: +v henrynash | 00:57 | |
jamielennox | hmm, we're going to have issues with serialization of the ksa AccessInfo - just how to make it interoperate with the old methd | 00:58 |
jamielennox | if we have ksc.AccessInfo subclass ksa.AccessInfo maybe we can put a get_data() or something on the base class that returns the full token | 00:59 |
bknudson | jamielennox: are you willing to rebase https://review.openstack.org/#/c/174194/2, etc., onto https://review.openstack.org/#/c/179486/ or https://review.openstack.org/#/c/179676/1 ? | 01:00 |
bknudson | it makes more sense to me to start from the source | 01:00 |
bknudson | I don't really care about https://review.openstack.org/#/c/179675/ so am not worried about that one. | 01:01 |
jamielennox | it should be easy to do 179486 | 01:01 |
bknudson | great | 01:02 |
jamielennox | probably the other is easy enough too | 01:02 |
bknudson | I can just abandon mine since looks like you were in the midst of it already | 01:02 |
jamielennox | bknudson: no worries, just when i saw you doing refactorings i wanted to make sure you were aware of the current ones | 01:03 |
bknudson | I was just experimenting to see how much nicer auth_token would be if it didn't have to reimplement all the token stuff. | 01:03 |
*** bjornar has quit IRC | 01:04 | |
jamielennox | right - it's getting better, i was thinking about how to expose the bind stuff from accessinfo as that's really all that is left that is a direct access i thinj | 01:04 |
bknudson | one thing that seems to be missing in AccessInfo is making getting token binding consistent | 01:04 |
jamielennox | :) | 01:04 |
bknudson | he he | 01:04 |
jamielennox | i wasn't sure if it made sense to return a dictionary with all bind stuff, or do like a kerberos_bind property | 01:05 |
jamielennox | i try to keep the AccessInfo flat where possible | 01:05 |
jamielennox | i think it will make it easier to reimplement if we get a new token format again | 01:06 |
bknudson | it's a class and we can push all the auth_token logic into it if we want. | 01:06 |
*** bjornar has joined #openstack-keystone | 01:06 | |
jamielennox | like move the verification function to accessinfo? | 01:07 |
bknudson | e.g., access_info.confirm_token_bind(mode, env) | 01:07 |
bknudson | unless auth_token should really care about all this. | 01:08 |
jamielennox | bknudson: what's mode? | 01:08 |
bknudson | _BIND_MODE.DISABLED , etc. | 01:08 |
jamielennox | oh - yep | 01:09 |
bknudson | AccessInfo doesn't care about disabled, though. | 01:09 |
jamielennox | bknudson: does that mean we could essentially create a validate() on AccessInfo? | 01:10 |
bknudson | or it can be a name. | 01:10 |
jamielennox | move all of validate_token | 01:10 |
bknudson | sure | 01:10 |
jamielennox | you'd have to pass a fair bit of stuff | 01:10 |
bknudson | auth_token will still have work to do to get the accessinfo from cache or from pki token | 01:11 |
jamielennox | at the moment it looks like just expiry and bind, but endpoint filtering would be there as ewell | 01:11 |
jamielennox | which is probably not a problem | 01:11 |
bknudson | I don't think we'll want accessinfo to talk to the server? | 01:12 |
bknudson | that would be confusing | 01:12 |
jamielennox | no it wouldn't talk to the server, endpoint enforce just checks that either a service_id and/or an endpoint_id exists in the catalog | 01:12 |
bknudson | right, but sometimes you don't have a catalog | 01:12 |
bknudson | e.g., if the token was originally requested with ?nocatalog | 01:13 |
jamielennox | that's a failure for the endpoint_id check | 01:13 |
bknudson | just fetch the catalog from the server if it didn't have one | 01:13 |
jamielennox | but you would have to pass this in anyway as we don't want AccessInfo reading the CONF | 01:13 |
jamielennox | so validate(enforce_service_id='XXX', enforce_endpoint_id='XXX', bind_mode='XXX') | 01:14 |
bknudson | it also needs the env | 01:14 |
jamielennox | https://review.openstack.org/#/c/153296/ | 01:14 |
jamielennox | though gyee is now messing with it again saying he wants to do it from policy rather than in auth_token | 01:15 |
jamielennox | https://review.openstack.org/#/c/177661 is wiht policy - and that's not what i thought he meant | 01:16 |
bknudson | gyee needs to make up his mind. | 01:17 |
bknudson | policy in keystonemiddleware... nasty | 01:17 |
jamielennox | yea, that doesn't sit right with me | 01:17 |
jamielennox | writing policy lines into CONF.keystone_authtoken seems wrong | 01:18 |
bknudson | we'll never be able to get that right | 01:18 |
*** wwwjfy has quit IRC | 01:18 | |
jamielennox | the example: "region_id:12345 or endpoint_id:23456" | 01:19 |
bknudson | if self._enforce_endpoint_constraint: # enforce endpoint constraint | 01:19 |
jamielennox | where is region_id coming from? | 01:19 |
bknudson | that's a really useful comment | 01:19 |
bknudson | auth_ref = access.AccessInfo.factory(body=data, !! | 01:19 |
bknudson | everybody wants AccessInfo | 01:20 |
jamielennox | yea, i did the refactor after i saw that first endpoint enforce not fitting right | 01:20 |
jamielennox | I don't know i see the point in making enforce endpoint a policy rule - surely there's not going to be multiple things you want to match there | 01:21 |
bknudson | lets get this work done on AccessInfo and then it'll be easier to add these new functions. | 01:21 |
jamielennox | and if we were going to do that why wouldn't we just do a global policy rule | 01:21 |
*** markvoelker has joined #openstack-keystone | 01:21 | |
bknudson | I thought every service would have their own policy. | 01:22 |
jamielennox | as far as endpoint enforcement goes i think so to | 01:22 |
bknudson | it uses global CONF... somebody's not going to be happy | 01:22 |
jamielennox | the service is supposed to know in advance what its endpoint_id is | 01:22 |
jamielennox | why do we pass CONF to enforcer? | 01:23 |
jamielennox | it also has use_conf=False | 01:23 |
jamielennox | that may be a summit discussion i think | 01:23 |
bknudson | sounds like the perfect place to discuss this. maybe during the meetup | 01:24 |
bknudson | that'll give us time to get all this AccessInfo refactoring in. | 01:24 |
jamielennox | ok, so rebase on top of https://review.openstack.org/#/c/179676/ ? | 01:25 |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin https://review.openstack.org/173558 | 01:25 |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient-kerberos: Update keystoneclient to 1.3 https://review.openstack.org/179677 | 01:25 |
bknudson | jamielennox: yes, if you think "Refactor _confirm_token_bind takes AccessInfo" makes sense. | 01:26 |
*** markvoelker has quit IRC | 01:26 | |
bknudson | It looked like that one was doing some of the same as some of your changes | 01:26 |
bknudson | (it's always making AccessInfo) | 01:26 |
bknudson | otherwise rebase on the parent and I can work on Refactor _confirm_token_bind takes AccessInfo later. | 01:27 |
jamielennox | the v2/v3 check isn't really better or worse - though i don't like using the dict part of AccessInfo | 01:27 |
bknudson | I still think it's better to stop using "data" (the token dict) | 01:28 |
*** henrynash_ has joined #openstack-keystone | 01:28 | |
*** ChanServ sets mode: +v henrynash_ | 01:28 | |
bknudson | that was my goal is to stop using data throughout here and just have accessinfo | 01:29 |
bknudson | so eventually I was going to have the token cache dealing with accessinfo, too. | 01:29 |
bknudson | and of course rather than getting X_USER_ID, etc, from token dict should be getting it all from access_info | 01:30 |
jamielennox | in ksa i changed https://github.com/openstack/keystoneauth/blob/master/keystoneauth/access.py so there is no dict and the AccessInfo contains the whole token object | 01:31 |
*** henrynash has quit IRC | 01:31 | |
*** henrynash_ is now known as henrynash | 01:31 | |
jamielennox | i'm not sure that was entirely the right thing - because i don't mind AccessInfo being a dict - if it were the real dict and it didn't shove extra 'version' etc information in | 01:32 |
bknudson | so we don't have the bind data? | 01:33 |
jamielennox | we wouldn't have access to it as is, no | 01:34 |
bknudson | so we're eventually going to change keystoneclient validate_token to return this new keystoneauth.access.AccessInfo? | 01:34 |
bknudson | this is going to be a lot of work. | 01:34 |
jamielennox | compatibility is going to be the issue, | 01:34 |
jamielennox | everything in ksa will work with just the ksa AccessInfo | 01:35 |
jamielennox | we'll subclass the old AccessInfo from the appropriate ksa one to give all that additional backwards compat stuff | 01:35 |
jamielennox | s/give/add | 01:35 |
bknudson | nice | 01:36 |
jamielennox | and then most likely ksc.token.validate will always return a ksc.AccessInfo for compat | 01:36 |
bknudson | I didn't notice this: http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n588 | 01:37 |
bknudson | should be easy to change self._validate_token to return the AccessInfo and then don't recreate | 01:37 |
jamielennox | bknudson: yep, i do that in one of my patches | 01:37 |
bknudson | and _build_user_headers already uses AccessInfo | 01:37 |
bknudson | so we're mostly there already | 01:38 |
bknudson | great! | 01:38 |
bknudson | jamielennox: you didn't do anything with the cache? | 01:38 |
jamielennox | bknudson: i didn't change the token data going into the cache but i changed some of how the cache was used | 01:39 |
jamielennox | https://review.openstack.org/#/c/174194/ and https://review.openstack.org/#/c/174196/ | 01:39 |
bknudson | https://review.openstack.org/#/c/179675/2/keystonemiddleware/auth_token/_cache.py -- changed to have cache.store take access_info | 01:40 |
jamielennox | bknudson: probably won't clash - but i'd check that https://review.openstack.org/#/c/174196/4/keystonemiddleware/auth_token/_cache.py is ok with it | 01:41 |
jamielennox | actually - it will clash | 01:42 |
bknudson | I'll just abandon https://review.openstack.org/#/c/179675/ anyways since most of that is done differently | 01:42 |
bknudson | can always just do the cache stuff after the rest of this is done. | 01:42 |
jamielennox | bknudson: what if we rebase your one onto https://review.openstack.org/#/c/174197/4/keystonemiddleware/auth_token/__init__.py | 01:43 |
jamielennox | that's where i return auth_ref from validate | 01:44 |
jamielennox | so it would just be a case of changing it so that instead of always building an AccessInfo from body, you build if it's not an online validation | 01:44 |
bknudson | jamielennox: y, it doesn't matter to me with https://review.openstack.org/#/c/179675 , it's a work in progress anyways | 01:45 |
bknudson | jamielennox: could split out the removal of test_cached_token_not_expired_with_old_style_nix_timestamp into a separate commit from https://review.openstack.org/#/c/174196/4/keystonemiddleware/tests/unit/auth_token/test_auth_token_middleware.py | 01:46 |
bknudson | and the other backwards-compat tests | 01:46 |
jamielennox | bknudson: they are testing the cache interface itself - not the validate_token interface coming from cache | 01:50 |
jamielennox | they test that _cache_get raises Invalid if the token is expired, which is what i was moving back into validate | 01:51 |
jamielennox | bknudson: commented on https://review.openstack.org/#/c/179486/6 i'm not sure i see the point. I get you want an accessinfo for checking bind, but it means you have to do a version check on the auth_ref, whereas before you had the IdentityServer returning the right information | 01:52 |
*** ncoghlan has joined #openstack-keystone | 01:53 | |
bknudson | jamielennox: we can't get rid of the data variable if checking bind requires it. | 01:53 |
jamielennox | we could rebase the confirm bind on top of https://review.openstack.org/#/c/174197/4/keystonemiddleware/auth_token/__init__.py for the same effect | 01:53 |
jamielennox | bknudson: yea, i'm trying to be ruthless with ksa whilst i have the chance, then when i can get feature branches set up for ksc and ksm we'll see what needs to be added back | 01:54 |
*** gokrokve has joined #openstack-keystone | 01:57 | |
bknudson | jamielennox: you don't see the point of https://review.openstack.org/#/c/179486/6/keystonemiddleware/auth_token/_identity.py ? self._client.tokens.validate always returns an AccessInfoV3 | 02:02 |
bknudson | so you always know the type of what's returned | 02:02 |
bknudson | you don't need to check the type | 02:02 |
*** dimsum__ has quit IRC | 02:04 | |
jamielennox | it was just that you need to convert them back to create the data you ned | 02:05 |
jamielennox | and then in https://review.openstack.org/#/c/179676/2/keystonemiddleware/auth_token/__init__.py you have to check version yet again | 02:07 |
jamielennox | i don't know if it cleans it up any until we have something on the accessinfo to extract the bind info | 02:08 |
*** davechen has joined #openstack-keystone | 02:10 | |
*** emagana has joined #openstack-keystone | 02:11 | |
*** davechen1 has joined #openstack-keystone | 02:15 | |
*** davechen has quit IRC | 02:17 | |
*** richm has quit IRC | 02:20 | |
*** markvoelker has joined #openstack-keystone | 02:22 | |
*** markvoelker has quit IRC | 02:27 | |
*** wwwjfy has joined #openstack-keystone | 02:27 | |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin https://review.openstack.org/173558 | 02:32 |
*** wwwjfy has quit IRC | 02:32 | |
openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core https://review.openstack.org/171916 | 02:34 |
openstackgerrit | Jamie Lennox proposed openstack/keystone: Move endpoint policy into keystone core https://review.openstack.org/171448 | 02:34 |
*** wwwjfy has joined #openstack-keystone | 02:34 | |
jamielennox | bknudson: do you have anything proposed for debtcollector in keystoneclient? | 02:36 |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient-saml2: Rename project to keystoneclient-saml2 https://review.openstack.org/173628 | 02:39 |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Allow registering additional plugins https://review.openstack.org/112564 | 02:47 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Simplify request making in auth_token tests https://review.openstack.org/167179 | 02:50 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Create new user plugin tests https://review.openstack.org/167180 | 02:50 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Serialize user auth plugin https://review.openstack.org/167181 | 02:50 |
*** dimsum__ has joined #openstack-keystone | 03:05 | |
*** dimsum__ has quit IRC | 03:10 | |
*** markvoelker has joined #openstack-keystone | 03:23 | |
*** markvoelker has quit IRC | 03:27 | |
*** wwwjfy has quit IRC | 03:27 | |
*** henrynash has quit IRC | 03:34 | |
*** henrynash has joined #openstack-keystone | 03:34 | |
*** ChanServ sets mode: +v henrynash | 03:34 | |
*** lhcheng has joined #openstack-keystone | 04:02 | |
*** ChanServ sets mode: +v lhcheng | 04:02 | |
*** josecastroleon has joined #openstack-keystone | 04:03 | |
*** josecastroleon has quit IRC | 04:05 | |
*** lhcheng has quit IRC | 04:07 | |
*** henrynash has quit IRC | 04:17 | |
*** henrynash has joined #openstack-keystone | 04:17 | |
*** ChanServ sets mode: +v henrynash | 04:17 | |
*** markvoelker has joined #openstack-keystone | 04:24 | |
*** markvoelker has quit IRC | 04:28 | |
*** spandhe has joined #openstack-keystone | 05:21 | |
*** markvoelker has joined #openstack-keystone | 05:24 | |
*** markvoelker has quit IRC | 05:29 | |
*** gokrokve has quit IRC | 05:37 | |
*** gokrokve has joined #openstack-keystone | 05:37 | |
*** lhcheng has joined #openstack-keystone | 05:38 | |
*** ChanServ sets mode: +v lhcheng | 05:38 | |
*** gokrokve has quit IRC | 05:42 | |
*** josecastroleon has joined #openstack-keystone | 06:02 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex https://review.openstack.org/179331 | 06:06 |
*** gokrokve has joined #openstack-keystone | 06:08 | |
*** gokrokve has quit IRC | 06:09 | |
marekd | jamielennox: re: https://review.openstack.org/#/c/177704/7 reading your comment. So, once ksa is released auth part will stay in ksc for deprecation time, right? | 06:09 |
*** gokrokve has joined #openstack-keystone | 06:09 | |
jamielennox | marekd: that was my thought | 06:10 |
marekd | jamielennox: also, I am guessing i'd be allowed to freely rename ffederated to federation in ksa without any tricks for deprecation, backwards compatibility etc? | 06:10 |
jamielennox | auth plugins will be in ksc for a while | 06:10 |
jamielennox | yep | 06:10 |
marekd | jamielennox: ok, i will abandon then this patch and propose new in ksa. | 06:10 |
marekd | jamielennox: bp isn't required, is it? | 06:11 |
jamielennox | marekd: no - though we haven't been adding anything new to ksa yet | 06:12 |
jamielennox | but for a rename feel free | 06:12 |
marekd | ...to add a bp or *not* add a bp ? | 06:12 |
marekd | jamielennox: also, for patch https://review.openstack.org/#/c/173558/4/keystoneclient_kerberos/v3.py what is the purpose of that? YOu want to be able to authenticate via kerberos starting with a OS-FEDERATION like link, like identity_providers/kerberos/protocols/kerberos/auth ? | 06:13 |
jamielennox | marekd: it lets you set up mod_auth_kerb in front of federation just like any other federation method | 06:15 |
jamielennox | you can provide a mapping from the information that comes through env params | 06:16 |
jamielennox | no more kerberos being special | 06:16 |
marekd | jamielennox: so ephemeral users allowed? | 06:16 |
jamielennox | marekd: sure i guess - the same as any other federation thing | 06:16 |
marekd | isn't kerberos authN only, something rather like authenticated/not authenticated ? | 06:17 |
jamielennox | marekd: you can use it with sssd/mod_identity_lookup and it will all tie together | 06:18 |
jamielennox | or you could just match on name | 06:18 |
marekd | jamielennox: if you match on name then you'd rather want to authenticate your local user. | 06:18 |
marekd | REMOTE_USER on steroids | 06:19 |
jamielennox | marekd: more or less | 06:20 |
jamielennox | but even based on what you've got now you can SetEnv from apache in the mod_auth_config settings and you would have the same thing you have now | 06:20 |
jamielennox | or set groups via kerb realm | 06:21 |
jamielennox | as i said, i know adam wants it for mod_identity_lookup and sssd | 06:21 |
*** ajayaa has joined #openstack-keystone | 06:21 | |
jamielennox | so it will fetch additional roles/groups from there | 06:21 |
marekd | jamielennox: btw, it's ksc that will depend on ksa now, once it's released, right? | 06:25 |
jamielennox | yea | 06:25 |
jamielennox | hey marekd, is the first federation call always a GET or should it be a POST? | 06:34 |
marekd | GET | 06:34 |
jamielennox | ok, that's what i had in https://review.openstack.org/#/c/173558/4/keystoneclient_kerberos/v3.py i just wasn't completely sure | 06:35 |
marekd | good :-) | 06:36 |
marekd | btw i commented on this patch | 06:36 |
jamielennox | yep, i saw it | 06:37 |
jamielennox | i don't know about prefixing everything with Federated | 06:38 |
jamielennox | i was just looking for some way to distinguish it from the other one | 06:38 |
jamielennox | i guess i could put it in a different file and still just call it kerberos | 06:38 |
marekd | jamielennox: maybe a docstring will be helpful | 06:38 |
jamielennox | i'd like a name other than 'federation' for all this as well - but i don't konw what to use | 06:39 |
marekd | MappedKerberos ? | 06:40 |
marekd | or you could indeed move it to another file, mapped.py ? | 06:40 |
marekd | but then we should probably make top level classes MappedBaseAuth etc. | 06:40 |
*** dimsum__ has joined #openstack-keystone | 06:42 | |
*** dimsum__ has quit IRC | 06:47 | |
jamielennox | didn't we do that already? | 06:54 |
jamielennox | oh- not it's called FederatedBaseAuth | 06:54 |
marekd | yes, which makes sense in case of protcols like saml, oidc, but...kerberos and similar aren't truly federation protocols. | 06:55 |
marekd | anyway, i am maybe wasting too much time on naming. | 06:55 |
jamielennox | if there was a time to get it straightened out it would be now while KSA is available | 06:56 |
jamielennox | but yea, i haven't been too caught up in that | 06:57 |
marekd | jamielennox: MappedBaseAuth and inheritants make more sense for you than FederatedBaseauth ? | 06:57 |
marekd | better to rename it now, so we can skip deprecations | 06:58 |
jamielennox | i don't know, i use the term federation/federated here because of the module on the server | 06:58 |
jamielennox | all mapped auth is going through /OS-FEDERATION/ so i've stuk with the federation name | 06:58 |
marekd | heh :-) | 06:58 |
marekd | i think this is why i proposed FederatedBaseAuth some time ago... | 06:58 |
jamielennox | maybe during summit we should try and rename it on the server side | 06:59 |
jamielennox | or just map it all to /auth | 06:59 |
marekd | we need distincs URLs | 06:59 |
marekd | distinct | 06:59 |
marekd | so we cannot simply remap to /auth | 06:59 |
jamielennox | right - but you can do /auth/identity_providers/XXX/protocols/XXX/auth is what i meant | 06:59 |
marekd | ah, oh, worth discussing, esp since os-federation is not an extension anymore | 07:00 |
jamielennox | two /auths seems weird, maybe we do it directly to /v3/identity_providers/.... | 07:00 |
jamielennox | marekd: i think that's a good idea given that we want to make mapped authentication the future of auth | 07:03 |
jamielennox | want to blueprint? | 07:03 |
marekd | jamielennox: yeah, worth discussing @ the summit. | 07:04 |
jamielennox | right | 07:04 |
marekd | jamielennox: you are asking if i want to create a bp ? | 07:04 |
marekd | (didn't get it) | 07:04 |
jamielennox | marekd: i can propose it | 07:05 |
marekd | jamielennox: btw, pecan and falcon are roughly replaceable frameworks or they have different purposes? | 07:05 |
jamielennox | marekd: roughly replacable, as with all these things they do some things slightly differently | 07:06 |
jamielennox | be that better or worse for us | 07:06 |
marekd | jamielennox: cause i think falcon was considered recently, whereas ppl are talking about pecan only now. | 07:06 |
marekd | jamielennox: why? | 07:06 |
jamielennox | pecan is on stackforge, the main guy works on opentsack | 07:07 |
marekd | falcon isn't mature enough? | 07:07 |
marekd | aha | 07:07 |
jamielennox | the idea is that we can have more customization to our needs of pecan | 07:07 |
jamielennox | falcon is built by rax so they are involved as well | 07:07 |
jamielennox | but for whatever reason pecan was around first | 07:08 |
jamielennox | i understand they don't want to have every project with a different framework - but why we aren't using something more mainstream i have no idea | 07:08 |
marekd | aha, i thought falcon would be better because they claim it's much faster | 07:09 |
marekd | i didn't even know it's more mainstream than pecan. | 07:09 |
jamielennox | neither are mainstream | 07:13 |
marekd | jamielennox: what is mainstream then? (i don't know much about wsgi frameworks). django customized for rest? | 07:15 |
jamielennox | i think there is something like that, but flask i gues | 07:15 |
*** lhcheng has quit IRC | 07:19 | |
*** lhcheng has joined #openstack-keystone | 07:22 | |
*** ChanServ sets mode: +v lhcheng | 07:22 | |
*** lhcheng has quit IRC | 07:25 | |
*** lhcheng has joined #openstack-keystone | 07:26 | |
*** ChanServ sets mode: +v lhcheng | 07:26 | |
*** markvoelker has joined #openstack-keystone | 07:26 | |
*** markvoelker has quit IRC | 07:30 | |
*** spandhe has quit IRC | 07:30 | |
*** chlong has quit IRC | 07:37 | |
*** csd has quit IRC | 07:49 | |
*** csd has joined #openstack-keystone | 07:51 | |
*** krykowski has joined #openstack-keystone | 07:52 | |
*** jistr has joined #openstack-keystone | 07:59 | |
openstackgerrit | ZhiQiang Fan proposed openstack/python-keystoneclient: return all endpoints if service type is empty https://review.openstack.org/179722 | 08:03 |
*** lhcheng has quit IRC | 08:04 | |
*** bdossant has joined #openstack-keystone | 08:08 | |
*** fhubik has joined #openstack-keystone | 08:13 | |
openstackgerrit | ZhiQiang Fan proposed openstack/python-keystoneclient: add --slowest flag to testr https://review.openstack.org/179725 | 08:14 |
*** ncoghlan has quit IRC | 08:24 | |
*** markvoelker has joined #openstack-keystone | 08:27 | |
*** markvoelker has quit IRC | 08:31 | |
*** fhubik is now known as fhubik_afk | 08:31 | |
*** rlt has joined #openstack-keystone | 08:37 | |
*** pnavarro has joined #openstack-keystone | 08:42 | |
*** krykowski has quit IRC | 08:57 | |
*** krykowski_ has joined #openstack-keystone | 08:57 | |
*** krykowski_ has quit IRC | 09:03 | |
*** krykowski has joined #openstack-keystone | 09:03 | |
*** e0ne has joined #openstack-keystone | 09:04 | |
*** lhcheng has joined #openstack-keystone | 09:04 | |
*** ChanServ sets mode: +v lhcheng | 09:04 | |
*** lhcheng has quit IRC | 09:08 | |
*** e0ne has quit IRC | 09:10 | |
*** _dguerri is now known as dguerri | 09:17 | |
*** fhubik_afk is now known as fhubik | 09:23 | |
*** henrynash has quit IRC | 09:26 | |
*** markvoelker has joined #openstack-keystone | 09:27 | |
*** dguerri is now known as _dguerri | 09:28 | |
*** markvoelker has quit IRC | 09:32 | |
*** _dguerri is now known as dguerri | 09:42 | |
*** fhubik is now known as fhubik_afk | 09:47 | |
*** krykowski has quit IRC | 09:49 | |
*** dguerri is now known as _dguerri | 09:50 | |
*** fhubik_afk is now known as fhubik | 09:50 | |
*** dimsum__ has joined #openstack-keystone | 09:53 | |
*** davechen1 has quit IRC | 10:00 | |
*** krykowski has joined #openstack-keystone | 10:22 | |
*** fhubik is now known as fhubik_afk | 10:26 | |
*** _dguerri is now known as dguerri | 10:27 | |
*** kiran-r has joined #openstack-keystone | 10:28 | |
*** fhubik_afk is now known as fhubik | 10:28 | |
*** e0ne has joined #openstack-keystone | 10:31 | |
*** lhcheng has joined #openstack-keystone | 10:34 | |
*** ChanServ sets mode: +v lhcheng | 10:34 | |
*** kiran-r is now known as _kiran_ | 10:35 | |
openstackgerrit | Kamil Rykowski proposed openstack/keystone-specs: Use oslo-versioned-objects to deal with upgrades https://review.openstack.org/167195 | 10:38 |
*** lhcheng has quit IRC | 10:39 | |
*** samueldmq has joined #openstack-keystone | 10:40 | |
samueldmq | morning | 10:40 |
*** dguerri is now known as _dguerri | 10:43 | |
*** fhubik is now known as fhubik_afk | 10:50 | |
*** fhubik_afk is now known as fhubik | 10:52 | |
dstanek | good morning samueldmq | 11:26 |
samueldmq | dstanek, hey : ) you always up early in the morning | 11:28 |
samueldmq | jamielennox, you around ? see https://review.openstack.org/#/q/branch:master+topic:identity-v3-only-jobs,n,z | 11:28 |
*** ctina_ has joined #openstack-keystone | 11:33 | |
marekd | samueldmq: he's rather asleep | 11:35 |
samueldmq | marekd, yep I think so, but I preferred to ping since his nickname is not 'jamielennox-afk', as it uses to be | 11:37 |
openstackgerrit | Alexey Miroshkin proposed openstack/keystone: Implement backend filtering on membership queries https://review.openstack.org/179758 | 11:38 |
*** dimsum__ is now known as dims | 11:41 | |
*** markvoelker has joined #openstack-keystone | 11:50 | |
*** raildo has joined #openstack-keystone | 11:58 | |
marekd | samueldmq: i have a question actually | 12:01 |
marekd | samueldmq: Dynamic Policy spec | 12:01 |
marekd | so basically you want to configue/keep the policies not in the file but in the DB and make it accessible via API? | 12:01 |
marekd | samueldmq: so other services (nova, glance, ...) will query Keystone as a reference policy store instead of keeping local policy configs in the files? | 12:02 |
marekd | is it the main aim of the spec? | 12:02 |
samueldmq | marekd, yeah | 12:04 |
samueldmq | marekd, policy will be enforce by ksmiddleware, which will fetch the policy (using ksclient) and cache it | 12:04 |
*** aix has joined #openstack-keystone | 12:05 | |
samueldmq | marekd, ksmiddleware will use the engine in oslo.policy to enforce it | 12:05 |
samueldmq | marekd, but yes, the main aim is as you described | 12:05 |
marekd | samueldmq: the policies would be global or could be personalized per project? | 12:06 |
marekd | nova policies, glance policies | 12:06 |
samueldmq | marekd, they can be retrieved per project, as we have today | 12:11 |
marekd | samueldmq: ok | 12:11 |
marekd | just wanted to clarify | 12:11 |
marekd | hopefully i will re-read it today carefully | 12:11 |
samueldmq | marekd, each policy api entry will be prefixed by compute, or identity, and so on | 12:11 |
samueldmq | marekd, to identify where they belong to | 12:12 |
marekd | ok | 12:12 |
marekd | understand | 12:12 |
samueldmq | marekd, nice, I am aplying the feedbacks already there | 12:12 |
samueldmq | marekd, thanks, appreciate your review | 12:12 |
*** shakamunyi has quit IRC | 12:18 | |
samueldmq | david8hu, hi, is this your lp profile https://launchpad.net/~david-j-hu ? | 12:18 |
*** htruta has joined #openstack-keystone | 12:21 | |
*** gordc has joined #openstack-keystone | 12:22 | |
*** fhubik has quit IRC | 12:28 | |
*** fhubik has joined #openstack-keystone | 12:29 | |
*** afaranha has joined #openstack-keystone | 12:30 | |
*** _dguerri is now known as dguerri | 12:38 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Upgrade Foreign key in Endpoint with ondelete='CASCADE' https://review.openstack.org/179767 | 12:42 |
*** iurygregory has joined #openstack-keystone | 12:42 | |
*** dguerri is now known as _dguerri | 12:45 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Upgrade Foreign key in Endpoint with ondelete='CASCADE' https://review.openstack.org/179767 | 12:45 |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: validate_token returns AccessInfo https://review.openstack.org/179486 | 12:49 |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo https://review.openstack.org/179676 | 12:52 |
*** links has joined #openstack-keystone | 12:56 | |
*** fhubik has quit IRC | 12:56 | |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor _build_user_headers doesn't need token_info https://review.openstack.org/179768 | 12:56 |
*** fhubik has joined #openstack-keystone | 12:57 | |
openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor _build_service_headers takes AccessInfo https://review.openstack.org/179770 | 13:00 |
*** bknudson has quit IRC | 13:01 | |
*** ajayaa has quit IRC | 13:10 | |
*** richm1 has joined #openstack-keystone | 13:11 | |
*** dims has quit IRC | 13:14 | |
*** dims has joined #openstack-keystone | 13:15 | |
*** nkinder has quit IRC | 13:15 | |
*** _kiran_ is now known as kiran-r | 13:18 | |
*** mestery_ is now known as mestery | 13:25 | |
*** joesavak has joined #openstack-keystone | 13:29 | |
openstackgerrit | Cyril Roelandt proposed openstack/keystonemiddleware: Prevent a UnicodeDecodeError in the s3token middleware https://review.openstack.org/179777 | 13:30 |
*** bknudson has joined #openstack-keystone | 13:33 | |
*** ChanServ sets mode: +v bknudson | 13:33 | |
*** kiran-r has quit IRC | 13:37 | |
marekd | morganfainberg: i think this can be now abandoned, right? If so, i will do so. https://review.openstack.org/#/c/157327/ | 13:37 |
*** raildo has left #openstack-keystone | 13:38 | |
*** raildo has joined #openstack-keystone | 13:38 | |
*** ctina_ is now known as ctina | 13:45 | |
*** ajayaa has joined #openstack-keystone | 13:46 | |
ajayaa | dolphm, dstanek, bknusdon, morganfainberg I have submitted a spec for having a NoSQL backend for Keystone. Please give your feedback. Here is the link. https://review.openstack.org/#/c/178999/ | 13:48 |
*** edmondsw has joined #openstack-keystone | 13:49 | |
ajayaa | The references given in the page mention the benefit of having a NoSQL backend and there is a link to a wiki for schema design for different backends as well. | 13:50 |
ajayaa | jamielennox, marekd, bknudson ^^ | 13:53 |
*** emagana has quit IRC | 13:53 | |
*** chlong has joined #openstack-keystone | 13:58 | |
*** fhubik has quit IRC | 14:03 | |
*** nkinder has joined #openstack-keystone | 14:07 | |
*** richm1 is now known as richm | 14:08 | |
*** chlong has quit IRC | 14:08 | |
*** ayoung has joined #openstack-keystone | 14:09 | |
*** ChanServ sets mode: +v ayoung | 14:09 | |
*** lhcheng has joined #openstack-keystone | 14:11 | |
*** ChanServ sets mode: +v lhcheng | 14:11 | |
*** _dguerri is now known as dguerri | 14:12 | |
*** dguerri is now known as _dguerri | 14:13 | |
*** _dguerri is now known as dguerri | 14:13 | |
*** e0ne has quit IRC | 14:14 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 14:14 | |
marekd | samueldmq: one more question: how does this api http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#policy compares to your spec? | 14:15 |
marekd | i think this is something henry was reffering to saying it's other services who need work, not keystone. | 14:16 |
*** lhcheng has quit IRC | 14:16 | |
*** pnavarro has quit IRC | 14:18 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Refactor _create_attribute_statement IdP method https://review.openstack.org/172647 | 14:19 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Add openstack_user_domain to assertion https://review.openstack.org/172562 | 14:19 |
*** stevemar has joined #openstack-keystone | 14:23 | |
*** ChanServ sets mode: +v stevemar | 14:23 | |
*** rlt has quit IRC | 14:24 | |
*** rlt has joined #openstack-keystone | 14:25 | |
*** chlong has joined #openstack-keystone | 14:26 | |
*** gokrokve_ has joined #openstack-keystone | 14:34 | |
morganfainberg | marekd: yes. Can be abandoned. | 14:36 |
*** gokrokve has quit IRC | 14:37 | |
openstackgerrit | David Stanek proposed openstack/keystone: Fixes test nits from a previous review https://review.openstack.org/179796 | 14:38 |
edmondsw | ajayaa, added a few comments on your nosql proposal | 14:40 |
*** packet has joined #openstack-keystone | 14:41 | |
*** emagana has joined #openstack-keystone | 14:42 | |
morganfainberg | Everyone: please look at https://libertydesignsummit.sched.org/type/design+summit/Keystone as a first pass - I will want to finalize this tomorrow. | 14:43 |
stevemar | morganfainberg, no dice | 14:44 |
morganfainberg | stevemar: ? | 14:44 |
stevemar | morganfainberg, joke gone wrong, i will review now | 14:44 |
morganfainberg | Hehe | 14:44 |
morganfainberg | I purposefully left one fishbowl tbd and one work session (following that fishbowl) as tbd | 14:45 |
morganfainberg | Until tomorrow. | 14:45 |
bknudson | morganfainberg: shouldn't we get the operator feedback before we discuss priorities? | 14:45 |
morganfainberg | We can swap those. Or we can adjust priorities after operator as well. | 14:46 |
morganfainberg | bknudson: it's really easy to swap these around. | 14:46 |
marekd | morganfainberg: "Work Sessions" will e redefined later or it is time to catch up at the summit and have some work done? | 14:46 |
marekd | (even code related) | 14:46 |
morganfainberg | Work sessions all have the same boring titles | 14:46 |
morganfainberg | They are small rooms. I've added ether pads and general descriptions to them. | 14:47 |
bknudson | I'll just note that I'd prefer it if there were fewer keystone sessions since that means I can go barge in on others. | 14:47 |
morganfainberg | bknudson: I purposefully asked for fewer sessions this time | 14:47 |
dstanek | stevemar: don't quit your day job | 14:48 |
bknudson | what's the deal with PKI tokens? | 14:48 |
morganfainberg | bknudson: a number of the keystone work sessions are "general" meaning kind of like what we did at the table in ATL | 14:48 |
bknudson | seinfeld joke | 14:48 |
morganfainberg | bknudson: I marked those as "office hours" | 14:48 |
stevemar | dstanek, so bknudson and i shouldn't quit our day jobs? | 14:49 |
dstanek | stevemar: nope. but i did laugh once figured out that you were trying to joke :-P | 14:49 |
bknudson | I might have to decide whether to attend one of the work sessions, a security session, etc. | 14:50 |
dstanek | morganfainberg: i don't have any reason to complain about the schedule. | 14:51 |
* dstanek high fives morganfainberg | 14:51 | |
morganfainberg | bknudson: if the work session isn't a general one we can swap it for one of the general ones. | 14:51 |
morganfainberg | bknudson: I figure the keystone group will be mostly in other project sessions this cycle. | 14:52 |
morganfainberg | Err. Summit | 14:52 |
bknudson | that seems to be where we're most needed | 14:52 |
morganfainberg | Yep. | 14:52 |
marekd | morganfainberg: because keystone is finished, now others need to catch up :P | 14:53 |
bknudson | maybe we can have a session where we work on the docs | 14:53 |
*** vhoward has quit IRC | 14:54 | |
morganfainberg | bknudson: I also am considering making he deployment story work session ops track as well | 14:54 |
*** vhoward has joined #openstack-keystone | 14:55 | |
morganfainberg | Or we can swap that one for docs. | 14:55 |
*** gokrokve_ has quit IRC | 14:55 | |
*** gokrokve has joined #openstack-keystone | 14:55 | |
*** links has quit IRC | 14:56 | |
bknudson | having no documentation is going to make it difficult for ops. | 14:56 |
*** henrynash has joined #openstack-keystone | 14:57 | |
*** ChanServ sets mode: +v henrynash | 14:57 | |
*** gokrokve has quit IRC | 14:57 | |
bknudson | I'm not familiar at all with deployment issues. Devstack works fine. | 14:57 |
morganfainberg | bknudson: anyway. Will finalize this stuff tomorrow. I have an appointment I need to run off to. | 14:57 |
bknudson | one deployment issue might be the use of md5 for tokens by default. | 14:58 |
stevemar | bknudson, "Well, it worked in DevStack" cc thingee | 14:58 |
*** gokrokve has joined #openstack-keystone | 14:58 | |
bknudson | if you're trying to have a secure deployment | 14:58 |
bknudson | and other issues that go along with attempting to do a secure deployment, but that's not all keystone. | 14:58 |
marekd | morganfainberg: i am also fine with the schedule. | 14:59 |
*** lmtaylor1 has joined #openstack-keystone | 15:04 | |
*** Bjoern___ has joined #openstack-keystone | 15:04 | |
*** ajayaa has quit IRC | 15:06 | |
*** Bjoern___ is now known as BjoernT | 15:08 | |
*** zzzeek has joined #openstack-keystone | 15:11 | |
*** aix has quit IRC | 15:13 | |
dstanek | just got a weird phone call .. he asked for me by name "david stanek" and when i said that's me is qualifies is with "david stanek from ibm?" | 15:13 |
*** iamjarvo has joined #openstack-keystone | 15:13 | |
dstanek | s/is qualifies is/he qualifies it to/ | 15:13 |
bknudson | there's no david stanek here as far as I can tell | 15:14 |
*** aix has joined #openstack-keystone | 15:15 | |
bknudson | dstanek: that was probably another of stevemar's famous jokes. | 15:16 |
dstanek | if so, then he has successfully confused me | 15:16 |
marekd | bknudson: i just imagined stevemar using batman's tool to change his voice, calling dstanek. | 15:17 |
stevemar | dstanek, oh wow | 15:22 |
stevemar | i actually didn't have anything to do with that | 15:22 |
*** BjoernT has left #openstack-keystone | 15:25 | |
*** e0ne has joined #openstack-keystone | 15:28 | |
*** _cjones_ has joined #openstack-keystone | 15:38 | |
*** mfisch has quit IRC | 15:40 | |
*** mfisch has joined #openstack-keystone | 15:41 | |
*** mfisch is now known as Guest65197 | 15:41 | |
*** _brian has joined #openstack-keystone | 15:45 | |
*** _brian is now known as blewis | 15:46 | |
lbragstad | dolphm: o/ blewis has some work to get nginx working with keystone-deploy on his fork https://github.com/brian-tx/keystone-deploy | 15:47 |
blewis | I submitted a PR - its a rough draft though | 15:47 |
lbragstad | dolphm: I know you had some efforts along the same lines (with or without supervisord?) | 15:48 |
dolphm | blewis: lbragstad: o/ | 15:49 |
lbragstad | wondering if there is a way we can figure out the delta and maybe get an nginx/supervisord branch in master? | 15:49 |
blewis | im thinking about maybe just breaking uwsgi out into its own role and having supervisor manage the process | 15:50 |
dolphm | lbragstad: on friday, i went down the path of deploying a different project i have with nginx + supervisord + gunicorn and then trying to manually install keystone on top of it, but i hadn't gotten it working yet | 15:50 |
*** htruta has quit IRC | 15:50 | |
dstanek | gunicorn didn't give the performance benefits i was hoping to see | 15:52 |
*** mattfarina has joined #openstack-keystone | 15:52 | |
*** htruta has joined #openstack-keystone | 15:53 | |
*** sigmavirus24 is now known as Apsu_ | 15:53 | |
dolphm | dstanek: how did you tune & benchmark it? | 15:53 |
*** Apsu_ is now known as sigmavirus24 | 15:53 | |
dstanek | i just ran the tests and adjusted the number of process according to cpu/memory constraints | 15:54 |
dolphm | dstanek: we were seeing some weird behaviors (aborted connections) with apache on friday, so i was ready to give it up in favor of something that's easier to tune :) | 15:54 |
blewis | im not a fan of gunicorn personally | 15:54 |
lbragstad | blewis: performance issues? | 15:55 |
dstanek | blewis: i actually love gunicorn - that's my goto django deploy | 15:55 |
dstanek | dolphm: aborted connections from apache? | 15:55 |
blewis | performance issues yes | 15:55 |
*** bdossant has quit IRC | 15:56 | |
dolphm | dstanek: yeah | 15:56 |
dolphm | dstanek: probably just a bad tune, but there's so many variables with mpm_event + mod_wsgi :( | 15:56 |
marekd | Do we still require API changes to be shipped with a spec to consider it complete? | 15:56 |
dstanek | dolphm: that's odd...was the box under duress? | 15:56 |
dolphm | dstanek: nope | 15:57 |
dolphm | dstanek: 40% of connections were being dropped regardless of the apparent load on the server, and seemingly regardless of the number of concurrent users (2 or 1000) | 15:57 |
dolphm | dstanek: d34dh0r53 had a pretty good theory to explain the behavior, but we didn't know how to fix the tuning to address it | 15:58 |
*** lhcheng has joined #openstack-keystone | 15:58 | |
*** ChanServ sets mode: +v lhcheng | 15:58 | |
marekd | dolphm: out of curiosity, what was the theory ? | 15:58 |
ayoung | it is not a theory until it has supporting evidence. As of now it is a hypothesis | 16:00 |
dstanek | dolphm: i know this sounds weird, but how do i get a broken environment to look at? | 16:00 |
dolphm | dstanek: send me your public key | 16:01 |
*** gokrokve_ has joined #openstack-keystone | 16:01 | |
dolphm | lbragstad: (is it still running?) | 16:01 |
dolphm | dstanek: send lbragstad* your public key | 16:01 |
*** gokrokve_ has quit IRC | 16:01 | |
dstanek | dolphm, lbragstad: done. let me know if it's still running | 16:02 |
lbragstad | dstanek: the env is still up, | 16:02 |
*** Guest65197 has quit IRC | 16:02 | |
lbragstad | dstanek: we can stress it... cc: dolphm blewis | 16:02 |
*** emagana has quit IRC | 16:03 | |
dstanek | lbragstad: i'll take a look at the box after lunch; is it easy to stress it on demand | 16:03 |
dstanek | ? | 16:04 |
dolphm | dstanek: very | 16:04 |
dstanek | ok, cool | 16:04 |
*** gokrokve has quit IRC | 16:04 | |
dolphm | dstanek: we have two servers to generate load, but one of them has a really simple locust script that just GETs / and reproduces it every time :( | 16:04 |
*** emagana has joined #openstack-keystone | 16:04 | |
*** dguerri is now known as _dguerri | 16:06 | |
*** gokrokve has joined #openstack-keystone | 16:06 | |
dstanek | excellent | 16:06 |
dstanek | dolphm, lbragstad: i'm going to finish what i was working on, go to lunch and then i'll take a look | 16:06 |
*** gokrokve has quit IRC | 16:06 | |
lbragstad | dstanek: awesome | 16:07 |
samueldmq | ayoung, ping - you around ? need to talk about the mechanism to update the unified config file as new projects come ... | 16:07 |
samueldmq | ayoung, I meant the unified policy file | 16:07 |
ayoung | samueldmq, "Here I am!" | 16:07 |
samueldmq | ayoung, hehe | 16:07 |
ayoung | thought you would like that. | 16:07 |
samueldmq | ayoung, did you see dhellmann's comment in the spec ? https://review.openstack.org/#/c/147651/4/specs/backlog/dynamic-policy.rst | 16:07 |
samueldmq | ayoung, yeah I liked :p | 16:08 |
marekd | samueldmq: ayoung": does ksc/osc implement existing policy api calls ? | 16:09 |
ayoung | "Where would that file live in git and how would it be updated as new projects come into the ecosystem?" | 16:09 |
openstackgerrit | Henrique Truta proposed openstack/keystone: Add is_domain field in Project Table https://review.openstack.org/157427 | 16:09 |
samueldmq | ayoung, yes | 16:09 |
ayoung | marekd, I think ksc yes, osc no. But I have not looked. | 16:09 |
ayoung | samueldmq, I would think it should go in its own repo? | 16:09 |
marekd | ayoung: that would be v3.contrib.endpoint_policy ? | 16:09 |
samueldmq | ayoung, it's own repo or in keystone ? | 16:10 |
samueldmq | ayoung, as keystone will now basically be managing all the policies | 16:10 |
dolphm | dstanek: pip install locustio; curl http://cdn.pasteraw.com/n4ecss6x9wciv6j3p29iktrv734x85p > locustfile.py; locust --host=http://104.130.20.208:35357; | 16:10 |
ayoung | samueldmq, I see it comparable to the systempolicy RPM that enforces SELinux | 16:10 |
ayoung | it is not part of the SELinux code base itself | 16:10 |
dolphm | dstanek: and then browse to port 8089 on your dev box or wherever you ran the above | 16:10 |
ayoung | samueldmq, on my machine it is policycoreutils-2.3-7.1.fc21.src.rpm | 16:11 |
samueldmq | ayoung, I am not familiar with selinux | 16:12 |
samueldmq | ayoung, so it has the repo for policies, and the enforcer ? | 16:12 |
ayoung | samueldmq, I'll link | 16:12 |
samueldmq | ayoung, k please | 16:12 |
*** alexsyip has joined #openstack-keystone | 16:17 | |
marekd | samueldmq: what's the purpose of todays policy API ? | 16:18 |
marekd | ayoung: ^^ | 16:18 |
marekd | it stores serialized blobd, right? | 16:18 |
marekd | blobs | 16:18 |
ayoung | marekd, yeah..not suer who uses it | 16:18 |
ayoung | I see it as a false start myself, but I'm biased | 16:18 |
marekd | and blobs are simply what usually sits in the local policy.json files per project? | 16:19 |
marekd | ayoung: who can operate on policy blobs? Only admin? | 16:19 |
samueldmq | ayoung, should the repo be created under oslo ? like oslo.policy-repo | 16:19 |
ayoung | marekd, it depends on policy. | 16:19 |
ayoung | samueldmq, or under keystone, but yes | 16:19 |
samueldmq | ayoung, hmm, so we keep the separate policies for backwards compatibility | 16:20 |
marekd | ayoung: heh, so keystone reads keystone/policy.json to conclude whether nova can fetch its serialized policy from keystone? :-) | 16:20 |
samueldmq | ayoung, and provide an unified as well | 16:20 |
ayoung | probably oslo, with a very deliberate set of reviewers, probably cores from the major projects | 16:20 |
ayoung | marekd, yep, and that is something to make sure we get right | 16:20 |
ayoung | I could see having policy covered by a second, hard coded policy file, instead of the main one | 16:21 |
samueldmq | ayoung, and as the unified policy will be in a common repo, everyone sees all the changes, still better to keep the unified policy consistent | 16:21 |
*** _dguerri is now known as dguerri | 16:21 | |
*** spandhe has joined #openstack-keystone | 16:26 | |
*** iamjarvo has quit IRC | 16:26 | |
samueldmq | ayoung, will we keep separate policy files ? | 16:29 |
ayoung | samueldmq, so...maybe we can keep the files separate, something like | 16:29 |
ayoung | common.json, novar, keystone etc...with a build process that merges them together | 16:30 |
samueldmq | ayoung, k but we need further work than just merging | 16:30 |
samueldmq | ayoung, like standardize the roles, etc | 16:30 |
ayoung | samueldmq, that is in the common section | 16:30 |
*** ajayaa has joined #openstack-keystone | 16:30 | |
* ayoung still looking for the origianl selinux repo | 16:31 | |
samueldmq | ayoung, k I am thinking on the design of the whole thing, and the migration process | 16:31 |
*** krykowski has quit IRC | 16:31 | |
openstackgerrit | Henrique Truta proposed openstack/keystone: List projects filtering by is_domain flag https://review.openstack.org/158398 | 16:31 |
ayoung | samueldmq, I think this is it https://github.com/fedora-selinux/selinux-policy | 16:32 |
ayoung | there might be an even more upstream for the core...still looking | 16:32 |
*** mfisch has joined #openstack-keystone | 16:34 | |
ayoung | samueldmq, actually..it might be more complex: https://github.com/SELinuxProject/selinux/tree/master/policycoreutils | 16:34 |
*** mfisch is now known as Guest19502 | 16:34 | |
samueldmq | ayoung, no readme :/ | 16:36 |
ayoung | samueldmq, I'd like to get the first cut in a flat file | 16:36 |
samueldmq | ayoung, k a flat file to everyone | 16:36 |
ayoung | maybe just unify nova and glance and cinder | 16:36 |
ayoung | neutron has special rules, and Keystone, as pointed out, has security concerns WRT to policy for policy | 16:37 |
ayoung | I wonder what happens if we put neutron's rules into a nova server that does not have neutron's special policy code? | 16:37 |
ayoung | Does it blow up or are they silently ignored? I suspect the latter | 16:38 |
ayoung | samueldmq, the general pattern on a line should be "match projectID and check role" | 16:38 |
ayoung | don't try to have a single rule for the whole api | 16:39 |
ayoung | so | 16:39 |
samueldmq | ayoung, yes but this will come later ... we just need to keep them in a single file | 16:39 |
samueldmq | ayoung, and consistent for now, right? | 16:39 |
ayoung | well, we'll have to change the common rules | 16:39 |
ayoung | http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json | 16:40 |
samueldmq | ayoung, yes, but we still want services passing their existing tests with the unified policy right ? | 16:40 |
ayoung | so, whereever there is "admin_or_owner" | 16:40 |
ayoung | we first expand that out. It can be done programmatically | 16:40 |
*** emagana has quit IRC | 16:41 | |
ayoung | Let me see if I have a demo environemtn I can hack on | 16:41 |
*** rdo has quit IRC | 16:41 | |
samueldmq | ayoung, if we change too much in the first round, it will be hard to services adopt it | 16:42 |
ayoung | samueldmq, agreed. But we want to make as few common rules as possible | 16:42 |
samueldmq | ayoung, I think merging the rules and unifying global rules as 'admin_or_owner' is enough | 16:42 |
samueldmq | for the first round | 16:42 |
*** emagana has joined #openstack-keystone | 16:42 | |
samueldmq | ayoung, yeah sure, I think we are talking the same thing :p | 16:42 |
ayoung | admin_or_owner is likely to be the firstp lace we see confluict. So we do away with it | 16:43 |
ayoung | let me confirm | 16:43 |
bknudson | https://libertydesignsummit.sched.org/event/21f1e738d1ce4e6df06341c881d4b1b2#.VUeh3kS8pLs -- looking forward to that one. | 16:44 |
bknudson | unfortunately we have a keystone session at the same time | 16:44 |
samueldmq | ayoung, after this first roung, we then tell to people: "hey we have a unified policy which works and won't break the way you work today" | 16:44 |
ayoung | bknudson, we are still cleaning up after Termie | 16:45 |
samueldmq | ayoung, "if you want ot modify polciies, go there" | 16:45 |
ayoung | samueldmq, yes. | 16:45 |
stevemar | bknudson, whats the conflicting one? | 16:45 |
samueldmq | ayoung, and then after we get everyone using it, we propose things we need to improve usability, compatibility, consistency, etc | 16:45 |
samueldmq | ayoung, things we have to agree with everyone | 16:45 |
ayoung | then again, we are still cleaning up from the folks he was cleaning up from, too | 16:45 |
ayoung | samueldmq, OK give me a moment to show you waht I mean. | 16:46 |
samueldmq | ayoung, sure | 16:46 |
david8hu | samueldmq, yes, you got my profile | 16:47 |
samueldmq | david8hu, nice, I am adding you as a contributor in the 'Dynamic Policy Overview' specs | 16:48 |
david8hu | samueldmq, Thanks | 16:49 |
*** gokrokve has joined #openstack-keystone | 16:50 | |
samueldmq | david8hu, np | 16:51 |
samueldmq | david8hu, the spec is this one https://review.openstack.org/#/c/147651 | 16:51 |
stevemar | bknudson, oh the keystone working group is going on all morning, we can always pop in and see termie | 16:52 |
samueldmq | david8hu, fell free to read it and get familiar if you aren't yet, also feedbakc is always welcome | 16:52 |
samueldmq | marekd, thanks for your review | 16:53 |
* samueldmq gets excited with the number of reviews that spec is receiving : ) | 16:53 | |
david8hu | samueldmq, contributed couple of -1s already :) | 16:54 |
samueldmq | david8hu, oh sure, just saw your name there, thanks | 16:54 |
*** rdo has joined #openstack-keystone | 16:54 | |
lhcheng | dstanek: ping | 16:57 |
*** ankita_w_ has joined #openstack-keystone | 16:57 | |
*** SpamapS has joined #openstack-keystone | 16:58 | |
ayoung | samueldmq bot | 17:00 |
SpamapS | Hi, I'm trying to figure out why python-keystoneclient doesn't allow one to null out a field since this commit: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=0e9ecaa1 | 17:00 |
SpamapS | The commit message seems somewhat unrelated. :-P | 17:00 |
lhcheng | dstanek: wanted to confirm if you're okay with the current validation on the trusted_dashboard or make it a little more restrictive. https://bugs.launchpad.net/keystone/+bug/1440958 | 17:01 |
openstack | Launchpad bug 1440958 in Keystone "loosen validation on matching trusted dashboard" [Medium,Fix committed] - Assigned to Lin Hua Cheng (lin-hua-cheng) | 17:01 |
SpamapS | jamielennox: ^^ could you by any chance take a look at that commit and help me understand why we need 'filter_none' when updating a user in keystone? | 17:03 |
ayoung | samueldmq, ok, first conflict is on default rule | 17:05 |
ayoung | nova has | 17:05 |
ayoung | "default": "is_admin:True or project_id:%(project_id)s", | 17:05 |
ayoung | cinder has rougly the same thing | 17:05 |
*** dguerri is now known as _dguerri | 17:06 | |
ayoung | glance has "default": "", | 17:06 |
ayoung | cinder tends towards rules like this | 17:06 |
ayoung | "default": [["is_admin:True"], ["project_id:%(project_id)s"]], | 17:06 |
ayoung | I'm going to use that one as the common default | 17:06 |
Guest19502 | stevemar: (this is mfisch) have you seen this before? " TypeError: samlize_token() takes at least 7 arguments (6 given)" I'm seeing it while trying to build the keystone package | 17:09 |
Guest19502 | seems related to a test you added | 17:09 |
stevemar | Guest19502, hmm, thats weird | 17:10 |
Guest19502 | thats a function inside keystone itself so it should have never passed gate.. | 17:10 |
Guest19502 | you are certainly only passing in 6 params | 17:11 |
Guest19502 | wonder if that test is skipped on gate | 17:11 |
samueldmq | ayoung, k so the first question is: does this break glance ? | 17:12 |
stevemar | Guest19502, is that happening in test_v3_federation.py ? | 17:12 |
stevemar | Guest19502, i know we mock that function | 17:12 |
samueldmq | ayoung, if it does, let's keep different default roles and all the services using the default policy | 17:12 |
samueldmq | ayoung, and work further in consistency once we get there, right? | 17:12 |
ayoung | samueldmq, I don | 17:13 |
ayoung | samueldmq, I don't think so, but we wuill have to test | 17:13 |
samueldmq | ayoung, ++ | 17:13 |
ayoung | if it does, we need to explicitly add in a rule for the broken call | 17:13 |
samueldmq | ayoung, I understood your approach :) | 17:13 |
ayoung | bascially, there should be no defaults in the normal case | 17:13 |
*** ajayaa has quit IRC | 17:13 | |
ayoung | we might define it for other people, but not for the apis shipped with the code | 17:14 |
samueldmq | ayoung, so we can already propose the rules we want to | 17:14 |
samueldmq | ayoung, and people can adopt it later if they want | 17:14 |
ayoung | yes | 17:14 |
Guest19502 | stevemar: yeah keystone/tests/unit/test_v3_federation.py", line 3176, in test_saml_signing | 17:14 |
Guest19502 | 17:02:44 self.PROJECT) | 17:14 |
Guest19502 | 17:02:44 TypeError: samlize_token() takes at least 7 arguments (6 given) | 17:14 |
samueldmq | ayoung, nice | 17:14 |
dstanek | lhcheng: at lunch right now, but I can take a look when I get back | 17:14 |
* Guest19502 shakes fist at nickserv again | 17:14 | |
*** jistr has quit IRC | 17:15 | |
*** Guest19502 has quit IRC | 17:15 | |
*** Guest19502 has joined #openstack-keystone | 17:15 | |
samueldmq | ayoung, how does ksmiddleware will invalidate the cached policy ? | 17:17 |
samueldmq | 'Marek Denis1:27 PM | 17:17 |
samueldmq | Keystonemiddleware would poll Keystone in some intervals, yes?' | 17:17 |
ayoung | samueldmq, probably follow the rules for the TRL | 17:17 |
stevemar | Guest19502, how are you building the package? seems really weird that it would mess up there | 17:17 |
Guest19502 | jenkins debian biulder | 17:18 |
Guest19502 | builder | 17:18 |
Guest19502 | so pbuilder | 17:18 |
samueldmq | ayoung, TRL ? I know we already have mechanisms to invalidate cached tokens, etc | 17:18 |
samueldmq | ayoung, I am just not familiar with them yet | 17:18 |
ayoung | samueldmq, https://github.com/admiyo/openstack-core-policy/commits/master | 17:19 |
ayoung | token revocation list. Part of the PKI code in auth_token middleware | 17:20 |
ayoung | basically, one minute timeout | 17:20 |
ayoung | we can make it longer or shorter as required. | 17:20 |
samueldmq | ayoung, so it's timeout based .. I think we can use a timestamp with updated_at | 17:22 |
samueldmq | ayoung, some mechanism like this, so ksmiddleware doesn't need to re-fetch if it didnt changed | 17:22 |
samueldmq | change* | 17:23 |
ayoung | samueldmq, yep..all of the HTTP protocol mechanisms at our disposal | 17:23 |
david8hu | samueldmq & ayoung, My question is if the cache is outdated and keystone is not available, how should middleware behave. | 17:23 |
openstackgerrit | Matt Fischer proposed openstack/keystone: Pass-in domain when testing saml signing https://review.openstack.org/179846 | 17:23 |
ayoung | david8hu, with TRL we deny everything | 17:23 |
ayoung | david8hu, since we are moving back to online validation of tokens, that is what would happen anyway | 17:24 |
ayoung | david8hu, with policy, I could say the rule would be "in the absense of Keystone keep processing with the old rules" too | 17:24 |
ayoung | either would work, and maybe we make that a config value | 17:25 |
david8hu | ayoung, I am thinking some kind of hall back machanism. | 17:25 |
david8hu | I mean fall back | 17:25 |
samueldmq | ayoung, I dont see the clue between the TRL, which is to revoke tokens | 17:25 |
samueldmq | ayoung, and the system to invalidate the policy cahce | 17:25 |
ayoung | samueldmq, we fetch and cache the TRL | 17:25 |
*** Guest19502 is now known as mfisch | 17:26 | |
samueldmq | ayoung, david8hu sorry need to go afk for a bit | 17:27 |
*** gokrokve has quit IRC | 17:27 | |
david8hu | ayoung, ok | 17:27 |
*** harlowja has joined #openstack-keystone | 17:34 | |
david8hu | ayoung, I am confused. When middleware checks with the cache, it is the policy file that is cached. How does token get involved? | 17:35 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Refactor _create_attribute_statement IdP method https://review.openstack.org/172647 | 17:35 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Add openstack_user_domain to assertion https://review.openstack.org/172562 | 17:35 |
*** gokrokve has joined #openstack-keystone | 17:41 | |
*** gokrokve has quit IRC | 17:45 | |
*** gokrokve has joined #openstack-keystone | 17:45 | |
samueldmq | david8hu, yeah, the same I was asking for | 17:46 |
samueldmq | david8hu, <samueldmq> ayoung, I dont see the clue between the TRL, which is to revoke tokens | 17:46 |
samueldmq | david8hu, I think the timestamp wiht updated_at + timeout for querying keystone if it has changed is enough | 17:49 |
*** lmtaylor1 has quit IRC | 17:51 | |
bknudson | SpamapS: I thought we merged a correction to https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=0e9ecaa1 | 17:55 |
*** aix has quit IRC | 17:58 | |
*** Ephur has joined #openstack-keystone | 17:58 | |
*** lmtaylor1 has joined #openstack-keystone | 17:58 | |
*** harlowja has quit IRC | 17:59 | |
*** harlowja_ has joined #openstack-keystone | 17:59 | |
david8hu | samueldmq, It sounds like middleware has to explicitly manage the policy file. If token had expired, it means time to check with keystone to see if there is a new policy. Perhaps, policy in the cache is considered valid for the case if keystone is not reachable. | 17:59 |
*** emagana has quit IRC | 18:02 | |
*** chlong has quit IRC | 18:02 | |
david8hu | samueldmq, ayoung, my follow on question is where does this token come from the first place? | 18:03 |
*** Ephur has quit IRC | 18:03 | |
*** EmilienM is now known as EmilienM|mtg | 18:05 | |
*** packet has quit IRC | 18:09 | |
*** emagana has joined #openstack-keystone | 18:11 | |
*** ankita_wagh has joined #openstack-keystone | 18:12 | |
*** chlong has joined #openstack-keystone | 18:15 | |
*** ankita_w_ has quit IRC | 18:15 | |
*** ankita_w_ has joined #openstack-keystone | 18:16 | |
raildo | lbragstad, hey... I didn't understand your comment here: https://review.openstack.org/#/c/158372/48/keystone/tests/unit/test_backend.py | 18:16 |
raildo | lbragstad, Do you mean, create the golden path for test_update_is_domain_project_name? | 18:17 |
lbragstad | raildo: oh, I was just suggesting a name | 18:17 |
raildo | lbragstad, in the second comment | 18:18 |
lbragstad | raildo: oh, yeah, | 18:18 |
*** ankita_wagh has quit IRC | 18:19 | |
lbragstad | raildo: I was just checking to make sure the golden path was tested somewhere (not sure if that test case lives somewhere else) | 18:19 |
*** EmilienM|mtg is now known as EmilienM | 18:21 | |
raildo | lbragstad, the first test, it's like the golden path... we show that we can create a project with a name, and later we cannot create other project with the same name. Are you suggesting another kind of test? | 18:23 |
lbragstad | raildo: ahh, gotcha. no that makes sense | 18:24 |
lbragstad | raildo: thanks for following up! | 18:24 |
raildo | lbragstad, thank you for the reviews :) I'll send a new patch with the other comments. | 18:25 |
lbragstad | raildo: perfect, thanks! | 18:27 |
*** mattfarina has quit IRC | 18:28 | |
*** henrynash has quit IRC | 18:31 | |
*** henrynash_ has joined #openstack-keystone | 18:31 | |
*** ChanServ sets mode: +v henrynash_ | 18:31 | |
*** ankita_wagh has joined #openstack-keystone | 18:35 | |
*** henrynash_ has quit IRC | 18:36 | |
*** samueldmq_ has joined #openstack-keystone | 18:37 | |
*** boris-42 has joined #openstack-keystone | 18:37 | |
dhellmann | bknudson, ayoung : are you ok with your cross-project sessions on roles & policy being merged into 1 session? | 18:37 |
bknudson | dhellmann: I'd rather just drop the roles and we can work on it outside the summit | 18:37 |
*** henrynash has joined #openstack-keystone | 18:38 | |
*** ChanServ sets mode: +v henrynash | 18:38 | |
openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Change project name constraint https://review.openstack.org/158372 | 18:38 |
bknudson | the work is pretty obvious and I don't want to confuse policy discussion | 18:38 |
dhellmann | bknudson: oh? ok, that works, too - ayoung suggested merging them | 18:38 |
dhellmann | ok, that's fair | 18:38 |
*** ankita_w_ has quit IRC | 18:38 | |
bknudson | are all the cross-project sessions in fishbowls? | 18:38 |
dhellmann | bknudson: yes | 18:39 |
bknudson | I don't think the roles work needs a fishbowl. | 18:39 |
dhellmann | bknudson: are you sure you want to withdraw the proposal? there's no reason to discuss roles? | 18:39 |
dhellmann | ok, cool | 18:39 |
bknudson | I think we do need to discuss what's going on with roles, and we also need to discuss policy | 18:40 |
bknudson | but I don't think they're related. | 18:40 |
bknudson | and the policy discussion will require more coordination | 18:41 |
dhellmann | should there be app-specific sessions on roles, or would that be a waste? | 18:41 |
openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Change project name constraint https://review.openstack.org/158372 | 18:41 |
raildo | henrynash, ^ with the code to get a project scoped token with is_domain=False in the token request | 18:41 |
*** rlt has quit IRC | 18:41 | |
ayoung | dhellmann, I think unified policy file will end up in its own repo. That sound right to you? | 18:43 |
*** gokrokve has quit IRC | 18:44 | |
*** gokrokve has joined #openstack-keystone | 18:48 | |
SpamapS | bknudson: if there was a correction, it wasn't to allow nulling out fields. | 18:50 |
SpamapS | bknudson: it's not the worst thing ever, but if you hit the REST API, you can at least get past the API into SQL land to try and null a field. | 18:50 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements https://review.openstack.org/179867 | 18:51 |
*** ankita_w_ has joined #openstack-keystone | 18:53 | |
*** henrynash has quit IRC | 18:56 | |
*** ankita_wagh has quit IRC | 18:57 | |
*** atiwari has joined #openstack-keystone | 19:00 | |
*** Ephur has joined #openstack-keystone | 19:03 | |
*** henrynash has joined #openstack-keystone | 19:03 | |
*** ChanServ sets mode: +v henrynash | 19:03 | |
*** chlong has quit IRC | 19:07 | |
*** annasort has joined #openstack-keystone | 19:08 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone-specs: Dynamic Policy Overview https://review.openstack.org/147651 | 19:10 |
*** samueldmq_ has quit IRC | 19:14 | |
dstanek | given http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/federation/idp.py#n46 how does this http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/test_v3_federation.py#n3162 pass? | 19:20 |
*** emagana has quit IRC | 19:21 | |
*** e0ne has quit IRC | 19:26 | |
*** e0ne has joined #openstack-keystone | 19:30 | |
stevemar | dstanek, line 3170 | 19:31 |
*** e0ne has quit IRC | 19:35 | |
*** e0ne has joined #openstack-keystone | 19:37 | |
*** e0ne has quit IRC | 19:39 | |
*** e0ne has joined #openstack-keystone | 19:39 | |
*** ctina_ has joined #openstack-keystone | 19:40 | |
*** e0ne has quit IRC | 19:41 | |
*** e0ne has joined #openstack-keystone | 19:42 | |
*** e0ne has quit IRC | 19:42 | |
*** e0ne has joined #openstack-keystone | 19:43 | |
*** e0ne has quit IRC | 19:43 | |
*** ctina has quit IRC | 19:44 | |
*** e0ne has joined #openstack-keystone | 19:45 | |
*** ctina_ has quit IRC | 19:45 | |
*** e0ne has quit IRC | 19:45 | |
*** emagana has joined #openstack-keystone | 19:48 | |
*** emagana_ has joined #openstack-keystone | 19:51 | |
*** emagana has quit IRC | 19:52 | |
dstanek | hmmmm....ok. then it really is a bug. it's broken on one of my VMs. pushing a fix momentarily | 19:53 |
dstanek | stevemar: does that mean we don't have that installed on the gate? | 19:53 |
dstanek | seems like we would have to | 19:53 |
stevemar | dstanek, yes, i think that was an issue we were running into when writing the tests | 19:55 |
tristanC | Hi, can someone please approve this stable/icehouse backport: https://review.openstack.org/#/c/175519/ | 19:56 |
openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Restrict inherited role assignments to subdomains https://review.openstack.org/164180 | 19:57 |
*** e0ne has joined #openstack-keystone | 19:57 | |
*** wasmum has joined #openstack-keystone | 19:57 | |
*** ankita_wagh has joined #openstack-keystone | 19:58 | |
wasmum | anyone have time to point me in the right direction with a Juno stack? Controller - MariaDB, KS, Horizon, CentOS7 - max_connections = 100000, nova api-workers = 4 | 19:59 |
wasmum | I keep getting "too many connections" | 19:59 |
*** ankita___ has joined #openstack-keystone | 19:59 | |
*** ankita_w_ has quit IRC | 20:01 | |
openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 20:02 |
*** ankita_wagh has quit IRC | 20:03 | |
openstackgerrit | Merged openstack/python-keystoneclient-saml2: Rename project to keystoneclient-saml2 https://review.openstack.org/173628 | 20:03 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/179904 | 20:03 |
bknudson | dstanek: https://review.openstack.org/#/c/179846/ already has one +2 | 20:05 |
*** josecastroleon has quit IRC | 20:07 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/178426 | 20:09 |
*** josecastroleon has joined #openstack-keystone | 20:09 | |
j_king | is there an API in keystone to extend the expiration time of a token? looking into https://bugs.launchpad.net/cinder/+bug/1298135 for cinder backup where we have a user initiating a long-running process that can potentially outlive the token used to authorize the action | 20:10 |
openstack | Launchpad bug 1298135 in Cinder "Cinder should handle token expiration for long ops" [Medium,Confirmed] - Assigned to j_king (james-agentultra) | 20:10 |
j_king | (been on my backburner for a few weeks) | 20:10 |
ayoung | j_king, not an API. It is a config value | 20:10 |
ayoung | you cannot extend an existing token, but you can set Keystone to issue tokens with a longer life | 20:10 |
j_king | ayoung: okay, that might be problematic for some operators who want a sane expiration value. hm. | 20:12 |
j_king | not really sure it's a huge issue tbh | 20:12 |
ayoung | j_king, a sane expiration vaslue is 5 minutes/ Operators are not sane | 20:12 |
ayoung | the issue is that we perform long running tasks with bearer tokens | 20:12 |
ayoung | its like a cop pulling you over and asking "did you have a valid drivers license last decade?" | 20:13 |
* ayoung steps off soapboxc | 20:14 | |
j_king | ayoung: I'm just wondering if this is an issue or not atm. token expiration values and policies are not my forté ;) | 20:14 |
ayoung | j_king, it comes up from time to time. | 20:14 |
*** cloudnull has quit IRC | 20:15 | |
j_king | i can see it being annoying for a user uploading a large volume to swift via cinder backup and that operation does fail if the token expires before the process is finished. | 20:15 |
j_king | can always do the math I guess and set an upper bound. :) | 20:15 |
j_king | I'll look into the bearer token stuff, thanks. :) | 20:16 |
*** cloudkiller has joined #openstack-keystone | 20:18 | |
ayoung | j_king, the problem is that it checks the token at the end. Solving that, and making it sane is one of the things I want to iron out at this summit. I'm an optimist. | 20:22 |
j_king | ayoung: I see. I'll defer looking into this issue until after the summit then. | 20:23 |
*** cloudkiller has quit IRC | 20:23 | |
*** sigmavirus24 has quit IRC | 20:23 | |
*** d34dh0r53 has quit IRC | 20:23 | |
dstanek | dolphm: lbragstad: i see seg faults in the apache log | 20:24 |
j_king | ayoung: I don't think there's a good, practical way to resolve it given the constraints. | 20:24 |
*** hockeynut has quit IRC | 20:24 | |
*** d34dh0r53 has joined #openstack-keystone | 20:24 | |
*** hockeynut has joined #openstack-keystone | 20:24 | |
*** cloudkiller has joined #openstack-keystone | 20:25 | |
*** sigmavirus24 has joined #openstack-keystone | 20:26 | |
*** htruta has quit IRC | 20:26 | |
*** e0ne has quit IRC | 20:26 | |
ayoung | j_king, nah, it is solvable. The thing is for cinder and swift to not use the same token, but rather get a token when it needs to talk to antother system. IN you r case, what happens first, the user talks to swift, and then swift talks to cinder? | 20:27 |
notmyname | swap those. swift doesn't talk to cinder. cinder talks to swift | 20:28 |
j_king | ayoung: what notmyname said :) | 20:28 |
j_king | ayoung: the cinder backup process splits up the volume into chunks and uploads them to a swift container | 20:29 |
ayoung | j_king, notmyname, ok. so when the user talks to cinder, t hey send a token. At that point, we have no idea how long the operation will last. You say it is 1 hour and 10 ,imnutes, but lets say it could take 2 hours and 10 minutes. We don't want all tokens to be as long as the longest possible operation. RIght? | 20:29 |
ayoung | So, instead, we need to tell Cinder: here is how you get a token when you need it on my behalf | 20:30 |
*** e0ne has joined #openstack-keystone | 20:30 | |
samueldmq | ayoung, I was looking at our overview spec, and I think we should have one more spec in that set : 'Enhance the policy management through Keystone API' | 20:30 |
*** jraim has quit IRC | 20:30 | |
*** boris-42 has quit IRC | 20:30 | |
ayoung | this is what trusts are for...exactly these types of operations. So the question is how can we make the trust creation not a pain in the kiester | 20:30 |
ayoung | samueldmq, write it up, please | 20:30 |
*** cyeoh has quit IRC | 20:31 | |
samueldmq | ayoung, ++ | 20:31 |
j_king | ayoung: right. i looked at the delegation apis | 20:31 |
*** Trozz has quit IRC | 20:31 | |
*** Trozz has joined #openstack-keystone | 20:31 | |
*** Nakato has quit IRC | 20:32 | |
*** sudorandom has quit IRC | 20:32 | |
j_king | ayoung: it wasn't clear how to set that up for the process to use. :) | 20:32 |
*** cloudkiller is now known as cloudnull | 20:32 | |
*** Nakato has joined #openstack-keystone | 20:33 | |
ayoung | j_king, notmyname so if the client starts the operation, it can create the trust, but that requires a significant degree of know-how on the client. Right now, only the user can create the trust. | 20:33 |
ayoung | We want it so the API can create the trust, but we give sane limitations to that creation | 20:33 |
ayoung | and then the workflow needs to carry the trust ID on along, and the swift client needs to be smart enough to get a new token prior to making the call to swift | 20:33 |
ayoung | I could almost see it like a middleware | 20:33 |
*** hockeynut has quit IRC | 20:33 | |
*** jraim has joined #openstack-keystone | 20:33 | |
ayoung | j_king, I know. I am pretty much the only person that thinks this way, except for the Heat team people I have corrupted | 20:33 |
*** hockeynut has joined #openstack-keystone | 20:34 | |
j_king | ayoung: that's about the gist of it iirc | 20:34 |
ayoung | the endpoints don't know to tell the user "hey, you need to create a trust" which would also work | 20:34 |
ayoung | that is how oauth tends to work: | 20:34 |
*** d34dh0r53 has quit IRC | 20:34 | |
ayoung | go to a resource, resources says "I need more auth" | 20:34 |
*** sigmavirus24 has quit IRC | 20:34 | |
*** cyeoh has joined #openstack-keystone | 20:34 | |
*** htruta has joined #openstack-keystone | 20:34 | |
*** d34dh0r53 has joined #openstack-keystone | 20:35 | |
ayoung | or..rather, go to a service , service responds with "I need auth for resources" | 20:35 |
ayoung | and redirec ts you to the oauth server to create that delegation agreement | 20:35 |
*** sigmavirus24 has joined #openstack-keystone | 20:35 | |
*** boris-42 has joined #openstack-keystone | 20:36 | |
*** sudorandom has joined #openstack-keystone | 20:37 | |
ayoung | now...doing this from Horizon might be slightly trickier, but Horizon works on behalf of the user. The services just need to know to say "I am going to need permission to this other resource" | 20:37 |
j_king | right... I assumed it would create a chain of trust to perform some set of actions on behalf of a user, authorized at the time of the request. | 20:37 |
ayoung | but..before any of this makes sense, we need to get endpoint binding of tokens working | 20:37 |
ayoung | cuz until we have that, people are just going to get tokens that are scoepd to the universe | 20:37 |
ayoung | j_king, exactly | 20:37 |
j_king | It'd make this issue I've got easy to do if there was a way for a process to request the trust without the user explicitly creating it but implying it via an auth'd request... or something. if that makes sense. | 20:39 |
j_king | ie: "I'm going to have to talk to X, Y, and Z (n times) in order to do this thing you asked, cool? Yes. Ok." | 20:40 |
ayoung | j_king, we could do that easily. THe tough part is getting the APIs to clarify what additional auth then need | 20:41 |
ayoung | and 401 or 403 would probably be confusing return codes...let me see what oauth specifies | 20:41 |
j_king | coolio | 20:41 |
ayoung | j_king, I'm guessing a redirect would be appropriate | 20:43 |
ayoung | HTTP 302 | 20:44 |
ayoung | 303 | 20:45 |
j_king | HTTP/1.1? | 20:45 |
*** e0ne has quit IRC | 20:45 | |
j_king | would it be changing the request type? | 20:46 |
ayoung | dstanek, what do you think; a user makes a request to something like Cinder that needs to talk to swift, and cinder is smart enough to know it is going to need a trust, so it returns an URL with all of the trust creation values pre-canned | 20:46 |
ayoung | j_king, so the 303 would be a GET, and would contain enought information for the client to create the trust | 20:47 |
j_king | yeah, sounds good | 20:47 |
ayoung | the client would then be smart enough to create the trust. The GET would be for pre-canned trusts on Keystone, and we would tightly control what they looked like | 20:48 |
*** samueldmq_ has joined #openstack-keystone | 20:48 | |
j_king | I think that would also help improve some of our internal tools that face similar scenarios | 20:52 |
*** browne has joined #openstack-keystone | 20:53 | |
david8hu | ayoung, samueldmq, On the dynamic policy topic, in addition to "enhance policy manage through keystone api" Samuel is drafting, we need an additional spec to cover CLI. I can help draft one plus at least one use case. Whatever we can do to make administrator's job easier the better. | 20:54 |
morganfainberg | ayoung: related to trusts... there was an ask in a recent meeting to enhance some of the limited use trust stuff. i'll talk w/ you at the summit | 20:54 |
samueldmq | david8hu, I think we don't support cli anymore in keystone, it's deprecated ... now we just add support in the keystoneclient, ayoung right ? | 20:55 |
david8hu | openstack client | 20:55 |
morganfainberg | samueldmq: openstack client is the CLI we use. keystoneclient cli is deprecated, keystoneclient as a library is all we're focused on there | 20:56 |
samueldmq | david8hu, yeah, not sure we need a spec, but at least a blueprint, check with ayoung | 20:56 |
samueldmq | morganfainberg, ++ | 20:56 |
david8hu | We should not add new CLI feature to keystone client. | 20:56 |
morganfainberg | correct | 20:56 |
morganfainberg | new cli features in keystoneclient will get -2'd | 20:56 |
samueldmq | o/ | 20:57 |
david8hu | a quick way to earn -2 :) | 20:57 |
samueldmq | yeah | 20:57 |
samueldmq | morganfainberg, btw, 'identity v3 only jobs' https://review.openstack.org/#/q/topic:identity-v3-only-jobs,n,z | 20:57 |
morganfainberg | samueldmq: nice | 20:57 |
samueldmq | morganfainberg, just have a review from mordred to apply there | 20:57 |
morganfainberg | cool | 20:57 |
samueldmq | morganfainberg, we don't need to passthrough the env var using d-g | 20:58 |
mordred | I didn't do it | 20:58 |
morganfainberg | mordred: you might have :P | 20:58 |
samueldmq | mordred, hehe | 20:58 |
* mordred hides amidst a field of opium poppies and floating gum drop fairies | 20:58 | |
mordred | hrm. that might have implied something incorrect ... | 20:59 |
morganfainberg | LOL | 20:59 |
morganfainberg | bknudson: http://libertydesignsummit.sched.org/event/2bdea90b411ba50fc62efff044b8e4b8 [the one opposite termie's talk] is a "general" session | 21:02 |
morganfainberg | bknudson: so it's just a go here and talk keystone if you want. no need for everyone to be there | 21:02 |
bknudson | morganfainberg: that might be the most useful session of the summit for us | 21:03 |
morganfainberg | hehe | 21:03 |
*** samleon has joined #openstack-keystone | 21:03 | |
bknudson | or it might just be people showing up and throwing tomatoes | 21:03 |
morganfainberg | bknudson: i also just turned the "deployment" work session into documentation work session | 21:04 |
morganfainberg | bknudson: and added it ot the doc track as well | 21:04 |
*** samleon has quit IRC | 21:04 | |
bknudson | morganfainberg: nice. | 21:04 |
morganfainberg | bknudson: and if you think swapping priority setting and ops feedback fishbowls is a good idea, happy to do that | 21:05 |
*** samleon has joined #openstack-keystone | 21:05 | |
bknudson | http://docs.openstack.org/admin-guide-cloud/content/ch-identity-mgmt-config.html -- not impressive | 21:05 |
*** raildo has quit IRC | 21:05 | |
bknudson | morganfainberg: I'm fine with the order as is. if ops want to help set the priority they can show up. | 21:06 |
morganfainberg | yeah i figure that is the way it goes | 21:06 |
morganfainberg | and ops session could also impact priorities | 21:06 |
morganfainberg | not sure what the last fishbowl should be | 21:06 |
morganfainberg | we could do policy things | 21:06 |
morganfainberg | but that is likely to turn into craziness | 21:06 |
bknudson | there's a cross-project for policy | 21:06 |
morganfainberg | bknudson: no need for us to do that then | 21:06 |
morganfainberg | well... | 21:07 |
bknudson | potentially, I don't know if the x-project have all been selected yet. | 21:07 |
morganfainberg | is that "congress" policy? | 21:07 |
*** ankita_wagh has joined #openstack-keystone | 21:07 | |
morganfainberg | or RBAC policy | 21:07 |
bknudson | no, it's ayoung's | 21:07 |
morganfainberg | or "group based policy" | 21:07 |
morganfainberg | ok | 21:07 |
morganfainberg | cool | 21:07 |
morganfainberg | x-project looks TBD still: http://libertydesignsummit.sched.org/overview/type/design+summit/Cross+Project+workshops | 21:07 |
lifeless | we're finalising it atm | 21:08 |
lifeless | I have an etherpad around here somewhere, we -might- have a slot free | 21:08 |
lifeless | I'm fairly sure one policy one got in - roles for services | 21:08 |
morganfainberg | lifeless: that's ayoung's then | 21:09 |
lifeless | I think we squashed it together with a related policy one about having a single big policy for a whole cloud | 21:09 |
morganfainberg | both are related | 21:09 |
dolphm | dstanek: seg faults regularly? | 21:09 |
* morganfainberg is worried about congress and group based policy bleeding into RBAC in ways that don't make sense. | 21:09 | |
dolphm | i haven't looked at the logs since friday | 21:09 |
morganfainberg | lifeless: but policy $things$ yes. | 21:10 |
dstanek | dolphm: i don't think it's regular | 21:10 |
morganfainberg | lifeless: did the service catalog one get traction? | 21:10 |
*** ankita___ has quit IRC | 21:10 | |
lifeless | https://etherpad.openstack.org/p/liberty-cross-project-session-planning | 21:10 |
* morganfainberg looks | 21:11 | |
dstanek | dolphm: any reason you guys are using mpm_event? this is the first time i've seen that and it's marked as experimental | 21:11 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-saml2: Updated from global requirements https://review.openstack.org/161588 | 21:11 |
morganfainberg | lifeless: yeah ok catalog one looks like it's in there | 21:12 |
ayoung | morganfainberg, what do you think of this: if a user asks nova et alles for a long running opeations, nova returns a 303 with a redirect to a page with enough infomration for how to creat a trust. The client can then submit that back to Keystone, create the trust, and the trust create redirects back to the original request, but with the trust ID in an additional header | 21:14 |
ayoung | or in the body of the request or something | 21:14 |
ayoung | it feels like OAuth | 21:14 |
ayoung | I wonder if we could use the OAuth extension to make something like that happen | 21:14 |
ayoung | unify oauth and trusts behind the scenes | 21:15 |
*** ankita_w_ has joined #openstack-keystone | 21:15 | |
*** ankita___ has joined #openstack-keystone | 21:17 | |
*** ankita_wagh has quit IRC | 21:18 | |
morganfainberg | ayoung: this was actually a request i had from a meeting recently | 21:19 |
ayoung | david8hu, write whatever specs you think are appropriate. I am just kciking off this avalanche and surfing | 21:19 |
morganfainberg | ayoung: make inter-service stuff more oauth-ish. | 21:19 |
ayoung | morganfainberg, what I wrote up? | 21:19 |
ayoung | cool | 21:19 |
morganfainberg | ayoung: yep. | 21:19 |
ayoung | termie will be happy about that | 21:19 |
morganfainberg | ayoung: now... i don't want to store an oauth token for *every* request | 21:19 |
morganfainberg | we're back to unbounded data sets and token tables | 21:19 |
ayoung | morganfainberg, nah, just for the long ones | 21:19 |
ayoung | and they are short lived tokens | 21:19 |
morganfainberg | ayoung: what is a long running task? | 21:19 |
*** ankita_w_ has quit IRC | 21:20 | |
morganfainberg | ayoung: which tasks is that? do we need to special case each one? | 21:20 |
ayoung | morganfainberg, we make the mechanism available, and let the services tell us | 21:20 |
ayoung | Keystone will allow a service to define a precanned trust | 21:20 |
morganfainberg | ayoung: can we instead find a way to bind a token to say.. nova - and issue a token with special powers | 21:20 |
ayoung | we only allow those to be assigned to service users | 21:20 |
morganfainberg | rather than needing to store the data in keystone? | 21:20 |
ayoung | to users with the service role on the service domain | 21:20 |
morganfainberg | again this is going to be an unbounded/db intensive thing | 21:20 |
morganfainberg | if we can err on the side of non-persistence here i'd be happier | 21:21 |
morganfainberg | to be clear: I want to make sure we look at non-persistent options. not saying it must be non-persistent | 21:21 |
ayoung | trh trust should at least be OKed by the user...but..we could make certain trusts implied.... | 21:21 |
morganfainberg | ayoung: that is kindof what i'm looking for. | 21:21 |
ayoung | implied trust would be defined at the Keystone level. What I want is clear transition rules: | 21:22 |
morganfainberg | ayoung: mull over options on limiting what we need to stash in stable storage | 21:22 |
ayoung | If the service user hands in a user token with role R1, then they can get a token for endpoihnt E with role R2 | 21:22 |
mfisch | stevemar: can you convince someone else to +2 https://review.openstack.org/#/c/179846/ so I dont have to hold it? | 21:22 |
morganfainberg | but in short - yes. i'd like to see a way that the user's token isn't passed around. the user's principle token is used just for communucating with the surface API not by proxy | 21:22 |
* mfisch wonders who wants a free beer in vancouver | 21:22 | |
stevemar | ayoung, morganfainberg can you look at ^ from mfisch | 21:22 |
morganfainberg | mfisch: -2! i mean... looking at it | 21:23 |
mfisch | lol | 21:23 |
ayoung | https://etherpad.openstack.org/p/implied-trusts | 21:23 |
ayoung | let me copy in there what we have so far | 21:23 |
* mfisch ships Franzia to morganfainberg | 21:23 | |
mfisch | thanks morganfainberg | 21:23 |
ayoung | morganfainberg, a precanned trust could probably be implemented with Fernet | 21:24 |
morganfainberg | ayoung: that is kind-of my thought | 21:24 |
morganfainberg | ayoung: i am very concerned that we end up removing token persistence for trust explosion ;) | 21:24 |
morganfainberg | ayoung: so i think we might be better off if we can do the pre-canned-trust where appropriate | 21:25 |
ayoung | morganfainberg, hell, we can make Keystone completely stateless | 21:25 |
ayoung | role assignments get checked via fernet? | 21:25 |
morganfainberg | ayoung: I think at some point we need some state | 21:25 |
morganfainberg | but that should be long-running state | 21:25 |
morganfainberg | not token-length | 21:25 |
ayoung | morganfainberg, let me suggest Deleware. It is small | 21:25 |
morganfainberg | single task length | 21:25 |
ayoung | Maybe RHode Island | 21:25 |
morganfainberg | ayoung: haha | 21:25 |
morganfainberg | ayoung: yeah don't go with california. | 21:26 |
ayoung | assignment is long running state | 21:26 |
ayoung | as is delegation | 21:26 |
morganfainberg | correct. but token-TTL length (or similar <86400s operations) should be in the range we don't need to store cruft for if at all possible | 21:26 |
ayoung | the lionger we make them, the more revocations we are going to have to persisit | 21:26 |
morganfainberg | if it's something ephemeral, lets take a stab at non-persist. | 21:27 |
ayoung | persisisisisist | 21:27 |
morganfainberg | ayoung: your precious.............esess..... | 21:27 |
morganfainberg | pockets? | 21:27 |
ayoung | Nasty Baginses | 21:27 |
morganfainberg | re: limited use trusts | 21:27 |
morganfainberg | also had an ask to allow the operator to set a min/max for trust life | 21:27 |
morganfainberg | and max # of consumptions for limited use | 21:28 |
ayoung | max might be a problem | 21:28 |
ayoung | Heat can run for a long while | 21:28 |
morganfainberg | yeah but you might use an unlimited trust for that | 21:28 |
ayoung | I wonder if we need "Class of trusts" | 21:28 |
ayoung | nah | 21:28 |
morganfainberg | anyway | 21:28 |
morganfainberg | it was an ask to make those an option | 21:28 |
* ayoung rapps own knuckles for suggesting | 21:28 | |
ayoung | morganfainberg, I can't help but think that we could make use of henrynash 's split of assignment for this somehow | 21:29 |
ayoung | roles assignments, trusts, and oauth are all delegations | 21:29 |
morganfainberg | things to talk about @ the summit | 21:30 |
morganfainberg | you have ~2wks to mull it over :) | 21:30 |
ayoung | I know we should make the consumer table into a special domain | 21:30 |
*** ankita_wagh has joined #openstack-keystone | 21:30 | |
ayoung | morganfainberg, is there a place to fit "unified delegation" into the keystone discussions? | 21:31 |
morganfainberg | we have an open fishbowl and work session | 21:31 |
morganfainberg | we also have some "general" topic work sessions at the moment | 21:31 |
morganfainberg | that could be co-opted | 21:32 |
ayoung | lets take one and somehow make it offcial. I want to advertise to non Keystone people that we are discussing this | 21:32 |
morganfainberg | so if you want more than keystone developers... fishbowl | 21:33 |
morganfainberg | and expect plenty of people to show up | 21:33 |
morganfainberg | if we want it just keystone devs - work session | 21:33 |
*** ankita___ has quit IRC | 21:33 | |
ayoung | I wonder if we can somehow integrate this with K2K Federation. It should be the same kind of mechanism | 21:34 |
ayoung | With K2K we get a SAML assertion...thanks Obama | 21:34 |
morganfainberg | i mean we can do "AuthN and Delegation" | 21:34 |
stevemar | ayoung, obama says you're welcome :P | 21:36 |
ayoung | morganfainberg, actually...saml and keystone tokens are just different content types. We could distinguish between the types with an accepts header | 21:36 |
*** samueldmq has quit IRC | 21:40 | |
*** samueldmq_ is now known as samueldmq | 21:40 | |
*** aix has joined #openstack-keystone | 21:46 | |
ayoung | stevemar, samueldmq we have an RDO test day tomorrow/wed. Can you guys stand by in #rdo in case I need to field a SAML or HMT question? Just have the room open in chat so you have the context. Anyone else that wants to be avaialble, much appreacited as well | 21:54 |
*** _dguerri has quit IRC | 21:54 | |
ayoung | It should be a good test of Kilo code | 21:54 |
*** lmtaylor1 has left #openstack-keystone | 21:56 | |
*** samueldmq has quit IRC | 21:57 | |
stevemar | ayoung, just give me a reminder tomorrow | 21:58 |
ayoung | stevemar, wilco | 21:59 |
*** dguerri has joined #openstack-keystone | 22:00 | |
*** ankita_wagh has quit IRC | 22:02 | |
morganfainberg | ayoung: we also need to issue Cache-control headers | 22:02 |
morganfainberg | ayoung: if we're talking about adhering to http things | 22:02 |
morganfainberg | ayoung: i'll try and be in #rdo as well fwiw | 22:03 |
ayoung | morganfainberg, I'll post a reminder to the room | 22:03 |
*** ChanServ changes topic to "Liberty Development Open | Review Liberty Specs | Summit in 2 weeks!" | 22:04 | |
ayoung | morganfainberg, for TLS, does it make more sense to forec 5000 and 35357 to do HTTPS, or to convert to using 443 and decomflicting the URLS? I want to push the latter, but ... | 22:05 |
*** ChanServ changes topic to "Liberty Development Open | Review Liberty Specs | See you at the summit!" | 22:05 | |
morganfainberg | i would love to hit 443 instead with deconflicted urls | 22:05 |
morganfainberg | but honestly, i'd worry about that today | 22:05 |
* morganfainberg summons david-lyle re: horizon running on non-root location. | 22:06 | |
david-lyle | you called | 22:06 |
morganfainberg | ayoung: my thought is we need to have a serious talk about deconflicting URLs and making sure everything can run (notably horizon) on shared vhosts | 22:06 |
*** harlowja_ has quit IRC | 22:06 | |
ayoung | morganfainberg, horizon is there | 22:06 |
morganfainberg | david-lyle: can horizon be moved off / yet? or does it need to still own the root? | 22:06 |
ayoung | morganfainberg, he got the last change in | 22:07 |
morganfainberg | i know that was an issue not-too-long ago | 22:07 |
morganfainberg | ah | 22:07 |
morganfainberg | cool | 22:07 |
ayoung | it was a DOA change for WEBROOT | 22:07 |
david-lyle | should work | 22:07 |
*** harlowja has joined #openstack-keystone | 22:07 | |
david-lyle | ah, that just merged, correct? | 22:07 |
ayoung | morganfainberg, so I should push for 443? | 22:07 |
morganfainberg | ayoung: for kilo i'd stick with discreet ports and aim to gate on shared-vhost in liberty | 22:07 |
ayoung | david-lyle, yep, tested it | 22:07 |
morganfainberg | ayoung: so we can be sure we don't regress. | 22:07 |
david-lyle | I can release d-o-a again | 22:07 |
ayoung | morganfainberg, that is going to propogate child abuse | 22:07 |
*** gordc has quit IRC | 22:07 | |
david-lyle | I think it will be 1.3.0 | 22:08 |
david-lyle | for liberty | 22:08 |
ayoung | david-lyle, 1.2.1 I thought | 22:08 |
morganfainberg | ayoung: it is the correct way to ensure we don't fall backwars. | 22:08 |
ayoung | its a bug fix | 22:08 |
ayoung | morganfainberg, I think we will have more errors with http vs https on the same ports | 22:08 |
* morganfainberg assumes liberty vs kilo for things like this | 22:08 | |
morganfainberg | we probably will | 22:08 |
david-lyle | ayoung: I think 1.2.* is left for kilo stable updates | 22:08 |
david-lyle | IIUC | 22:08 |
morganfainberg | use proper SSL termination :P | 22:08 |
david-lyle | I'll ping ttx in the morning to confirm | 22:09 |
ayoung | morganfainberg, this is documentation only at this point | 22:09 |
*** blewis has quit IRC | 22:09 | |
ayoung | I think I would rather tell people "SSL means moving to port 443" and only have to backpeddle if people look at me sternly | 22:09 |
morganfainberg | seriously, i'd worry if we're not gating on it. | 22:09 |
morganfainberg | thats all. | 22:09 |
morganfainberg | so i'd say aim for that to be a confirmed thing in liberty, maybe with documentation of "well it does work like this in kilo, but ... $things" | 22:10 |
ayoung | morganfainberg, so you think https on 35357 is the norm already? | 22:10 |
morganfainberg | yes | 22:10 |
ayoung | ok | 22:10 |
ayoung | that is easier | 22:10 |
morganfainberg | any serious deployments SSL terminate (stunnel, apache, etc) on 35357 and 5000 | 22:10 |
ayoung | the easy way is always harder | 22:10 |
morganfainberg | sometimes they terminate the stunnel and stuff for "public" url endpoint | 22:10 |
morganfainberg | and not for internal | 22:10 |
morganfainberg | and actually use different hosts/urls for those. | 22:11 |
ayoung | morganfainberg, the OAuth thing I just talked about...gonna need to be able to create multiple trusts | 22:16 |
ayoung | one for each remote service you want to talk to | 22:16 |
morganfainberg | ayoung: we will need to map out the way this all works | 22:16 |
ayoung | morganfainberg, I'm just trying to captture the rivulets running off this braindrizzle | 22:17 |
* morganfainberg hands a bucket over | 22:17 | |
morganfainberg | don't let the drizzle escape | 22:17 |
*** ayoung is now known as ayoung-dadmode | 22:17 | |
*** ankita_wagh has joined #openstack-keystone | 22:19 | |
morganfainberg | dstanek: ping | 22:19 |
*** nkinder has quit IRC | 22:35 | |
*** joesavak has quit IRC | 22:36 | |
*** bknudson has quit IRC | 22:44 | |
*** mattfarina has joined #openstack-keystone | 22:51 | |
*** mattfarina has quit IRC | 22:51 | |
*** gsilvis has quit IRC | 22:54 | |
*** gsilvis has joined #openstack-keystone | 23:01 | |
jamielennox | SpamapS: i agree it seems somewhat unrelated - however i don't think that change would have actually changed the behaviour of that field | 23:10 |
jamielennox | SpamapS: in that we go from .update() to _update() - when you submit something to update() it should already remove the None entries and so it should be the same | 23:11 |
SpamapS | jamielennox: I'm wondering why you would want to remove the entries with a value of None though. | 23:11 |
SpamapS | jamielennox: key with a value of None is suggesting that the end result desired is null, but removing it means the end result is "don't change that field" | 23:12 |
SpamapS | jamielennox: so my quibble with the change being unrelated is that the commit message doesn't help me understand the "why do we need this change" of that part. I may be missing where that was already filtered some other way? | 23:13 |
jamielennox | SpamapS: I would tend to agree, the manager code is horrible | 23:13 |
*** Ephur has quit IRC | 23:13 | |
SpamapS | jamielennox: to be clear, I'm working on shade (and perhaps openstacksdk next) and one of the goals there is to have a homogeneous experience between OpenStack API's, and we're leaning toward making keys with a value of None mean "unset that field" | 23:15 |
jamielennox | SpamapS: would love that | 23:16 |
jamielennox | so https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L382 | 23:16 |
SpamapS | jamielennox: of course, we're also planning on factoring out python-keystoneclient .. so this may be moot. ;) | 23:17 |
jamielennox | that filter_kwargs https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L61 | 23:17 |
jamielennox | one of the things it does is drop all None kwargs | 23:17 |
jamielennox | for whatever reason (i can't remember now) i had to go directly to _update and so i would miss that step, so i was not trying to add in something new just maintain what was there | 23:18 |
jamielennox | SpamapS: factoring out ksc? | 23:18 |
SpamapS | jamielennox: yes, we're bending over backward to use the clientlibs. We'd still use keystoneclient for session actually. | 23:18 |
jamielennox | SpamapS: yea, they are terrible | 23:19 |
jamielennox | SpamapS: so have you heard us talk of keystoneauth? | 23:19 |
jamielennox | https://github.com/openstack/keystoneauth | 23:19 |
SpamapS | jamielennox: no, but would that be just the session, w/o the rest of keystoneclient ? | 23:19 |
jamielennox | SpamapS: pretty much | 23:19 |
SpamapS | because that would be interesting to openstacksdk too :) | 23:20 |
jamielennox | all the stuff that is common across clients | 23:20 |
jamielennox | I'm hoping so | 23:20 |
SpamapS | yeah thats basically what openstacksdk's mission is.. make a single client for all the things. | 23:20 |
SpamapS | that works sort of in the same way for everything | 23:20 |
SpamapS | shade is a step even further.. it is a library to encode the most common actions in simple methods. | 23:21 |
SpamapS | jamielennox: thanks for the heads up I will keep an eye on that! | 23:21 |
jamielennox | SpamapS: we haven't had a release yet, it's our chance for breaking changes so we're looking at it, but hopefully around summit time | 23:22 |
SpamapS | summit, the best time to sneak your release into the wild! :) | 23:23 |
SpamapS | jamielennox: ok anyway to the original point, I don't know why we'd want to drop all None args, as it leaves no way to unset a field using keystoneclient. | 23:24 |
SpamapS | jamielennox: I could open a bug on that if you think it would have a chance at making the next breaking-release of keystoneclient. ;) | 23:24 |
SpamapS | since I'd imagine it might break stuff to allow it. | 23:24 |
jamielennox | SpamapS: i don't have an answer, as much as i've become the client guy i'm mainly interested in standardizing all the auth parts | 23:25 |
jamielennox | SpamapS: but yes, a bug report would be good - also ask horizon as they must have done something like this | 23:25 |
jamielennox | maybe they set the empty string? | 23:25 |
*** samueldmq has joined #openstack-keystone | 23:27 | |
*** chlong has joined #openstack-keystone | 23:30 | |
*** stevemar has quit IRC | 23:37 | |
*** gokrokve has quit IRC | 23:39 | |
*** _cjones_ has quit IRC | 23:42 | |
*** dims_ has joined #openstack-keystone | 23:42 | |
*** dims has quit IRC | 23:44 | |
*** Raildo has joined #openstack-keystone | 23:54 | |
*** lhcheng has quit IRC | 23:56 | |
*** nkinder has joined #openstack-keystone | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!