Monday, 2015-05-04

*** wwwjfy has joined #openstack-keystone00:18
*** markvoelker has joined #openstack-keystone00:21
*** lhcheng has joined #openstack-keystone00:24
*** ChanServ sets mode: +v lhcheng00:24
*** markvoelker has quit IRC00:25
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: validate_token returns AccessInfo  https://review.openstack.org/17948600:27
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Futher refactoring to use AccessInfo  https://review.openstack.org/17967500:27
*** lhcheng has quit IRC00:29
*** henrynash has quit IRC00:37
*** henrynash has joined #openstack-keystone00:38
*** ChanServ sets mode: +v henrynash00:38
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Futher refactoring to use AccessInfo  https://review.openstack.org/17967500:44
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo  https://review.openstack.org/17967600:44
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo  https://review.openstack.org/17967600:46
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Futher refactoring to use AccessInfo  https://review.openstack.org/17967500:46
jamielennoxbknudson: have you had a look at my refactorings on auth_token?00:47
jamielennoxwe seem to have a similar agenda00:48
bknudsonjamielennox: do you have a link?00:48
jamielennoxbknudson: starts https://review.openstack.org/#/c/174194/200:49
bknudsonhttps://review.openstack.org/#/c/174197/ is looking similar!00:49
jamielennoxbknudson: i was trying to move things around so that auth checking all existed in the validate function00:50
jamielennoxthe 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 there00:51
bknudsonjamielennox: with https://review.openstack.org/179486 and https://review.openstack.org/179676 we've got AccessInfo in validate.00:53
bknudsonit's not difficult to get an AccessInfo, just use the factory00:53
bknudsonor, keystoneclient validate_token returns an AccessInfo now.00:53
jamielennoxthe factory is one of the first things i fixed with ksa00:53
jamielennoxyep, so in my refactors i made it so validate returns the accessinfo00:54
jamielennoxi haven't seen yours yet, i was just letting you know others are out there00:54
jamielennoxbknudson: ah, cool we get the AccessInfo back directly from the client call00:54
bknudsonthat was one of the things I implemented in the v2 validate_token method to make it easier00:55
jamielennoxyuk 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 easier00:56
bknudsonI'm expecting that to go away00:56
*** henrynash has quit IRC00:57
bknudsonalthough we'll always need to serialize the AccessInfo to the cache00:57
bknudsonand deserialize00:57
*** henrynash has joined #openstack-keystone00:57
*** ChanServ sets mode: +v henrynash00:57
jamielennoxhmm, we're going to have issues with serialization of the ksa AccessInfo - just how to make it interoperate with the old methd00:58
jamielennoxif we have ksc.AccessInfo subclass ksa.AccessInfo maybe we can put a get_data() or something on the base class that returns the full token00:59
bknudsonjamielennox: 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
bknudsonit makes more sense to me to start from the source01:00
bknudsonI don't really care about https://review.openstack.org/#/c/179675/ so am not worried about that one.01:01
jamielennoxit should be easy to do 17948601:01
bknudsongreat01:02
jamielennoxprobably the other is easy enough too01:02
bknudsonI can just abandon mine since looks like you were in the midst of it already01:02
jamielennoxbknudson: no worries, just when i saw you doing refactorings i wanted to make sure you were aware of the current ones01:03
bknudsonI 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 IRC01:04
jamielennoxright - 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 thinj01:04
bknudsonone thing that seems to be missing in AccessInfo is making getting token binding consistent01:04
jamielennox:)01:04
bknudsonhe he01:04
jamielennoxi wasn't sure if it made sense to return a dictionary with all bind stuff, or do like a kerberos_bind property01:05
jamielennoxi try to keep the AccessInfo flat where possible01:05
jamielennoxi think it will make it easier to reimplement if we get a new token format again01:06
bknudsonit's a class and we can push all the auth_token logic into it if we want.01:06
*** bjornar has joined #openstack-keystone01:06
jamielennoxlike move the verification function to accessinfo?01:07
bknudsone.g., access_info.confirm_token_bind(mode, env)01:07
bknudsonunless auth_token should really care about all this.01:08
jamielennoxbknudson: what's mode?01:08
bknudson_BIND_MODE.DISABLED , etc.01:08
jamielennoxoh - yep01:09
bknudsonAccessInfo doesn't care about disabled, though.01:09
jamielennoxbknudson: does that mean we could essentially create a validate() on AccessInfo?01:10
bknudsonor it can be a name.01:10
jamielennoxmove all of validate_token01:10
bknudsonsure01:10
jamielennoxyou'd have to pass a fair bit of stuff01:10
bknudsonauth_token will still have work to do to get the accessinfo from cache or from pki token01:11
jamielennoxat the moment it looks like just expiry and bind, but endpoint filtering would be there as ewell01:11
jamielennoxwhich is probably not a problem01:11
bknudsonI don't think we'll want accessinfo to talk to the server?01:12
bknudsonthat would be confusing01:12
jamielennoxno it wouldn't talk to the server, endpoint enforce just checks that either a service_id and/or an endpoint_id exists in the catalog01:12
bknudsonright, but sometimes you don't have a catalog01:12
bknudsone.g., if the token was originally requested with ?nocatalog01:13
jamielennoxthat's a failure for the endpoint_id check01:13
bknudsonjust fetch the catalog from the server if it didn't have one01:13
jamielennoxbut you would have to pass this in anyway as we don't want AccessInfo reading the CONF01:13
jamielennoxso validate(enforce_service_id='XXX', enforce_endpoint_id='XXX', bind_mode='XXX')01:14
bknudsonit also needs the env01:14
jamielennoxhttps://review.openstack.org/#/c/153296/01:14
jamielennoxthough gyee is now messing with it again saying he wants to do it from policy rather than in auth_token01:15
jamielennoxhttps://review.openstack.org/#/c/177661 is wiht policy - and that's not what i thought he meant01:16
bknudsongyee needs to make up his mind.01:17
bknudsonpolicy in keystonemiddleware... nasty01:17
jamielennoxyea, that doesn't sit right with me01:17
jamielennoxwriting policy lines into CONF.keystone_authtoken seems wrong01:18
bknudsonwe'll never be able to get that right01:18
*** wwwjfy has quit IRC01:18
jamielennoxthe example: "region_id:12345 or endpoint_id:23456"01:19
bknudsonif self._enforce_endpoint_constraint: # enforce endpoint constraint01:19
jamielennoxwhere is region_id coming from?01:19
bknudsonthat's a really useful comment01:19
bknudsonauth_ref = access.AccessInfo.factory(body=data, !!01:19
bknudsoneverybody wants AccessInfo01:20
jamielennoxyea, i did the refactor after i saw that first endpoint enforce not fitting right01:20
jamielennoxI 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 there01:21
bknudson lets get this work done on AccessInfo and then it'll be easier to add these new functions.01:21
jamielennoxand if we were going to do that why wouldn't we just do a global policy rule01:21
*** markvoelker has joined #openstack-keystone01:21
bknudsonI thought every service would have their own policy.01:22
jamielennoxas far as endpoint enforcement goes i think so to01:22
bknudsonit uses global CONF... somebody's not going to be happy01:22
jamielennoxthe service is supposed to know in advance what its endpoint_id is01:22
jamielennoxwhy do we pass CONF to enforcer?01:23
jamielennoxit also has use_conf=False01:23
jamielennoxthat may be a summit discussion i think01:23
bknudsonsounds like the perfect place to discuss this. maybe during the meetup01:24
bknudsonthat'll give us time to get all this AccessInfo refactoring in.01:24
jamielennoxok, so rebase on top of https://review.openstack.org/#/c/179676/ ?01:25
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin  https://review.openstack.org/17355801:25
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-kerberos: Update keystoneclient to 1.3  https://review.openstack.org/17967701:25
bknudsonjamielennox: yes, if you think "Refactor _confirm_token_bind takes AccessInfo" makes sense.01:26
*** markvoelker has quit IRC01:26
bknudsonIt looked like that one was doing some of the same as some of your changes01:26
bknudson(it's always making AccessInfo)01:26
bknudsonotherwise rebase on the parent and I can work on Refactor _confirm_token_bind takes AccessInfo later.01:27
jamielennoxthe v2/v3 check isn't really better or worse - though i don't like using the dict part of AccessInfo01:27
bknudsonI still think it's better to stop using "data" (the token dict)01:28
*** henrynash_ has joined #openstack-keystone01:28
*** ChanServ sets mode: +v henrynash_01:28
bknudsonthat was my goal is to stop using data throughout here and just have accessinfo01:29
bknudsonso eventually I was going to have the token cache dealing with accessinfo, too.01:29
bknudsonand of course rather than getting X_USER_ID, etc, from token dict should be getting it all from access_info01:30
jamielennoxin 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 object01:31
*** henrynash has quit IRC01:31
*** henrynash_ is now known as henrynash01:31
jamielennoxi'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 in01:32
bknudsonso we don't have the bind data?01:33
jamielennoxwe wouldn't have access to it as is, no01:34
bknudsonso we're eventually going to change keystoneclient validate_token to return this new keystoneauth.access.AccessInfo?01:34
bknudsonthis is going to be a lot of work.01:34
jamielennoxcompatibility is going to be the issue,01:34
jamielennoxeverything in ksa will work with just the ksa AccessInfo01:35
jamielennoxwe'll subclass the old AccessInfo from the appropriate ksa one to give all that additional backwards compat stuff01:35
jamielennoxs/give/add01:35
bknudsonnice01:36
jamielennoxand then most likely ksc.token.validate will always return a ksc.AccessInfo for compat01:36
bknudsonI didn't notice this: http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n58801:37
bknudsonshould be easy to change self._validate_token to return the AccessInfo and then don't recreate01:37
jamielennoxbknudson: yep, i do that in one of my patches01:37
bknudsonand _build_user_headers already uses AccessInfo01:37
bknudsonso we're mostly there already01:38
bknudsongreat!01:38
bknudsonjamielennox: you didn't do anything with the cache?01:38
jamielennoxbknudson: i didn't change the token data going into the cache but i changed some of how the cache was used01:39
jamielennoxhttps://review.openstack.org/#/c/174194/ and https://review.openstack.org/#/c/174196/01:39
bknudsonhttps://review.openstack.org/#/c/179675/2/keystonemiddleware/auth_token/_cache.py -- changed to have cache.store take access_info01:40
jamielennoxbknudson: probably won't clash - but i'd check that https://review.openstack.org/#/c/174196/4/keystonemiddleware/auth_token/_cache.py is ok with it01:41
jamielennoxactually - it will clash01:42
bknudsonI'll just abandon https://review.openstack.org/#/c/179675/ anyways since most of that is done differently01:42
bknudsoncan always just do the cache stuff after the rest of this is done.01:42
jamielennoxbknudson: what if we rebase your one onto https://review.openstack.org/#/c/174197/4/keystonemiddleware/auth_token/__init__.py01:43
jamielennoxthat's where i return auth_ref from validate01:44
jamielennoxso 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 validation01:44
bknudsonjamielennox: y, it doesn't matter to me with  https://review.openstack.org/#/c/179675 , it's a work in progress anyways01:45
bknudsonjamielennox: 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.py01:46
bknudsonand the other backwards-compat tests01:46
jamielennoxbknudson: they are testing the cache interface itself - not the validate_token interface coming from cache01:50
jamielennoxthey test that _cache_get raises Invalid if the token is expired, which is what i was moving back into validate01:51
jamielennoxbknudson: 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 information01:52
*** ncoghlan has joined #openstack-keystone01:53
bknudsonjamielennox: we can't get rid of the data variable if checking bind requires it.01:53
jamielennoxwe could rebase the confirm bind on top of https://review.openstack.org/#/c/174197/4/keystonemiddleware/auth_token/__init__.py for the same effect01:53
jamielennoxbknudson: 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 back01:54
*** gokrokve has joined #openstack-keystone01:57
bknudsonjamielennox: 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 AccessInfoV302:02
bknudsonso you always know the type of what's returned02:02
bknudsonyou don't need to check the type02:02
*** dimsum__ has quit IRC02:04
jamielennoxit was just that you need to convert them back to create the data you ned02:05
jamielennoxand then in https://review.openstack.org/#/c/179676/2/keystonemiddleware/auth_token/__init__.py you have to check version yet again02:07
jamielennoxi don't know if it cleans it up any until we have something on the accessinfo to extract the bind info02:08
*** davechen has joined #openstack-keystone02:10
*** emagana has joined #openstack-keystone02:11
*** davechen1 has joined #openstack-keystone02:15
*** davechen has quit IRC02:17
*** richm has quit IRC02:20
*** markvoelker has joined #openstack-keystone02:22
*** markvoelker has quit IRC02:27
*** wwwjfy has joined #openstack-keystone02:27
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin  https://review.openstack.org/17355802:32
*** wwwjfy has quit IRC02:32
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core  https://review.openstack.org/17191602:34
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint policy into keystone core  https://review.openstack.org/17144802:34
*** wwwjfy has joined #openstack-keystone02:34
jamielennoxbknudson: do you have anything proposed for debtcollector in keystoneclient?02:36
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-saml2: Rename project to keystoneclient-saml2  https://review.openstack.org/17362802:39
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Allow registering additional plugins  https://review.openstack.org/11256402:47
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Simplify request making in auth_token tests  https://review.openstack.org/16717902:50
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Create new user plugin tests  https://review.openstack.org/16718002:50
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Serialize user auth plugin  https://review.openstack.org/16718102:50
*** dimsum__ has joined #openstack-keystone03:05
*** dimsum__ has quit IRC03:10
*** markvoelker has joined #openstack-keystone03:23
*** markvoelker has quit IRC03:27
*** wwwjfy has quit IRC03:27
*** henrynash has quit IRC03:34
*** henrynash has joined #openstack-keystone03:34
*** ChanServ sets mode: +v henrynash03:34
*** lhcheng has joined #openstack-keystone04:02
*** ChanServ sets mode: +v lhcheng04:02
*** josecastroleon has joined #openstack-keystone04:03
*** josecastroleon has quit IRC04:05
*** lhcheng has quit IRC04:07
*** henrynash has quit IRC04:17
*** henrynash has joined #openstack-keystone04:17
*** ChanServ sets mode: +v henrynash04:17
*** markvoelker has joined #openstack-keystone04:24
*** markvoelker has quit IRC04:28
*** spandhe has joined #openstack-keystone05:21
*** markvoelker has joined #openstack-keystone05:24
*** markvoelker has quit IRC05:29
*** gokrokve has quit IRC05:37
*** gokrokve has joined #openstack-keystone05:37
*** lhcheng has joined #openstack-keystone05:38
*** ChanServ sets mode: +v lhcheng05:38
*** gokrokve has quit IRC05:42
*** josecastroleon has joined #openstack-keystone06:02
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/17933106:06
*** gokrokve has joined #openstack-keystone06:08
*** gokrokve has quit IRC06:09
marekdjamielennox: 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-keystone06:09
jamielennoxmarekd: that was my thought06:10
marekdjamielennox: 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
jamielennoxauth plugins will be in ksc for a while06:10
jamielennoxyep06:10
marekdjamielennox: ok, i will abandon then this patch and propose new in ksa.06:10
marekdjamielennox: bp isn't required, is it?06:11
jamielennoxmarekd: no - though we haven't been adding anything new to ksa yet06:12
jamielennoxbut for a rename feel free06:12
marekd...to add a bp or *not* add a bp ?06:12
marekdjamielennox: 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
jamielennoxmarekd: it lets you set up mod_auth_kerb in front of federation just like any other federation method06:15
jamielennoxyou can provide a mapping from the information that comes through env params06:16
jamielennoxno more kerberos being special06:16
marekdjamielennox: so ephemeral users allowed?06:16
jamielennoxmarekd: sure i guess - the same as any other federation thing06:16
marekdisn't kerberos authN only, something rather like authenticated/not authenticated ?06:17
jamielennoxmarekd: you can use it with sssd/mod_identity_lookup and it will all tie together06:18
jamielennoxor you could just match on name06:18
marekdjamielennox: if you match on name then you'd rather want to authenticate your local user.06:18
marekdREMOTE_USER on steroids06:19
jamielennoxmarekd: more or less06:20
jamielennoxbut 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 now06:20
jamielennoxor set groups via kerb realm06:21
jamielennoxas i said, i know adam wants it for mod_identity_lookup and sssd06:21
*** ajayaa has joined #openstack-keystone06:21
jamielennoxso it will fetch additional roles/groups from there06:21
marekdjamielennox: btw, it's ksc that will depend on ksa now, once it's released, right?06:25
jamielennoxyea06:25
jamielennoxhey marekd, is the first federation call always a GET or should it be a POST?06:34
marekdGET06:34
jamielennoxok, that's what i had in https://review.openstack.org/#/c/173558/4/keystoneclient_kerberos/v3.py i just wasn't completely sure06:35
marekdgood :-)06:36
marekdbtw i commented on this patch06:36
jamielennoxyep, i saw it06:37
jamielennoxi don't know about prefixing everything with Federated06:38
jamielennoxi was just looking for some way to distinguish it from the other one06:38
jamielennoxi guess i could put it in a different file and still just call it kerberos06:38
marekdjamielennox: maybe a docstring will be helpful06:38
jamielennoxi'd like a name other than 'federation' for all this as well - but i don't konw what to use06:39
marekdMappedKerberos ?06:40
marekdor you could indeed move it to another file, mapped.py ?06:40
marekdbut then we should probably make top level classes MappedBaseAuth etc.06:40
*** dimsum__ has joined #openstack-keystone06:42
*** dimsum__ has quit IRC06:47
jamielennoxdidn't we do that already?06:54
jamielennoxoh- not it's called FederatedBaseAuth06:54
marekdyes, which makes sense in case of protcols like saml, oidc, but...kerberos and similar aren't truly federation protocols.06:55
marekdanyway, i am maybe wasting too much time on naming.06:55
jamielennoxif there was a time to get it straightened out it would be now while KSA is available06:56
jamielennoxbut yea, i haven't been too caught up in that06:57
marekdjamielennox: MappedBaseAuth and inheritants make more sense for you than FederatedBaseauth ?06:57
marekdbetter to rename it now, so we can skip deprecations06:58
jamielennoxi don't know, i use the term federation/federated here because of the module on the server06:58
jamielennoxall mapped auth is going through /OS-FEDERATION/ so i've stuk with the federation name06:58
marekdheh :-)06:58
marekdi think this is why i proposed FederatedBaseAuth some time ago...06:58
jamielennoxmaybe during summit we should try and rename it on the server side06:59
jamielennoxor just map it all to /auth06:59
marekdwe need distincs URLs06:59
marekddistinct06:59
marekdso we cannot simply remap to /auth06:59
jamielennoxright - but you can do /auth/identity_providers/XXX/protocols/XXX/auth is what i meant06:59
marekdah, oh, worth discussing, esp since os-federation is not an extension anymore07:00
jamielennoxtwo /auths seems weird, maybe we do it directly to /v3/identity_providers/....07:00
jamielennoxmarekd: i think that's a good idea given that we want to make mapped authentication the future of auth07:03
jamielennoxwant to blueprint?07:03
marekdjamielennox: yeah, worth discussing @ the summit.07:04
jamielennoxright07:04
marekdjamielennox: you are asking if i want to create a bp ?07:04
marekd(didn't get it)07:04
jamielennoxmarekd: i can propose it07:05
marekdjamielennox: btw, pecan and falcon are roughly replaceable frameworks or they have different purposes?07:05
jamielennoxmarekd: roughly replacable, as with all these things they do some things slightly differently07:06
jamielennoxbe that better or worse for us07:06
marekdjamielennox: cause i think falcon was considered recently, whereas ppl are talking about pecan only now.07:06
marekdjamielennox: why?07:06
jamielennoxpecan is on stackforge, the main guy works on opentsack07:07
marekdfalcon isn't mature enough?07:07
marekdaha07:07
jamielennoxthe idea is that we can have more customization to our needs of pecan07:07
jamielennoxfalcon is built by rax so they are involved as well07:07
jamielennoxbut for whatever reason pecan was around first07:08
jamielennoxi 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 idea07:08
marekdaha, i thought falcon would be better because they claim it's much faster07:09
marekdi didn't even know it's more mainstream than pecan.07:09
jamielennoxneither are mainstream07:13
marekdjamielennox: what is mainstream then? (i don't know much about wsgi frameworks). django customized for rest?07:15
jamielennoxi think there is something like that, but flask i gues07:15
*** lhcheng has quit IRC07:19
*** lhcheng has joined #openstack-keystone07:22
*** ChanServ sets mode: +v lhcheng07:22
*** lhcheng has quit IRC07:25
*** lhcheng has joined #openstack-keystone07:26
*** ChanServ sets mode: +v lhcheng07:26
*** markvoelker has joined #openstack-keystone07:26
*** markvoelker has quit IRC07:30
*** spandhe has quit IRC07:30
*** chlong has quit IRC07:37
*** csd has quit IRC07:49
*** csd has joined #openstack-keystone07:51
*** krykowski has joined #openstack-keystone07:52
*** jistr has joined #openstack-keystone07:59
openstackgerritZhiQiang Fan proposed openstack/python-keystoneclient: return all endpoints if service type is empty  https://review.openstack.org/17972208:03
*** lhcheng has quit IRC08:04
*** bdossant has joined #openstack-keystone08:08
*** fhubik has joined #openstack-keystone08:13
openstackgerritZhiQiang Fan proposed openstack/python-keystoneclient: add --slowest flag to testr  https://review.openstack.org/17972508:14
*** ncoghlan has quit IRC08:24
*** markvoelker has joined #openstack-keystone08:27
*** markvoelker has quit IRC08:31
*** fhubik is now known as fhubik_afk08:31
*** rlt has joined #openstack-keystone08:37
*** pnavarro has joined #openstack-keystone08:42
*** krykowski has quit IRC08:57
*** krykowski_ has joined #openstack-keystone08:57
*** krykowski_ has quit IRC09:03
*** krykowski has joined #openstack-keystone09:03
*** e0ne has joined #openstack-keystone09:04
*** lhcheng has joined #openstack-keystone09:04
*** ChanServ sets mode: +v lhcheng09:04
*** lhcheng has quit IRC09:08
*** e0ne has quit IRC09:10
*** _dguerri is now known as dguerri09:17
*** fhubik_afk is now known as fhubik09:23
*** henrynash has quit IRC09:26
*** markvoelker has joined #openstack-keystone09:27
*** dguerri is now known as _dguerri09:28
*** markvoelker has quit IRC09:32
*** _dguerri is now known as dguerri09:42
*** fhubik is now known as fhubik_afk09:47
*** krykowski has quit IRC09:49
*** dguerri is now known as _dguerri09:50
*** fhubik_afk is now known as fhubik09:50
*** dimsum__ has joined #openstack-keystone09:53
*** davechen1 has quit IRC10:00
*** krykowski has joined #openstack-keystone10:22
*** fhubik is now known as fhubik_afk10:26
*** _dguerri is now known as dguerri10:27
*** kiran-r has joined #openstack-keystone10:28
*** fhubik_afk is now known as fhubik10:28
*** e0ne has joined #openstack-keystone10:31
*** lhcheng has joined #openstack-keystone10:34
*** ChanServ sets mode: +v lhcheng10:34
*** kiran-r is now known as _kiran_10:35
openstackgerritKamil Rykowski proposed openstack/keystone-specs: Use oslo-versioned-objects to deal with upgrades  https://review.openstack.org/16719510:38
*** lhcheng has quit IRC10:39
*** samueldmq has joined #openstack-keystone10:40
samueldmqmorning10:40
*** dguerri is now known as _dguerri10:43
*** fhubik is now known as fhubik_afk10:50
*** fhubik_afk is now known as fhubik10:52
dstanekgood morning samueldmq11:26
samueldmqdstanek, hey : ) you always up early in the morning11:28
samueldmqjamielennox, you around ? see https://review.openstack.org/#/q/branch:master+topic:identity-v3-only-jobs,n,z11:28
*** ctina_ has joined #openstack-keystone11:33
marekdsamueldmq: he's rather asleep11:35
samueldmqmarekd, yep I think so, but I preferred to ping since his nickname is not 'jamielennox-afk', as it uses to be11:37
openstackgerritAlexey Miroshkin proposed openstack/keystone: Implement backend filtering on membership queries  https://review.openstack.org/17975811:38
*** dimsum__ is now known as dims11:41
*** markvoelker has joined #openstack-keystone11:50
*** raildo has joined #openstack-keystone11:58
marekdsamueldmq: i have a question actually12:01
marekdsamueldmq: Dynamic Policy spec12:01
marekdso basically you want to configue/keep the policies not in the file but in the DB and make it accessible via API?12:01
marekdsamueldmq: so other services (nova, glance, ...) will query Keystone as a reference policy store instead of keeping local policy configs in the files?12:02
marekdis it the main aim of the spec?12:02
samueldmqmarekd, yeah12:04
samueldmqmarekd, policy will be enforce by ksmiddleware, which will fetch the policy (using ksclient) and cache it12:04
*** aix has joined #openstack-keystone12:05
samueldmqmarekd, ksmiddleware will use the engine in oslo.policy to enforce it12:05
samueldmqmarekd, but yes, the main aim is as you described12:05
marekdsamueldmq: the policies would be global or could be personalized per project?12:06
marekdnova policies, glance policies12:06
samueldmqmarekd, they can be retrieved per project, as we have today12:11
marekdsamueldmq: ok12:11
marekdjust wanted to clarify12:11
marekdhopefully i will re-read it today carefully12:11
samueldmqmarekd, each policy api entry will be prefixed by compute, or identity, and so on12:11
samueldmqmarekd, to identify where they belong to12:12
marekdok12:12
marekdunderstand12:12
samueldmqmarekd, nice, I am aplying the feedbacks already there12:12
samueldmqmarekd, thanks, appreciate your review12:12
*** shakamunyi has quit IRC12:18
samueldmqdavid8hu, hi, is this your lp profile https://launchpad.net/~david-j-hu ?12:18
*** htruta has joined #openstack-keystone12:21
*** gordc has joined #openstack-keystone12:22
*** fhubik has quit IRC12:28
*** fhubik has joined #openstack-keystone12:29
*** afaranha has joined #openstack-keystone12:30
*** _dguerri is now known as dguerri12:38
openstackgerritDave Chen proposed openstack/keystone: Upgrade Foreign key in Endpoint with ondelete='CASCADE'  https://review.openstack.org/17976712:42
*** iurygregory has joined #openstack-keystone12:42
*** dguerri is now known as _dguerri12:45
openstackgerritDave Chen proposed openstack/keystone: Upgrade Foreign key in Endpoint with ondelete='CASCADE'  https://review.openstack.org/17976712:45
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: validate_token returns AccessInfo  https://review.openstack.org/17948612:49
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo  https://review.openstack.org/17967612:52
*** links has joined #openstack-keystone12:56
*** fhubik has quit IRC12:56
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Refactor _build_user_headers doesn't need token_info  https://review.openstack.org/17976812:56
*** fhubik has joined #openstack-keystone12:57
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Refactor _build_service_headers takes AccessInfo  https://review.openstack.org/17977013:00
*** bknudson has quit IRC13:01
*** ajayaa has quit IRC13:10
*** richm1 has joined #openstack-keystone13:11
*** dims has quit IRC13:14
*** dims has joined #openstack-keystone13:15
*** nkinder has quit IRC13:15
*** _kiran_ is now known as kiran-r13:18
*** mestery_ is now known as mestery13:25
*** joesavak has joined #openstack-keystone13:29
openstackgerritCyril Roelandt proposed openstack/keystonemiddleware: Prevent a UnicodeDecodeError in the s3token middleware  https://review.openstack.org/17977713:30
*** bknudson has joined #openstack-keystone13:33
*** ChanServ sets mode: +v bknudson13:33
*** kiran-r has quit IRC13:37
marekdmorganfainberg: 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-keystone13:38
*** raildo has joined #openstack-keystone13:38
*** ctina_ is now known as ctina13:45
*** ajayaa has joined #openstack-keystone13:46
ajayaadolphm, 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-keystone13:49
ajayaaThe 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
ajayaajamielennox, marekd, bknudson ^^13:53
*** emagana has quit IRC13:53
*** chlong has joined #openstack-keystone13:58
*** fhubik has quit IRC14:03
*** nkinder has joined #openstack-keystone14:07
*** richm1 is now known as richm14:08
*** chlong has quit IRC14:08
*** ayoung has joined #openstack-keystone14:09
*** ChanServ sets mode: +v ayoung14:09
*** lhcheng has joined #openstack-keystone14:11
*** ChanServ sets mode: +v lhcheng14:11
*** _dguerri is now known as dguerri14:12
*** dguerri is now known as _dguerri14:13
*** _dguerri is now known as dguerri14:13
*** e0ne has quit IRC14:14
*** sigmavirus24_awa is now known as sigmavirus2414:14
marekdsamueldmq: 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
marekdi think this is something henry was reffering to saying it's other services who need work, not keystone.14:16
*** lhcheng has quit IRC14:16
*** pnavarro has quit IRC14:18
openstackgerritRodrigo Duarte proposed openstack/keystone: Refactor _create_attribute_statement IdP method  https://review.openstack.org/17264714:19
openstackgerritRodrigo Duarte proposed openstack/keystone: Add openstack_user_domain to assertion  https://review.openstack.org/17256214:19
*** stevemar has joined #openstack-keystone14:23
*** ChanServ sets mode: +v stevemar14:23
*** rlt has quit IRC14:24
*** rlt has joined #openstack-keystone14:25
*** chlong has joined #openstack-keystone14:26
*** gokrokve_ has joined #openstack-keystone14:34
morganfainbergmarekd: yes. Can be abandoned.14:36
*** gokrokve has quit IRC14:37
openstackgerritDavid Stanek proposed openstack/keystone: Fixes test nits from a previous review  https://review.openstack.org/17979614:38
edmondswajayaa, added a few comments on your nosql proposal14:40
*** packet has joined #openstack-keystone14:41
*** emagana has joined #openstack-keystone14:42
morganfainbergEveryone: please look at https://libertydesignsummit.sched.org/type/design+summit/Keystone as a first pass - I will want to finalize this tomorrow.14:43
stevemarmorganfainberg, no dice14:44
morganfainbergstevemar: ?14:44
stevemarmorganfainberg, joke gone wrong, i will review now14:44
morganfainbergHehe14:44
morganfainbergI purposefully left one fishbowl tbd and one work session (following that fishbowl) as tbd14:45
morganfainbergUntil tomorrow.14:45
bknudsonmorganfainberg: shouldn't we get the operator feedback before we discuss priorities?14:45
morganfainbergWe can swap those. Or we can adjust priorities after operator as well.14:46
morganfainbergbknudson: it's really easy to swap these around.14:46
marekdmorganfainberg: "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
morganfainbergWork sessions all have the same boring titles14:46
morganfainbergThey are small rooms. I've added ether pads and general descriptions to them.14:47
bknudsonI'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
morganfainbergbknudson: I purposefully asked for fewer sessions this time14:47
dstanekstevemar: don't quit your day job14:48
bknudsonwhat's the deal with PKI tokens?14:48
morganfainbergbknudson: a number of the keystone work sessions are "general" meaning kind of like what we did at the table in ATL14:48
bknudsonseinfeld joke14:48
morganfainbergbknudson: I marked those as "office hours"14:48
stevemardstanek, so bknudson and i shouldn't quit our day jobs?14:49
dstanekstevemar: nope. but i did laugh once  figured out that you were trying to joke :-P14:49
bknudsonI might have to decide whether to attend one of the work sessions, a security session, etc.14:50
dstanekmorganfainberg: i don't have any reason to complain about the schedule.14:51
* dstanek high fives morganfainberg 14:51
morganfainbergbknudson: if the work session isn't a general one we can swap it for one of the general ones.14:51
morganfainbergbknudson: I figure the keystone group will be mostly in other project sessions this cycle.14:52
morganfainbergErr. Summit14:52
bknudsonthat seems to be where we're most needed14:52
morganfainbergYep.14:52
marekdmorganfainberg: because keystone is finished, now others need to catch up  :P14:53
bknudsonmaybe we can have a session where we work on the docs14:53
*** vhoward has quit IRC14:54
morganfainbergbknudson: I also am considering making he deployment story work session ops track as well14:54
*** vhoward has joined #openstack-keystone14:55
morganfainbergOr we can swap that one for docs.14:55
*** gokrokve_ has quit IRC14:55
*** gokrokve has joined #openstack-keystone14:55
*** links has quit IRC14:56
bknudsonhaving no documentation is going to make it difficult for ops.14:56
*** henrynash has joined #openstack-keystone14:57
*** ChanServ sets mode: +v henrynash14:57
*** gokrokve has quit IRC14:57
bknudsonI'm not familiar at all with deployment issues. Devstack works fine.14:57
morganfainbergbknudson: anyway. Will finalize this stuff tomorrow. I have an appointment I need to run off to.14:57
bknudsonone deployment issue might be the use of md5 for tokens by default.14:58
stevemarbknudson, "Well, it worked in DevStack" cc thingee14:58
*** gokrokve has joined #openstack-keystone14:58
bknudsonif you're trying to have a secure deployment14:58
bknudsonand other issues that go along with attempting to do a secure deployment, but that's not all keystone.14:58
marekdmorganfainberg: i am also fine with the schedule.14:59
*** lmtaylor1 has joined #openstack-keystone15:04
*** Bjoern___ has joined #openstack-keystone15:04
*** ajayaa has quit IRC15:06
*** Bjoern___ is now known as BjoernT15:08
*** zzzeek has joined #openstack-keystone15:11
*** aix has quit IRC15:13
dstanekjust 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-keystone15:13
dstaneks/is qualifies is/he qualifies it to/15:13
bknudsonthere's no david stanek here as far as I can tell15:14
*** aix has joined #openstack-keystone15:15
bknudsondstanek: that was probably another of stevemar's famous jokes.15:16
dstanekif so, then he has successfully confused me15:16
marekdbknudson: i just imagined stevemar using batman's tool to change his voice, calling dstanek.15:17
stevemardstanek, oh wow15:22
stevemari actually didn't have anything to do with that15:22
*** BjoernT has left #openstack-keystone15:25
*** e0ne has joined #openstack-keystone15:28
*** _cjones_ has joined #openstack-keystone15:38
*** mfisch has quit IRC15:40
*** mfisch has joined #openstack-keystone15:41
*** mfisch is now known as Guest6519715:41
*** _brian has joined #openstack-keystone15:45
*** _brian is now known as blewis15:46
lbragstaddolphm: o/ blewis has some work to get nginx working with keystone-deploy on his fork https://github.com/brian-tx/keystone-deploy15:47
blewisI submitted a PR - its a rough draft though15:47
lbragstaddolphm: I know you had some efforts along the same lines (with or without supervisord?)15:48
dolphmblewis: lbragstad: o/15:49
lbragstadwondering if there is a way we can figure out the delta and maybe get an nginx/supervisord branch in master?15:49
blewisim thinking about maybe just breaking uwsgi out into its own role and having supervisor manage the process15:50
dolphmlbragstad: 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 yet15:50
*** htruta has quit IRC15:50
dstanekgunicorn didn't give the performance benefits i was hoping to see15:52
*** mattfarina has joined #openstack-keystone15:52
*** htruta has joined #openstack-keystone15:53
*** sigmavirus24 is now known as Apsu_15:53
dolphmdstanek: how did you tune & benchmark it?15:53
*** Apsu_ is now known as sigmavirus2415:53
dstaneki just ran the tests and adjusted the number of process according to cpu/memory constraints15:54
dolphmdstanek: 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
blewisim not a fan of gunicorn personally15:54
lbragstadblewis: performance issues?15:55
dstanekblewis: i actually love gunicorn - that's my goto django deploy15:55
dstanekdolphm: aborted connections from apache?15:55
blewisperformance issues yes15:55
*** bdossant has quit IRC15:56
dolphmdstanek: yeah15:56
dolphmdstanek: probably just a bad tune, but there's so many variables with mpm_event + mod_wsgi :(15:56
marekdDo we still require API changes to be shipped with a spec to consider it complete?15:56
dstanekdolphm: that's odd...was the box under duress?15:56
dolphmdstanek: nope15:57
dolphmdstanek: 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
dolphmdstanek: d34dh0r53 had a pretty good theory to explain the behavior, but we didn't know how to fix the tuning to address it15:58
*** lhcheng has joined #openstack-keystone15:58
*** ChanServ sets mode: +v lhcheng15:58
marekddolphm: out of curiosity, what was the theory ?15:58
ayoungit is not a theory until it has supporting evidence.  As of now it is a hypothesis16:00
dstanekdolphm: i know this sounds weird, but how do i get a broken environment to look at?16:00
dolphmdstanek: send me your public key16:01
*** gokrokve_ has joined #openstack-keystone16:01
dolphmlbragstad: (is it still running?)16:01
dolphmdstanek: send lbragstad* your public key16:01
*** gokrokve_ has quit IRC16:01
dstanekdolphm, lbragstad: done. let me know if it's still running16:02
lbragstaddstanek: the env is still up,16:02
*** Guest65197 has quit IRC16:02
lbragstaddstanek: we can stress it... cc: dolphm blewis16:02
*** emagana has quit IRC16:03
dstaneklbragstad: i'll take a look at the box after lunch; is it easy to stress it on demand16:03
dstanek?16:04
dolphmdstanek: very16:04
dstanekok, cool16:04
*** gokrokve has quit IRC16:04
dolphmdstanek: 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-keystone16:04
*** dguerri is now known as _dguerri16:06
*** gokrokve has joined #openstack-keystone16:06
dstanekexcellent16:06
dstanekdolphm, lbragstad: i'm going to finish what i was working on, go to lunch and then i'll take a look16:06
*** gokrokve has quit IRC16:06
lbragstaddstanek: awesome16:07
samueldmqayoung, ping - you around ? need to talk about the mechanism to update the unified config file as new projects come ...16:07
samueldmqayoung, I meant the unified policy file16:07
ayoungsamueldmq, "Here I am!"16:07
samueldmqayoung, hehe16:07
ayoungthought you would like that.16:07
samueldmqayoung, did you see dhellmann's comment in the spec ? https://review.openstack.org/#/c/147651/4/specs/backlog/dynamic-policy.rst16:07
samueldmqayoung, yeah I liked :p16:08
marekdsamueldmq: 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
openstackgerritHenrique Truta proposed openstack/keystone: Add is_domain field in Project Table  https://review.openstack.org/15742716:09
samueldmqayoung, yes16:09
ayoungmarekd, I think ksc yes, osc no.  But I have not looked.16:09
ayoungsamueldmq, I would think it  should go in its own repo?16:09
marekdayoung: that would be v3.contrib.endpoint_policy ?16:09
samueldmqayoung, it's own repo or in keystone ?16:10
samueldmqayoung, as keystone will now basically be managing all the policies16:10
dolphmdstanek: pip install locustio; curl http://cdn.pasteraw.com/n4ecss6x9wciv6j3p29iktrv734x85p > locustfile.py; locust --host=http://104.130.20.208:35357;16:10
ayoungsamueldmq, I see it comparable to the systempolicy RPM that enforces SELinux16:10
ayoungit is not part of the SELinux code base itself16:10
dolphmdstanek: and then browse to port 8089 on your dev box or wherever you ran the above16:10
ayoungsamueldmq, on my machine it is policycoreutils-2.3-7.1.fc21.src.rpm16:11
samueldmqayoung, I am not familiar with selinux16:12
samueldmqayoung, so it has the repo for policies, and the enforcer ?16:12
ayoungsamueldmq, I'll link16:12
samueldmqayoung, k please16:12
*** alexsyip has joined #openstack-keystone16:17
marekdsamueldmq: what's the purpose of todays policy API ?16:18
marekdayoung: ^^16:18
marekdit stores serialized blobd, right?16:18
marekdblobs16:18
ayoungmarekd, yeah..not suer who uses it16:18
ayoungI see it as a false start myself, but I'm biased16:18
marekdand blobs are simply what usually sits in the local policy.json files per project?16:19
marekdayoung: who can operate on policy blobs? Only admin?16:19
samueldmqayoung, should the repo be created under oslo ? like oslo.policy-repo16:19
ayoungmarekd, it depends on policy.16:19
ayoungsamueldmq, or under keystone, but yes16:19
samueldmqayoung, hmm, so we keep the separate policies for backwards compatibility16:20
marekdayoung: heh, so keystone reads keystone/policy.json to conclude whether nova can fetch its serialized policy from keystone? :-)16:20
samueldmqayoung, and provide an unified as well16:20
ayoungprobably oslo, with a very deliberate set of reviewers, probably cores  from the major projects16:20
ayoungmarekd, yep, and that is something to make sure we get right16:20
ayoungI could see having policy covered by a second, hard coded policy file, instead of the main one16:21
samueldmqayoung, and as the unified policy will be in a common repo, everyone sees all the changes, still better to keep the unified policy consistent16:21
*** _dguerri is now known as dguerri16:21
*** spandhe has joined #openstack-keystone16:26
*** iamjarvo has quit IRC16:26
samueldmqayoung, will we keep separate policy files ?16:29
ayoungsamueldmq, so...maybe we can keep the files separate, something like16:29
ayoungcommon.json, novar, keystone  etc...with a build process that merges them together16:30
samueldmqayoung, k but we need further work than just merging16:30
samueldmqayoung, like standardize the roles, etc16:30
ayoungsamueldmq, that is in the common section16:30
*** ajayaa has joined #openstack-keystone16:30
* ayoung still looking for the origianl selinux repo16:31
samueldmqayoung, k I am thinking on the design of the whole thing, and the migration process16:31
*** krykowski has quit IRC16:31
openstackgerritHenrique Truta proposed openstack/keystone: List projects filtering by is_domain flag  https://review.openstack.org/15839816:31
ayoungsamueldmq, I think this is it https://github.com/fedora-selinux/selinux-policy16:32
ayoungthere might be an even more upstream for the core...still looking16:32
*** mfisch has joined #openstack-keystone16:34
ayoungsamueldmq, actually..it might be more complex:  https://github.com/SELinuxProject/selinux/tree/master/policycoreutils16:34
*** mfisch is now known as Guest1950216:34
samueldmqayoung, no readme :/16:36
ayoungsamueldmq, I'd like to get the first cut in a flat file16:36
samueldmqayoung, k a flat file to everyone16:36
ayoungmaybe just unify nova and glance and cinder16:36
ayoungneutron has special rules, and Keystone, as pointed out, has security concerns WRT to policy for policy16:37
ayoungI wonder what happens if we put neutron's rules into a nova server that does not have neutron's special policy code?16:37
ayoungDoes it blow up or are they silently ignored?  I suspect the latter16:38
ayoungsamueldmq, the general pattern on a line should be "match projectID  and check role"16:38
ayoungdon't try to have a single rule for the whole api16:39
ayoungso16:39
samueldmqayoung, yes but this will come later ... we just need to keep them in a single file16:39
samueldmqayoung, and consistent for now, right?16:39
ayoungwell, we'll have to change the common rules16:39
ayounghttp://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json16:40
samueldmqayoung, yes, but we still want services passing their existing tests with the unified policy right ?16:40
ayoungso, whereever there is "admin_or_owner"16:40
ayoungwe first expand that out.  It can be done programmatically16:40
*** emagana has quit IRC16:41
ayoungLet me see if I have a demo environemtn I can hack on16:41
*** rdo has quit IRC16:41
samueldmqayoung, if we change too much in the first round, it will be hard to services adopt it16:42
ayoungsamueldmq, agreed.  But we want to make as few common rules as possible16:42
samueldmqayoung, I think merging the rules and unifying global rules as 'admin_or_owner' is enough16:42
samueldmqfor the first round16:42
*** emagana has joined #openstack-keystone16:42
samueldmqayoung, yeah sure, I think we are talking the same thing :p16:42
ayoungadmin_or_owner is likely to be the firstp lace we see confluict.  So we do away with it16:43
ayounglet me confirm16:43
bknudsonhttps://libertydesignsummit.sched.org/event/21f1e738d1ce4e6df06341c881d4b1b2#.VUeh3kS8pLs -- looking forward to that one.16:44
bknudsonunfortunately we have a keystone session at the same time16:44
samueldmqayoung, 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
ayoungbknudson, we are still cleaning up after Termie16:45
samueldmqayoung, "if you want ot modify polciies, go there"16:45
ayoungsamueldmq, yes.16:45
stevemarbknudson, whats the conflicting one?16:45
samueldmqayoung, and then after we get everyone using it, we propose things we need to improve usability, compatibility, consistency, etc16:45
samueldmqayoung, things we have to agree with everyone16:45
ayoungthen again, we are still cleaning up from the folks he was cleaning up from, too16:45
ayoungsamueldmq, OK  give me a moment to show you waht I mean.16:46
samueldmqayoung, sure16:46
david8husamueldmq, yes, you got my profile16:47
samueldmqdavid8hu, nice, I am adding you as a contributor in the 'Dynamic Policy Overview' specs16:48
david8husamueldmq, Thanks16:49
*** gokrokve has joined #openstack-keystone16:50
samueldmqdavid8hu, np16:51
samueldmqdavid8hu, the spec is this one https://review.openstack.org/#/c/14765116:51
stevemarbknudson, oh the keystone working group is going on all morning, we can always pop in and see termie16:52
samueldmqdavid8hu, fell free to read it and get familiar if you aren't yet, also feedbakc is always welcome16:52
samueldmqmarekd, thanks for your review16:53
* samueldmq gets excited with the number of reviews that spec is receiving : )16:53
david8husamueldmq, contributed couple of -1s already :)16:54
samueldmqdavid8hu, oh sure, just saw your name there, thanks16:54
*** rdo has joined #openstack-keystone16:54
lhchengdstanek: ping16:57
*** ankita_w_ has joined #openstack-keystone16:57
*** SpamapS has joined #openstack-keystone16:58
ayoungsamueldmq bot17:00
SpamapSHi, 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=0e9ecaa117:00
SpamapSThe commit message seems somewhat unrelated. :-P17:00
lhchengdstanek: 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/144095817:01
openstackLaunchpad bug 1440958 in Keystone "loosen validation on matching trusted dashboard" [Medium,Fix committed] - Assigned to Lin Hua Cheng (lin-hua-cheng)17:01
SpamapSjamielennox: ^^ 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
ayoungsamueldmq, ok, first conflict is on default rule17:05
ayoungnova has17:05
ayoung  "default": "is_admin:True or project_id:%(project_id)s",17:05
ayoungcinder has rougly the same thing17:05
*** dguerri is now known as _dguerri17:06
ayoungglance has     "default": "",17:06
ayoungcinder tends towards rules like this17:06
ayoung    "default":  [["is_admin:True"], ["project_id:%(project_id)s"]],17:06
ayoungI'm going to use that one as the common default17:06
Guest19502stevemar: (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 package17:09
Guest19502seems related to a test you added17:09
stevemarGuest19502, hmm, thats weird17:10
Guest19502thats a function inside keystone itself so it should have never passed gate..17:10
Guest19502you are certainly only passing in 6 params17:11
Guest19502wonder if that test is skipped on gate17:11
samueldmqayoung, k so the first question is: does this break glance ?17:12
stevemarGuest19502, is that happening in test_v3_federation.py ?17:12
stevemarGuest19502, i know we mock that function17:12
samueldmqayoung, if it does, let's keep different default roles and all the services using the default policy17:12
samueldmqayoung, and work further in consistency once we get there, right?17:12
ayoungsamueldmq, I don17:13
ayoungsamueldmq, I don't think so, but we wuill have to test17:13
samueldmqayoung, ++17:13
ayoungif it does, we need to explicitly add in a rule for the broken call17:13
samueldmqayoung, I understood your approach :)17:13
ayoungbascially, there should be no defaults in the normal case17:13
*** ajayaa has quit IRC17:13
ayoungwe might define it for other people, but not for the apis shipped with the code17:14
samueldmqayoung, so we can already propose the rules we want to17:14
samueldmqayoung, and people can adopt it later if they want17:14
ayoungyes17:14
Guest19502stevemar: yeah keystone/tests/unit/test_v3_federation.py", line 3176, in test_saml_signing17:14
Guest1950217:02:44     self.PROJECT)17:14
Guest1950217:02:44 TypeError: samlize_token() takes at least 7 arguments (6 given)17:14
samueldmqayoung, nice17:14
dstaneklhcheng: at lunch right now, but I can take a look when I get back17:14
* Guest19502 shakes fist at nickserv again17:14
*** jistr has quit IRC17:15
*** Guest19502 has quit IRC17:15
*** Guest19502 has joined #openstack-keystone17:15
samueldmqayoung, how does ksmiddleware will invalidate the cached policy ?17:17
samueldmq'Marek Denis1:27 PM17:17
samueldmqKeystonemiddleware would poll Keystone in some intervals, yes?'17:17
ayoungsamueldmq, probably follow the rules for the TRL17:17
stevemarGuest19502, how are you building the package? seems really weird that it would mess up there17:17
Guest19502jenkins debian biulder17:18
Guest19502builder17:18
Guest19502so pbuilder17:18
samueldmqayoung, TRL ? I know we already have mechanisms to invalidate cached tokens, etc17:18
samueldmqayoung, I am just not familiar with them yet17:18
ayoungsamueldmq, https://github.com/admiyo/openstack-core-policy/commits/master17:19
ayoungtoken revocation list.  Part of the PKI code in auth_token middleware17:20
ayoungbasically, one minute timeout17:20
ayoungwe can make it longer or shorter as required.17:20
samueldmqayoung, so it's timeout based .. I think we can use a timestamp with updated_at17:22
samueldmqayoung, some mechanism like this, so ksmiddleware doesn't need to re-fetch if it didnt changed17:22
samueldmqchange*17:23
ayoungsamueldmq, yep..all of the HTTP protocol mechanisms at our disposal17:23
david8husamueldmq & ayoung,  My question is if the cache is outdated and keystone is not available, how should middleware behave.17:23
openstackgerritMatt Fischer proposed openstack/keystone: Pass-in domain when testing saml signing  https://review.openstack.org/17984617:23
ayoungdavid8hu, with TRL we deny everything17:23
ayoungdavid8hu, since we are moving back to online validation of tokens, that is what would happen anyway17:24
ayoungdavid8hu, with policy, I could say the rule would be "in the absense of Keystone keep processing with the old rules" too17:24
ayoungeither would work, and maybe we make that a config value17:25
david8huayoung, I am thinking some kind of hall back machanism.17:25
david8huI mean fall back17:25
samueldmqayoung, I dont see the clue between the TRL, which is to revoke tokens17:25
samueldmqayoung, and the system to invalidate the policy cahce17:25
ayoungsamueldmq, we fetch and cache the TRL17:25
*** Guest19502 is now known as mfisch17:26
samueldmqayoung, david8hu sorry need to go afk for a bit17:27
*** gokrokve has quit IRC17:27
david8huayoung, ok17:27
*** harlowja has joined #openstack-keystone17:34
david8huayoung,  I am confused.  When middleware checks with the cache,  it is the policy file that is cached.  How does token get involved?17:35
openstackgerritRodrigo Duarte proposed openstack/keystone: Refactor _create_attribute_statement IdP method  https://review.openstack.org/17264717:35
openstackgerritRodrigo Duarte proposed openstack/keystone: Add openstack_user_domain to assertion  https://review.openstack.org/17256217:35
*** gokrokve has joined #openstack-keystone17:41
*** gokrokve has quit IRC17:45
*** gokrokve has joined #openstack-keystone17:45
samueldmqdavid8hu, yeah, the same I was asking for17:46
samueldmqdavid8hu, <samueldmq> ayoung, I dont see the clue between the TRL, which is to revoke tokens17:46
samueldmqdavid8hu, I think the timestamp wiht updated_at + timeout for querying keystone if it has changed is enough17:49
*** lmtaylor1 has quit IRC17:51
bknudsonSpamapS: I thought we merged a correction to https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=0e9ecaa117:55
*** aix has quit IRC17:58
*** Ephur has joined #openstack-keystone17:58
*** lmtaylor1 has joined #openstack-keystone17:58
*** harlowja has quit IRC17:59
*** harlowja_ has joined #openstack-keystone17:59
david8husamueldmq, 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 IRC18:02
*** chlong has quit IRC18:02
david8husamueldmq, ayoung, my follow on question is where does this token come from the first place?18:03
*** Ephur has quit IRC18:03
*** EmilienM is now known as EmilienM|mtg18:05
*** packet has quit IRC18:09
*** emagana has joined #openstack-keystone18:11
*** ankita_wagh has joined #openstack-keystone18:12
*** chlong has joined #openstack-keystone18:15
*** ankita_w_ has quit IRC18:15
*** ankita_w_ has joined #openstack-keystone18:16
raildolbragstad, hey... I didn't understand your comment here: https://review.openstack.org/#/c/158372/48/keystone/tests/unit/test_backend.py18:16
raildolbragstad, Do you mean, create the golden path for  test_update_is_domain_project_name?18:17
lbragstadraildo: oh, I was just suggesting a name18:17
raildolbragstad, in the second comment18:18
lbragstadraildo: oh, yeah,18:18
*** ankita_wagh has quit IRC18:19
lbragstadraildo: 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 EmilienM18:21
raildolbragstad, 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
lbragstadraildo: ahh, gotcha. no that makes sense18:24
lbragstadraildo: thanks for following up!18:24
raildolbragstad, thank you for the reviews :) I'll send a new patch with the other comments.18:25
lbragstadraildo: perfect, thanks!18:27
*** mattfarina has quit IRC18:28
*** henrynash has quit IRC18:31
*** henrynash_ has joined #openstack-keystone18:31
*** ChanServ sets mode: +v henrynash_18:31
*** ankita_wagh has joined #openstack-keystone18:35
*** henrynash_ has quit IRC18:36
*** samueldmq_ has joined #openstack-keystone18:37
*** boris-42 has joined #openstack-keystone18:37
dhellmannbknudson, ayoung : are you ok with your cross-project sessions on roles & policy being merged into 1 session?18:37
bknudsondhellmann: I'd rather just drop the roles and we can work on it outside the summit18:37
*** henrynash has joined #openstack-keystone18:38
*** ChanServ sets mode: +v henrynash18:38
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone: Change project name constraint  https://review.openstack.org/15837218:38
bknudsonthe work is pretty obvious and I don't want to confuse policy discussion18:38
dhellmannbknudson: oh? ok, that works, too - ayoung suggested merging them18:38
dhellmannok, that's fair18:38
*** ankita_w_ has quit IRC18:38
bknudsonare all the cross-project sessions in fishbowls?18:38
dhellmannbknudson: yes18:39
bknudsonI don't think the roles work needs a fishbowl.18:39
dhellmannbknudson: are you sure you want to withdraw the proposal? there's no reason to discuss roles?18:39
dhellmannok, cool18:39
bknudsonI think we do need to discuss what's going on with roles, and we also need to discuss policy18:40
bknudsonbut I don't think they're related.18:40
bknudsonand the policy discussion will require more coordination18:41
dhellmannshould there be app-specific sessions on roles, or would that be a waste?18:41
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone: Change project name constraint  https://review.openstack.org/15837218:41
raildohenrynash, ^ with the code to get a project scoped token with is_domain=False in the token request18:41
*** rlt has quit IRC18:41
ayoungdhellmann, I think unified policy file will end up in its own repo.  That sound right to you?18:43
*** gokrokve has quit IRC18:44
*** gokrokve has joined #openstack-keystone18:48
SpamapSbknudson: if there was a correction, it wasn't to allow nulling out fields.18:50
SpamapSbknudson: 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
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements  https://review.openstack.org/17986718:51
*** ankita_w_ has joined #openstack-keystone18:53
*** henrynash has quit IRC18:56
*** ankita_wagh has quit IRC18:57
*** atiwari has joined #openstack-keystone19:00
*** Ephur has joined #openstack-keystone19:03
*** henrynash has joined #openstack-keystone19:03
*** ChanServ sets mode: +v henrynash19:03
*** chlong has quit IRC19:07
*** annasort has joined #openstack-keystone19:08
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Dynamic Policy Overview  https://review.openstack.org/14765119:10
*** samueldmq_ has quit IRC19:14
dstanekgiven 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 IRC19:21
*** e0ne has quit IRC19:26
*** e0ne has joined #openstack-keystone19:30
stevemardstanek, line 317019:31
*** e0ne has quit IRC19:35
*** e0ne has joined #openstack-keystone19:37
*** e0ne has quit IRC19:39
*** e0ne has joined #openstack-keystone19:39
*** ctina_ has joined #openstack-keystone19:40
*** e0ne has quit IRC19:41
*** e0ne has joined #openstack-keystone19:42
*** e0ne has quit IRC19:42
*** e0ne has joined #openstack-keystone19:43
*** e0ne has quit IRC19:43
*** ctina has quit IRC19:44
*** e0ne has joined #openstack-keystone19:45
*** ctina_ has quit IRC19:45
*** e0ne has quit IRC19:45
*** emagana has joined #openstack-keystone19:48
*** emagana_ has joined #openstack-keystone19:51
*** emagana has quit IRC19:52
dstanekhmmmm....ok. then it really is a bug. it's broken on one of my VMs. pushing a fix momentarily19:53
dstanekstevemar: does that mean we don't have that installed on the gate?19:53
dstanekseems like we would have to19:53
stevemardstanek, yes, i think that was an issue we were running into when writing the tests19:55
tristanCHi, can someone please approve this stable/icehouse backport: https://review.openstack.org/#/c/175519/19:56
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone: Restrict inherited role assignments to subdomains  https://review.openstack.org/16418019:57
*** e0ne has joined #openstack-keystone19:57
*** wasmum has joined #openstack-keystone19:57
*** ankita_wagh has joined #openstack-keystone19:58
wasmumanyone have time to point me in the right direction with a Juno stack? Controller - MariaDB, KS, Horizon, CentOS7 - max_connections = 100000, nova api-workers = 419:59
wasmumI keep getting "too many connections"19:59
*** ankita___ has joined #openstack-keystone19:59
*** ankita_w_ has quit IRC20:01
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller  https://review.openstack.org/15300720:02
*** ankita_wagh has quit IRC20:03
openstackgerritMerged openstack/python-keystoneclient-saml2: Rename project to keystoneclient-saml2  https://review.openstack.org/17362820:03
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/17990420:03
bknudsondstanek: https://review.openstack.org/#/c/179846/ already has one +220:05
*** josecastroleon has quit IRC20:07
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/17842620:09
*** josecastroleon has joined #openstack-keystone20:09
j_kingis 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 action20:10
openstackLaunchpad 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
ayoungj_king, not an API.  It is a config value20:10
ayoungyou cannot extend an existing token, but you can set Keystone to issue tokens with a longer life20:10
j_kingayoung: okay, that might be problematic for some operators who want a sane expiration value. hm.20:12
j_kingnot really sure it's a huge issue tbh20:12
ayoungj_king, a sane expiration vaslue is 5 minutes/  Operators are not sane20:12
ayoungthe issue is that we perform long running tasks with bearer tokens20:12
ayoungits like a cop pulling you over and  asking "did you have a valid drivers license last decade?"20:13
* ayoung steps off soapboxc20:14
j_kingayoung: I'm just wondering if this is an issue or not atm. token expiration values and policies are not my forté ;)20:14
ayoungj_king, it comes up from time to time.20:14
*** cloudnull has quit IRC20:15
j_kingi 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_kingcan always do the math I guess and set an upper bound. :)20:15
j_kingI'll look into the bearer token stuff, thanks. :)20:16
*** cloudkiller has joined #openstack-keystone20:18
ayoungj_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_kingayoung: I see. I'll defer looking into this issue until after the summit then.20:23
*** cloudkiller has quit IRC20:23
*** sigmavirus24 has quit IRC20:23
*** d34dh0r53 has quit IRC20:23
dstanekdolphm: lbragstad: i see seg faults in the apache log20:24
j_kingayoung: I don't think there's a good, practical way to resolve it given the constraints.20:24
*** hockeynut has quit IRC20:24
*** d34dh0r53 has joined #openstack-keystone20:24
*** hockeynut has joined #openstack-keystone20:24
*** cloudkiller has joined #openstack-keystone20:25
*** sigmavirus24 has joined #openstack-keystone20:26
*** htruta has quit IRC20:26
*** e0ne has quit IRC20:26
ayoungj_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
notmynameswap those. swift doesn't talk to cinder. cinder talks to swift20:28
j_kingayoung: what notmyname said :)20:28
j_kingayoung: the cinder backup process splits up the volume into chunks and uploads them to a swift container20:29
ayoungj_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
ayoungSo, instead, we need to tell Cinder:  here is how you get a token when you need it on my behalf20:30
*** e0ne has joined #openstack-keystone20:30
samueldmqayoung, 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 IRC20:30
*** boris-42 has quit IRC20:30
ayoungthis 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 kiester20:30
ayoungsamueldmq, write it up, please20:30
*** cyeoh has quit IRC20:31
samueldmqayoung, ++20:31
j_kingayoung: right. i looked at the delegation apis20:31
*** Trozz has quit IRC20:31
*** Trozz has joined #openstack-keystone20:31
*** Nakato has quit IRC20:32
*** sudorandom has quit IRC20:32
j_kingayoung: it wasn't clear how to set that up for the process to use. :)20:32
*** cloudkiller is now known as cloudnull20:32
*** Nakato has joined #openstack-keystone20:33
ayoungj_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
ayoungWe want it so the API can create the trust, but we give sane limitations to that creation20:33
ayoungand 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 swift20:33
ayoungI could almost see it like a middleware20:33
*** hockeynut has quit IRC20:33
*** jraim has joined #openstack-keystone20:33
ayoungj_king, I know.  I am pretty much the only person that thinks this way, except for the Heat team people I have corrupted20:33
*** hockeynut has joined #openstack-keystone20:34
j_kingayoung: that's about the gist of it iirc20:34
ayoungthe endpoints don't know to tell the user "hey, you need to create a trust" which would also work20:34
ayoungthat is how oauth tends to work:20:34
*** d34dh0r53 has quit IRC20:34
ayounggo to a resource,  resources says "I need more auth"20:34
*** sigmavirus24 has quit IRC20:34
*** cyeoh has joined #openstack-keystone20:34
*** htruta has joined #openstack-keystone20:34
*** d34dh0r53 has joined #openstack-keystone20:35
ayoungor..rather, go to a service , service responds with "I need auth for resources"20:35
ayoungand redirec ts you to the oauth server to create that delegation agreement20:35
*** sigmavirus24 has joined #openstack-keystone20:35
*** boris-42 has joined #openstack-keystone20:36
*** sudorandom has joined #openstack-keystone20:37
ayoungnow...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_kingright... 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
ayoungbut..before any of this makes sense, we need to get endpoint binding of tokens working20:37
ayoungcuz until we have that, people are just going to get tokens that are scoepd to the universe20:37
ayoungj_king, exactly20:37
j_kingIt'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_kingie: "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
ayoungj_king, we could do that easily.  THe tough part is getting the APIs to clarify what additional auth then need20:41
ayoungand 401 or 403 would probably be confusing return codes...let me see what oauth specifies20:41
j_kingcoolio20:41
ayoungj_king, I'm guessing a redirect would be appropriate20:43
ayoung HTTP 30220:44
ayoung30320:45
j_kingHTTP/1.1?20:45
*** e0ne has quit IRC20:45
j_kingwould it be changing the request type?20:46
ayoungdstanek, 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-canned20:46
ayoungj_king, so the 303 would be a GET, and would contain enought information for the client to create the trust20:47
j_kingyeah, sounds good20:47
ayoungthe 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 like20:48
*** samueldmq_ has joined #openstack-keystone20:48
j_kingI think that would also help improve some of our internal tools that face similar scenarios20:52
*** browne has joined #openstack-keystone20:53
david8huayoung, 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
morganfainbergayoung: 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 summit20:54
samueldmqdavid8hu, 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
david8huopenstack client20:55
morganfainbergsamueldmq: openstack client is the CLI we use. keystoneclient cli is deprecated, keystoneclient as a library is all we're focused on there20:56
samueldmqdavid8hu, yeah, not sure we need a spec, but at least a blueprint, check with ayoung20:56
samueldmqmorganfainberg, ++20:56
david8huWe should not add new CLI feature to keystone client.20:56
morganfainbergcorrect20:56
morganfainbergnew cli features in keystoneclient will get -2'd20:56
samueldmqo/20:57
david8hua quick way to earn -2 :)20:57
samueldmqyeah20:57
samueldmqmorganfainberg, btw, 'identity v3 only jobs' https://review.openstack.org/#/q/topic:identity-v3-only-jobs,n,z20:57
morganfainbergsamueldmq: nice20:57
samueldmqmorganfainberg, just have a review from mordred to apply there20:57
morganfainbergcool20:57
samueldmqmorganfainberg, we don't need to passthrough the env var using d-g20:58
mordredI didn't do it20:58
morganfainbergmordred: you might have :P20:58
samueldmqmordred, hehe20:58
* mordred hides amidst a field of opium poppies and floating gum drop fairies20:58
mordredhrm. that might have implied something incorrect ...20:59
morganfainbergLOL20:59
morganfainbergbknudson: http://libertydesignsummit.sched.org/event/2bdea90b411ba50fc62efff044b8e4b8 [the one opposite termie's talk] is a "general" session21:02
morganfainbergbknudson: so it's just a go here and talk keystone if you want. no need for everyone to be there21:02
bknudsonmorganfainberg: that might be the most useful session of the summit for us21:03
morganfainberghehe21:03
*** samleon has joined #openstack-keystone21:03
bknudsonor it might just be people showing up and throwing tomatoes21:03
morganfainbergbknudson: i also just turned the "deployment" work session into documentation work session21:04
morganfainbergbknudson: and added it ot the doc track as well21:04
*** samleon has quit IRC21:04
bknudsonmorganfainberg: nice.21:04
morganfainbergbknudson: and if you think swapping priority setting and ops feedback fishbowls is a good idea, happy to do that21:05
*** samleon has joined #openstack-keystone21:05
bknudsonhttp://docs.openstack.org/admin-guide-cloud/content/ch-identity-mgmt-config.html -- not impressive21:05
*** raildo has quit IRC21:05
bknudsonmorganfainberg: I'm fine with the order as is. if ops want to help set the priority they can show up.21:06
morganfainbergyeah i figure that is the way it goes21:06
morganfainbergand ops session could also impact priorities21:06
morganfainbergnot sure what the last fishbowl should be21:06
morganfainbergwe could do policy things21:06
morganfainbergbut that is likely to turn into craziness21:06
bknudsonthere's a cross-project for policy21:06
morganfainbergbknudson: no need for us to do that then21:06
morganfainbergwell...21:07
bknudsonpotentially, I don't know if the x-project have all been selected yet.21:07
morganfainbergis that "congress" policy?21:07
*** ankita_wagh has joined #openstack-keystone21:07
morganfainbergor RBAC policy21:07
bknudsonno, it's ayoung's21:07
morganfainbergor "group based policy"21:07
morganfainbergok21:07
morganfainbergcool21:07
morganfainbergx-project looks TBD still: http://libertydesignsummit.sched.org/overview/type/design+summit/Cross+Project+workshops21:07
lifelesswe're finalising it atm21:08
lifelessI have an etherpad around here somewhere, we -might- have a slot free21:08
lifelessI'm fairly sure one policy one got in - roles for services21:08
morganfainberglifeless: that's ayoung's then21:09
lifelessI think we squashed it together with a related policy one about having a single big policy for a whole cloud21:09
morganfainbergboth are related21:09
dolphmdstanek: 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
dolphmi haven't looked at the logs since friday21:09
morganfainberglifeless: but policy $things$ yes.21:10
dstanekdolphm: i don't think it's regular21:10
morganfainberglifeless: did the service catalog one get traction?21:10
*** ankita___ has quit IRC21:10
lifelesshttps://etherpad.openstack.org/p/liberty-cross-project-session-planning21:10
* morganfainberg looks21:11
dstanekdolphm: any reason you guys are using mpm_event? this is the first time i've seen that and it's marked as experimental21:11
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient-saml2: Updated from global requirements  https://review.openstack.org/16158821:11
morganfainberglifeless: yeah ok catalog one looks like it's in there21:12
ayoungmorganfainberg, 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 header21:14
ayoungor in the body of the request or something21:14
ayoungit feels like OAuth21:14
ayoungI wonder if we could use the OAuth extension to make something like that happen21:14
ayoungunify oauth and trusts behind the scenes21:15
*** ankita_w_ has joined #openstack-keystone21:15
*** ankita___ has joined #openstack-keystone21:17
*** ankita_wagh has quit IRC21:18
morganfainbergayoung: this was actually a request i had from a meeting recently21:19
ayoungdavid8hu, write whatever specs you think are appropriate.  I am just kciking off this avalanche and surfing21:19
morganfainbergayoung: make inter-service stuff more oauth-ish.21:19
ayoungmorganfainberg, what I wrote up?21:19
ayoungcool21:19
morganfainbergayoung: yep.21:19
ayoungtermie will be happy about that21:19
morganfainbergayoung: now... i don't want to store an oauth token for *every* request21:19
morganfainbergwe're back to unbounded data sets and token tables21:19
ayoungmorganfainberg, nah, just for the long ones21:19
ayoungand they are short lived tokens21:19
morganfainbergayoung: what is a long running task?21:19
*** ankita_w_ has quit IRC21:20
morganfainbergayoung: which tasks is that? do we need to special case each one?21:20
ayoungmorganfainberg, we make the mechanism available, and let the services tell us21:20
ayoungKeystone will allow a service to define a precanned trust21:20
morganfainbergayoung: can we instead find a way to bind a token to say.. nova - and issue a token with special powers21:20
ayoungwe only allow those to be assigned to service users21:20
morganfainbergrather than needing to store the data in keystone?21:20
ayoungto users with the service role on the service domain21:20
morganfainbergagain this is going to be an unbounded/db intensive thing21:20
morganfainbergif we can err on the side of non-persistence here i'd be happier21:21
morganfainbergto be clear: I want to make sure we look at non-persistent options. not saying it must be non-persistent21:21
ayoungtrh trust should at least be OKed by the user...but..we could make certain trusts implied....21:21
morganfainbergayoung: that is kindof what i'm looking for.21:21
ayoungimplied trust would be defined at the Keystone level.  What I want is clear transition rules:21:22
morganfainbergayoung: mull over options on limiting what we need to stash in stable storage21:22
ayoungIf the service user hands in a user token with role R1, then they can get a token for endpoihnt E with role R221:22
mfischstevemar: can you convince someone else to +2 https://review.openstack.org/#/c/179846/ so I dont have to hold it?21:22
morganfainbergbut 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 proxy21:22
* mfisch wonders who wants a free beer in vancouver21:22
stevemarayoung, morganfainberg can you look at ^ from mfisch21:22
morganfainbergmfisch: -2! i mean... looking at it21:23
mfischlol21:23
ayounghttps://etherpad.openstack.org/p/implied-trusts21:23
ayounglet me copy in there what we have so far21:23
* mfisch ships Franzia to morganfainberg 21:23
mfischthanks morganfainberg21:23
ayoungmorganfainberg, a precanned trust could probably be implemented with Fernet21:24
morganfainbergayoung: that is kind-of my thought21:24
morganfainbergayoung: i am very concerned that we end up removing token persistence for trust explosion ;)21:24
morganfainbergayoung: so i think we might be better off if we can do the pre-canned-trust where appropriate21:25
ayoungmorganfainberg, hell, we can make Keystone completely stateless21:25
ayoungrole assignments get checked via fernet?21:25
morganfainbergayoung: I think at some point we need some state21:25
morganfainbergbut that should be long-running state21:25
morganfainbergnot token-length21:25
ayoungmorganfainberg, let me suggest Deleware.  It is small21:25
morganfainbergsingle task length21:25
ayoungMaybe RHode Island21:25
morganfainbergayoung: haha21:25
morganfainbergayoung: yeah don't go with california.21:26
ayoungassignment is long running state21:26
ayoungas is delegation21:26
morganfainbergcorrect. but token-TTL length (or similar <86400s operations) should be in the range we don't need to store cruft for if at all possible21:26
ayoungthe lionger we make them, the more revocations we are going to have to persisit21:26
morganfainbergif it's something ephemeral, lets take a stab at non-persist.21:27
ayoungpersisisisisist21:27
morganfainbergayoung: your precious.............esess.....21:27
morganfainbergpockets?21:27
ayoungNasty Baginses21:27
morganfainbergre: limited use trusts21:27
morganfainbergalso had an ask to allow the operator to set a min/max for trust life21:27
morganfainbergand max # of consumptions for limited use21:28
ayoungmax might be a problem21:28
ayoungHeat can run for a long while21:28
morganfainbergyeah but you might use an unlimited trust for that21:28
ayoungI wonder if we need "Class of trusts"21:28
ayoungnah21:28
morganfainberganyway21:28
morganfainbergit was an ask to make those an option21:28
* ayoung rapps own knuckles for suggesting21:28
ayoungmorganfainberg, I can't help but think that we could make use of henrynash 's split of assignment for this somehow21:29
ayoungroles assignments, trusts, and oauth are all delegations21:29
morganfainbergthings to talk about @ the summit21:30
morganfainbergyou have ~2wks to mull it over :)21:30
ayoungI know we should make the consumer table into a special domain21:30
*** ankita_wagh has joined #openstack-keystone21:30
ayoungmorganfainberg, is there a place to fit  "unified delegation" into the keystone discussions?21:31
morganfainbergwe have an open fishbowl and work session21:31
morganfainbergwe also have some "general" topic work sessions at the moment21:31
morganfainbergthat could be co-opted21:32
ayounglets take one and somehow make it offcial. I want to advertise to non Keystone people that we are discussing this21:32
morganfainbergso if you want more than keystone developers... fishbowl21:33
morganfainbergand expect plenty of people to show up21:33
morganfainbergif we want it just keystone devs - work session21:33
*** ankita___ has quit IRC21:33
ayoungI wonder if we can somehow integrate this with K2K Federation.  It should be the same kind of mechanism21:34
ayoungWith K2K we get a SAML assertion...thanks Obama21:34
morganfainbergi mean we can do "AuthN and Delegation"21:34
stevemarayoung, obama says you're welcome :P21:36
ayoungmorganfainberg, actually...saml and keystone tokens are just different content types.  We could distinguish between the types with an accepts header21:36
*** samueldmq has quit IRC21:40
*** samueldmq_ is now known as samueldmq21:40
*** aix has joined #openstack-keystone21:46
ayoungstevemar, 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 well21:54
*** _dguerri has quit IRC21:54
ayoungIt should be a good test of Kilo code21:54
*** lmtaylor1 has left #openstack-keystone21:56
*** samueldmq has quit IRC21:57
stevemarayoung, just give me a reminder tomorrow21:58
ayoungstevemar, wilco21:59
*** dguerri has joined #openstack-keystone22:00
*** ankita_wagh has quit IRC22:02
morganfainbergayoung: we also need to issue Cache-control headers22:02
morganfainbergayoung: if we're talking about adhering to http things22:02
morganfainbergayoung: i'll try and be in #rdo as well fwiw22:03
ayoungmorganfainberg, I'll post a reminder to the room22:03
*** ChanServ changes topic to "Liberty Development Open | Review Liberty Specs | Summit in 2 weeks!"22:04
ayoungmorganfainberg, 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
morganfainbergi would love to hit 443 instead with deconflicted urls22:05
morganfainbergbut honestly, i'd worry about that today22:05
* morganfainberg summons david-lyle re: horizon running on non-root location.22:06
david-lyleyou called22:06
morganfainbergayoung: my thought is we need to have a serious talk about deconflicting URLs and making sure everything can run (notably horizon) on shared vhosts22:06
*** harlowja_ has quit IRC22:06
ayoungmorganfainberg, horizon is there22:06
morganfainbergdavid-lyle: can horizon be moved off / yet? or does it need to still own the root?22:06
ayoungmorganfainberg, he got the last change in22:07
morganfainbergi know that was an issue not-too-long ago22:07
morganfainbergah22:07
morganfainbergcool22:07
ayoungit was a DOA change for WEBROOT22:07
david-lyleshould work22:07
*** harlowja has joined #openstack-keystone22:07
david-lyleah, that just merged, correct?22:07
ayoungmorganfainberg, so I should push for 443?22:07
morganfainbergayoung: for kilo i'd stick with discreet ports and aim to gate on shared-vhost in liberty22:07
ayoungdavid-lyle, yep, tested it22:07
morganfainbergayoung: so we can be sure we don't regress.22:07
david-lyleI can release d-o-a again22:07
ayoungmorganfainberg, that is going to propogate child abuse22:07
*** gordc has quit IRC22:07
david-lyleI think it will be 1.3.022:08
david-lylefor liberty22:08
ayoungdavid-lyle, 1.2.1 I thought22:08
morganfainbergayoung: it is the correct way to ensure we don't fall backwars.22:08
ayoungits a bug fix22:08
ayoungmorganfainberg, I think we will have more errors with http vs https on the same ports22:08
* morganfainberg assumes liberty vs kilo for things like this22:08
morganfainbergwe probably will22:08
david-lyleayoung: I think 1.2.* is left for kilo stable updates22:08
david-lyleIIUC22:08
morganfainberguse proper SSL termination :P22:08
david-lyleI'll ping ttx in the morning to confirm22:09
ayoungmorganfainberg, this is documentation only at this point22:09
*** blewis has quit IRC22:09
ayoungI think I would rather tell people "SSL means moving to port 443" and only have to backpeddle if people look at me sternly22:09
morganfainbergseriously, i'd worry if we're not gating on it.22:09
morganfainbergthats all.22:09
morganfainbergso 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
ayoungmorganfainberg, so you think https on 35357 is the norm already?22:10
morganfainbergyes22:10
ayoungok22:10
ayoungthat is easier22:10
morganfainbergany serious deployments SSL terminate (stunnel, apache, etc) on 35357 and 500022:10
ayoungthe easy way is always harder22:10
morganfainbergsometimes they terminate the stunnel and stuff for "public" url endpoint22:10
morganfainbergand not for internal22:10
morganfainbergand actually use different hosts/urls for those.22:11
ayoungmorganfainberg, the OAuth thing I just talked about...gonna need to be able to create multiple trusts22:16
ayoungone for each remote service you want to talk to22:16
morganfainbergayoung: we will need to map out the way this all works22:16
ayoungmorganfainberg, I'm just trying to captture the rivulets running off this braindrizzle22:17
* morganfainberg hands a bucket over22:17
morganfainbergdon't let the drizzle escape22:17
*** ayoung is now known as ayoung-dadmode22:17
*** ankita_wagh has joined #openstack-keystone22:19
morganfainbergdstanek: ping22:19
*** nkinder has quit IRC22:35
*** joesavak has quit IRC22:36
*** bknudson has quit IRC22:44
*** mattfarina has joined #openstack-keystone22:51
*** mattfarina has quit IRC22:51
*** gsilvis has quit IRC22:54
*** gsilvis has joined #openstack-keystone23:01
jamielennoxSpamapS: i agree it seems somewhat unrelated - however i don't think that change would have actually changed the behaviour of that field23:10
jamielennoxSpamapS: 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 same23:11
SpamapSjamielennox: I'm wondering why you would want to remove the entries with a value of None though.23:11
SpamapSjamielennox: 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
SpamapSjamielennox: 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
jamielennoxSpamapS: I would tend to agree, the manager code is horrible23:13
*** Ephur has quit IRC23:13
SpamapSjamielennox: 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
jamielennoxSpamapS: would love that23:16
jamielennoxso https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L38223:16
SpamapSjamielennox: of course, we're also planning on factoring out python-keystoneclient .. so this may be moot. ;)23:17
jamielennoxthat filter_kwargs https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L6123:17
jamielennoxone of the things it does is drop all None kwargs23:17
jamielennoxfor 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 there23:18
jamielennoxSpamapS: factoring out ksc?23:18
SpamapSjamielennox: yes, we're bending over backward to use the clientlibs. We'd still use keystoneclient for session actually.23:18
jamielennoxSpamapS: yea, they are terrible23:19
jamielennoxSpamapS: so have you heard us talk of keystoneauth?23:19
jamielennoxhttps://github.com/openstack/keystoneauth23:19
SpamapSjamielennox: no, but would that be just the session, w/o the rest of keystoneclient ?23:19
jamielennoxSpamapS: pretty much23:19
SpamapSbecause that would be interesting to openstacksdk too :)23:20
jamielennoxall the stuff that is common across clients23:20
jamielennoxI'm hoping so23:20
SpamapSyeah thats basically what openstacksdk's mission is.. make a single client for all the things.23:20
SpamapSthat works sort of in the same way for everything23:20
SpamapSshade is a step even further.. it is a library to encode the most common actions in simple methods.23:21
SpamapSjamielennox: thanks for the heads up I will keep an eye on that!23:21
jamielennoxSpamapS: we haven't had a release yet, it's our chance for breaking changes so we're looking at it, but hopefully around summit time23:22
SpamapSsummit, the best time to sneak your release into the wild! :)23:23
SpamapSjamielennox: 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
SpamapSjamielennox: 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
SpamapSsince I'd imagine it might break stuff to allow it.23:24
jamielennoxSpamapS: i don't have an answer, as much as i've become the client guy i'm mainly interested in standardizing all the auth parts23:25
jamielennoxSpamapS: but yes, a bug report would be good - also ask horizon as they must have done something like this23:25
jamielennoxmaybe they set the empty string?23:25
*** samueldmq has joined #openstack-keystone23:27
*** chlong has joined #openstack-keystone23:30
*** stevemar has quit IRC23:37
*** gokrokve has quit IRC23:39
*** _cjones_ has quit IRC23:42
*** dims_ has joined #openstack-keystone23:42
*** dims has quit IRC23:44
*** Raildo has joined #openstack-keystone23:54
*** lhcheng has quit IRC23:56
*** nkinder has joined #openstack-keystone23:58

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