Thursday, 2017-03-02

*** browne has quit IRC00:05
*** browne has joined #openstack-keystone00:09
*** lamt has joined #openstack-keystone00:12
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes
*** _cjones_ has quit IRC00:21
*** _cjones_ has joined #openstack-keystone00:22
*** _cjones_ has quit IRC00:26
*** lamt has quit IRC00:31
*** thorst has joined #openstack-keystone00:31
*** thorst has quit IRC00:36
*** tovin07 has joined #openstack-keystone00:38
*** thorst has joined #openstack-keystone00:41
openstackgerritAnthony Washington proposed openstack/keystone master: Ensure token expiration is always consistent
adriant_Would I be able to do a single API call (maybe 2) to work out if two projects are in the same tree after work on this spec is done:
adriant_ ?00:59
adriant_Because currently I'd need to do a full upward tree traversal to the non-domain root to see if they are both in the same tree.01:00
*** thorst has quit IRC01:01
*** catintheroof has joined #openstack-keystone01:04
*** ngupta has quit IRC01:07
*** jamielennox is now known as jamielennox|away01:16
*** liujiong has joined #openstack-keystone01:17
*** guoshan has joined #openstack-keystone01:24
*** prashkre_ has joined #openstack-keystone01:32
*** prashkre has quit IRC01:32
*** browne has quit IRC01:36
*** browne has joined #openstack-keystone01:40
rodrigodsadriant_, you can do that via the "parents_as_ids" query parameter01:44
rodrigodsso you get for both projects and check if they have the same ID there01:44
*** adrian_otto has quit IRC01:44
adriant_rodrigods, oh, can I do that now?01:45
rodrigodsadriant_, you do a GET /v3/projects/<project_id>?parents_as_ids=true01:45
rodrigodsit returns the parents of the project organized in a dictionary01:45
rodrigodsonly the IDs01:45
adriant_rodrigods, oh! Fantastic. I haven't had to try yet, but that works perfectly for something I'll need.01:45
adriant_that's fine, I just need to compare roots01:46
rodrigodsadriant_, great!01:46
adriant_it's always nice to find out and API already supports the thing you need01:47
rodrigodsadriant_, ++ it is supposed to be documented, but looks like it isn't01:48
adriant_rodrigods, while I'm at it, is there a single API call to get all children for a given project? I haven't looked too deeply into it yet, but don't remember seeing it in the docs.01:49
*** browne has quit IRC01:49
rodrigodsadriant_, yep!01:50
rodrigodssubtree_as_ids :)01:50
adriant_I know I can do project list and "parent_id=<project_id>"01:50
adriant_but I never looked too deep for subtrees01:51
adriant_ah, but just IDs?01:51
rodrigodsyes... just the IDs01:51
rodrigodsorganized in a dict01:51
adriant_so I'd then need to do a get query for each...01:51
rodrigodswe also have subtree_as_list and parents_as_list01:51
rodrigodswhich returns the info of the projects01:51
rodrigodshowever... they only return info for projects the user has access to01:52
adriant_subtree as list sounds like what I want01:52
rodrigodsaka have role assignments on them01:52
adriant_I need an admin command that return a full subtree01:52
rodrigodswe don't have it :(01:52
adriant_so it shouldn't care about roles01:52
rodrigodshowever... you can do a subtree_as_ids and then query for each project01:53
rodrigodsthere you will have the infos01:53
rodrigodsi personally don't like the *as_list API (although i've implemented myself)01:53
adriant_but then I'm doing an O(n) operation for subtree info :(01:54
rodrigodsadriant_, yeah... i know01:54
rodrigodsbut it is tricky to not leak information for such API calls01:54
rodrigodsso we decided to do like that01:55
adriant_Ok, I think in this case I'll just stick to only showing just the immediate subtree, as I can do that with projects.list(parent_id=<current_project>)01:55
rodrigodsadriant_, do you have huge hierarchies?01:56
adriant_not yet :P01:56
adriant_but after I'm done... probably reasonably wide01:56
adriant_I'm setting max depth at 4 or 501:56
adriant_and some limit in breadth01:57
adriant_we aren't using heirarchies since we're a single domain cloud, so I'm doing some weird wrapper logic and project_path based naming to allow something 'like' HMT to work.01:57
adriant_single domain 'public' cloud...01:58
adriant_so a project name will end up: "my-company/some-team/website-project/dev"01:59
rodrigodshmm nice01:59
adriant_I'll post a thread and some demos when I get it all working nicely to the mailing list.01:59
rodrigodswe thought a lot about hierarchical names for projects01:59
rodrigodsturns out we would need a whole new API version to support it01:59
rodrigodsadriant_, nice!01:59
adriant_yeah, that's why I'm doing it as just a naming convention02:00
adriant_to allow semi-unique subproject naming02:00
adriant_I remember reading the specs for unique namespaces for subprojects and liked the path system best02:01
adriant_so I'm doing that with our management service using just the name field, but... my max depth is 64chars :P02:01
*** catintheroof has quit IRC02:01
adriant_because the keystone project name field is 64...02:01
adriant_or was it 100?02:02
rodrigodsis it still 64?02:02
adriant_lemme check02:02
rodrigodsit is:
adriant_name = sql.Column(sql.String(64), nullable=False)02:03
adriant_while 'name' in all other openstack projects is 25502:03
adriant_rodrigods, I complained a whilke back on the mailing list but nothing happened. May just submit a patch.02:08
rodrigodsadriant_, ++02:08
adriant_although having the id be 64 is also a little silly since keystone uses uui4.hex which is always 32 :P02:09
*** gyee has quit IRC02:12
*** gyee has joined #openstack-keystone02:12
*** ngupta has joined #openstack-keystone02:16
*** MasterOfBugs has quit IRC02:20
*** agrebennikov_ has quit IRC02:24
*** ngupta has quit IRC02:33
*** ngupta has joined #openstack-keystone02:33
*** namnh has joined #openstack-keystone02:34
*** ngupta has quit IRC02:38
*** martinus__ has quit IRC02:40
*** martinus__ has joined #openstack-keystone02:43
*** gyee has quit IRC02:58
*** gyee has joined #openstack-keystone02:59
*** dave-mccowan has joined #openstack-keystone03:07
*** links has joined #openstack-keystone03:08
*** ngupta has joined #openstack-keystone03:15
*** erlon has quit IRC03:35
*** thorst has joined #openstack-keystone03:50
*** thorst has quit IRC03:50
*** rcernin has quit IRC03:50
*** nicolasbock has quit IRC04:06
*** dave-mccowan has quit IRC04:16
*** dnalezyt has quit IRC04:23
*** thorst has joined #openstack-keystone04:32
*** thorst has quit IRC04:32
*** adrian_otto has joined #openstack-keystone04:38
openstackgerritTony Breeds proposed openstack/keystone master: [DNM] Testing WebOb 1.7.1
openstackgerritTony Breeds proposed openstack/keystonemiddleware master: [DNM] Testing WebOb 1.7.1
*** adrian_otto has quit IRC04:54
*** h5t4_ has joined #openstack-keystone04:57
*** guoshan has quit IRC05:00
*** lamt has joined #openstack-keystone05:02
*** thorst has joined #openstack-keystone05:03
*** ravelar has quit IRC05:03
*** lamt has quit IRC05:05
*** guoshan has joined #openstack-keystone05:12
*** thorst has quit IRC05:16
*** adriant_ has quit IRC05:20
*** rderose has quit IRC05:21
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements
*** guoshan has quit IRC05:27
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements
*** prashkre has joined #openstack-keystone05:49
*** prashkre_ has quit IRC05:49
*** prashkre_ has joined #openstack-keystone05:50
*** prashkre has quit IRC05:50
*** h5t4_ has quit IRC05:53
*** guoshan has joined #openstack-keystone05:55
*** dikonoor has joined #openstack-keystone05:59
*** arturb has quit IRC06:03
*** Dinesh_Bhor has quit IRC06:09
*** ngupta has quit IRC06:18
*** arturb has joined #openstack-keystone06:27
*** prashkre__ has joined #openstack-keystone06:29
*** prashkre_ has quit IRC06:29
*** prashkre_ has joined #openstack-keystone06:31
*** prashkre__ has quit IRC06:31
*** edmondsw has joined #openstack-keystone06:32
*** prashkre_ has quit IRC06:34
*** prashkre_ has joined #openstack-keystone06:34
*** richm has quit IRC06:43
*** Dinesh_Bhor has joined #openstack-keystone06:46
*** zhurong has joined #openstack-keystone06:47
*** h5t4 has joined #openstack-keystone06:51
*** zhurong has quit IRC06:53
*** gyee has quit IRC06:54
*** edmondsw has quit IRC06:56
*** namnh has quit IRC07:06
*** rcernin has joined #openstack-keystone07:18
*** tesseract has joined #openstack-keystone07:18
*** namnh has joined #openstack-keystone07:23
*** edmondsw has joined #openstack-keystone07:24
*** edmondsw has quit IRC07:29
*** edmondsw has joined #openstack-keystone07:29
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Imported Translations from Zanata
*** edmondsw has quit IRC07:34
*** zhugaoxiao has joined #openstack-keystone07:34
*** prashkre_ has quit IRC07:38
*** prashkre_ has joined #openstack-keystone07:39
*** prashkre__ has joined #openstack-keystone07:45
*** prashkre_ has quit IRC07:45
*** slunkad has quit IRC08:07
*** slunkad has joined #openstack-keystone08:11
*** pcaruana has joined #openstack-keystone08:13
*** DFFlanders has joined #openstack-keystone08:41
*** jaosorior has joined #openstack-keystone08:56
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:00
openstackgerritRico Lin proposed openstack/python-keystoneclient master: Update test requirement
openstackgerritRico Lin proposed openstack/keystoneauth master: Update test requirement
*** thorst has joined #openstack-keystone09:13
*** thorst has quit IRC09:18
*** guoshan has quit IRC09:20
*** arunkant has quit IRC09:47
*** namnh has quit IRC09:55
*** aasthad has quit IRC10:02
*** liujiong has quit IRC10:07
*** tovin07 has quit IRC10:12
openstackgerritRico Lin proposed openstack/oslo.policy master: [Fix gate]Update test requirement
*** links has quit IRC10:31
*** links has joined #openstack-keystone10:47
*** dikonoor has quit IRC10:49
*** DFFlanders has quit IRC10:51
*** mvk has quit IRC10:57
*** nicolasbock has joined #openstack-keystone11:01
*** egonzalez has joined #openstack-keystone11:04
*** dikonoor has joined #openstack-keystone11:07
*** dikonoo has joined #openstack-keystone11:08
*** dikonoor has quit IRC11:11
*** richm has joined #openstack-keystone11:11
*** dikonoor has joined #openstack-keystone11:12
*** thorst has joined #openstack-keystone11:14
*** dikonoo has quit IRC11:15
*** thorst has quit IRC11:19
*** edmondsw has joined #openstack-keystone11:20
*** edmondsw has quit IRC11:25
*** mvk has joined #openstack-keystone11:28
*** dikonoor has quit IRC11:42
*** dikonoor has joined #openstack-keystone11:51
*** links has quit IRC11:51
openstackgerritRico Lin proposed openstack/ldappool master: [Fix gate]Update test requirement
openstackgerritOpenStack Proposal Bot proposed openstack/oslo.policy master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements
*** links has joined #openstack-keystone12:04
*** raildo has joined #openstack-keystone12:13
*** raildo_ has joined #openstack-keystone12:13
*** ngupta has joined #openstack-keystone12:22
*** ngupta has quit IRC12:27
*** thorst has joined #openstack-keystone12:45
*** catintheroof has joined #openstack-keystone12:56
*** raildo has quit IRC12:59
*** raildo_ is now known as raildo12:59
*** rderose has joined #openstack-keystone13:13
*** jdennis has quit IRC13:14
*** jlwhite has quit IRC13:15
*** jlwhite has joined #openstack-keystone13:15
*** ngupta has joined #openstack-keystone13:23
*** ngupta has quit IRC13:27
*** chlong_ has joined #openstack-keystone13:40
*** jdennis has joined #openstack-keystone13:42
*** mvk has quit IRC13:52
*** prashkre__ has quit IRC13:53
*** spilla has joined #openstack-keystone14:03
*** breton has quit IRC14:07
*** lamt has joined #openstack-keystone14:11
*** lamt has quit IRC14:12
*** links has quit IRC14:12
*** lamt has joined #openstack-keystone14:25
dstanekrderose: look as and let me know where our thoughts don't jive14:25
rderosedstanek: okay14:27
*** edmondsw has joined #openstack-keystone14:32
rderosedstanek: what is the key a hash of?14:32
*** breton has joined #openstack-keystone14:32
rderosedstanek: ah, I see random bytes14:34
dstanekrderose: yep, random bytes14:35
dstanekrderose: i think that spec is really only missing a strong justification and some elaboration on the security issues14:36
dstanekand then that would be a clear picture of how i see api keys14:36
rderosedstanek: yeah, I think that can work. the only issue is hitting the database for every validation14:36
rderosebut as we discussed, we're already doing that with revocation events14:37
dstanekrderose: i think we are doing that for other reasons too. remember when you validate a token you get back a ton of information14:37
rderosedstanek: okay14:38
*** ngupta has joined #openstack-keystone14:42
*** ngupta_ has joined #openstack-keystone14:43
*** johndperkins has joined #openstack-keystone14:45
*** ngupta has quit IRC14:46
*** ngupta_ has quit IRC14:49
*** ngupta has joined #openstack-keystone14:49
*** prashkre has joined #openstack-keystone14:50
openstackgerritMerged openstack/keystone master: Remove EndpointFilterCatalog
*** mvk has joined #openstack-keystone14:56
*** lamt has quit IRC15:01
*** johndperkins has quit IRC15:03
*** johndperkins has joined #openstack-keystone15:05
*** dikonoor has quit IRC15:06
*** rderose has quit IRC15:11
openstackgerritMerged openstack/keystone master: Exchange cURL examples for openstackclient
dstaneki'd be interested in hearing from dolphm, notmorgan, jamielennox|away and others - do my thoughts on API keys reflect yours?15:14
*** ravelar has joined #openstack-keystone15:16
*** chris_hultin|AWA is now known as chris_hultin15:16
*** lamt has joined #openstack-keystone15:19
dolphmdstanek: i'll review, but the one thought i had that i threw on that easel was that api keys should be subject to quota limits, so you should only be able to generate like 100 api keys per user by default, or something15:22
dolphmdstanek: just to prevent the "i need to boot a vm! <create API key> <use API key to boot vm> <discard API key>" pattern like we see with tokens15:23
dstanekdolphm: lol, sure. that would be so much harder then the normal flow already :-)15:25
dstanekdolphm: at least we'll have quote in keystone. now keystone can use it too!15:25
*** dave-mccowan has joined #openstack-keystone15:26
dolphmdstanek: specifically, i don't want them to expire, and i want there to be such a low number of API keys that cache hits are likely15:26
dolphmdstanek: and yeah, dogfood15:26
dstanekdolphm:  we have to be careful with caching since api keys are more like passwords than tokens15:28
dolphmdstanek: don't we already hash or encrypt tokens in cache?15:29
dstanek"more like" meaning a compromise of an api key is like a compromise of a password (with a limited scope) since there is no expiration15:29
dolphmdstanek: (in auth_token)15:29
dstanekdolphm: yes, i'm not worried about the actual storage. just limiting the mess in case of a compromise15:30
*** spzala has joined #openstack-keystone15:30
dolphmdstanek: ++15:31
dstanekfor example, it may be wise to cache the output of an api-key (like the token body style response) and make sure we hit the DB each time (or much more frequently) to make sure it's still valid15:31
*** lucasxu has joined #openstack-keystone15:32
*** lamt has quit IRC15:33
dolphmdstanek: so, like count() whether the key is in the db, and if so, you know it's immutable and you can return from cache? why not just delete from cache when an api key is revoked?15:33
*** lamt has joined #openstack-keystone15:34
dstanekdolphm: actually that's a good point. i was thinking of distributed caching like with varnish15:35
dstanekdoing too many things at once this morning15:35
dolphmman, i haven't heard anyone mention varnish in forever15:35
dolphmdstanek: are any openstack deployers using varnish?15:36
dstanekprobably not. our cache headers suck15:39
dstaneki use it for all kinds of things though15:39
dolphmoh, that's true15:39
prashkrerodrigods:lbragstad: Hi Lance/Rodrigo. I am working on the follow up patch for Could you please help me how to release notes. do we follow any process to create release notes?15:41
lbragstadprashkre i'm actually in the middle of reviewing that patch :)15:42
prashkrelbragstad: sure.15:43
*** rakhmerov has quit IRC15:43
*** rderose has joined #openstack-keystone15:46
prashkrelbragstad: At time of my first contribution, I have followed [1] to create release notes for nova. do we have any such process for keystone. [1]
*** rakhmerov has joined #openstack-keystone15:49
gagehugoprashkre that's what I use as well15:50
gagehugoit's the same process15:50
notmorgandolphm: we do not encrypt tokens in cache. in ksm there is an option. to but is rarely used.15:50
notmorganand we have not implemented cache control stuff for keystone, we should.15:51
dolphm"we do not" == "devstack doesn't" ?15:51
dstanekprashkre: yeah, keystone uses reno so the docs apply here as well15:52
dstaneknotmorgan: i thought we did encrypt tokens in the cache15:52
notmorganyou have to configure it I. ksm15:53
notmorganmost people I know don't bother to15:53
notmorgankeystone does not have those options.15:53
dstaneknotmorgan: fair enough. we support it even if it's not used15:54
dstanekkeystone should if we cache credentials15:54
notmorgandolphm: I want an expiration always passed on creation of API keys, but 0 means doesn't expire15:54
notmorgandolphm: and I agree, quota limit on them is good.15:54
dolphmnull is more explicit than a timestamp in the past15:55
dstaneknotmorgan: any other thoughts about the implementation. i documented what i thought to be a real simple implementation15:55
notmorgandolphm: sure, but must be passed.15:55
dstanekalso, why do we use X-Auth-Token instead of Authorization?15:55
notmorgandstanek: I can implement the encryption in cache in about 10m in dogpile15:55
bknudson_if you delete your token while the instance is booting it'll fail.15:56
dolphmdstanek: that's what nova or swift used before keystone existed *shrug*15:56
bknudson_(I mean the instance will fail to boot)15:56
notmorganbecause folks who did that didn't read the RFC saying don't x-prefix headers ;)15:57
dstaneknotmorgan: not cache encryption implementation - api key implementation15:57
notmorganbut yeah historical, nova did that before, we do it now15:57
notmorgandstanek: I was commenting we can implement encryption in cache trivially.15:58
notmorganthat's all.15:58
dstanekwhat i've not thought through is what nova does with an15:58
dstanekAPI key. just pass it through like a token?15:58
*** lamt has quit IRC15:58
dstanekor would they go and get a token for it?15:59
notmorganwell depends on implementation15:59
notmorganme, I'd like to make it a signed request15:59
bknudson_the api key better have the catalog so that nova can find the other services15:59
notmorganbut that is a lot of moving parts15:59
*** rcernin has quit IRC15:59
notmorganlikely need to use it to get a token15:59
notmorganbecause of service catalog reasons.15:59
rderosenotmorgan: that is how I originally thought of it15:59
notmorganalso <rant>stupid endpoint being dynamic based upon user token</rant>16:00
rderoseworking on updating this though16:00
*** ayoung has quit IRC16:00
notmorganthe endpoint filtering based on tokens is going to bite us again here.16:00
notmorgananyways, so likely needs a normal token.16:00
*** chlong_ has quit IRC16:01
bknudson_I don't think we considered the issues with endpoint filtering and how nova uses tokens.16:01
*** chlong__ has joined #openstack-keystone16:01
bknudson_what if glance is filtered out and I try to boot an instance?16:02
notmorganI am still of the opinion the catalog should be static and not change because of auth context. the endpoint should say "nope" if it isn't allowed.16:02
notmorganbknudson_: you are possibly very broken.16:02
notmorganwe don't test those cases... in fact I'd use that as an argument to deprecate filtering.16:02
dstanekrderose: i think the same way about the service. weren't you also thinkin thinking that the user would need to get a token for the api-key?16:02
notmorganif the catalog was static, things like apikeys could go straight to the service.16:03
bknudson_maybe nova shouldn't use the client's service catalog.16:03
notmorganor you could do discovery if you need.16:03
dstaneknotmorgan: signed requests would be awesome, but i think that it could be added on later16:03
bknudson_what's the advantage of signed requests over client certificates?16:04
notmorganbknudson_: different mechanism for validation. x509 is heavy to validate everywhere.16:04
*** rderose has quit IRC16:04
notmorgansigned requests can be confirmed by keystone via ksm16:05
*** rderose has joined #openstack-keystone16:05
dstaneknotmorgan: wait, so you're thnking that the user never sends the api-key to nova?16:05
notmorgansigned request would be sent to the endpoint directly.16:05
notmorgandstanek: that would be my choice, the API key would be the signing secret16:05
bknudson_signed requests seem to break REST... I'm not going to sign requests by hand.16:05
rderosedstanek: a token for the API key? the other way round, you auth with an api key and request a token was my original thought16:05
notmorganhmac, time, nonce, request, secret id16:06
notmorganksm asks keystone to validate. (same as today)16:06
notmorgankeystone validates.16:06
bknudson_a fernet token from an API key would be very small16:06
notmorgansecret never hits the wire.16:06
dstanekrderose: user presents api-key and gets token is what i was saying16:06
openstackgerritRichard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order
rderosedstanek: ah, yes16:06
notmorgandstanek: that would be my choice, second choice is api-key to nova direct, third (easier and most likely to be implemented) api-key to keystone for token16:07
*** markvoelker has quit IRC16:07
notmorganwe can also work backwards16:07
bknudson_let's just start API keys with "MII" and then auth_token knows what it is.16:07
dstanekif api-key isn't a bearer token then it's not really an api-key; at that point we are just providing the user with "alternative passwords" #notmyauthz16:08
rderosebknudson_: "MII"?16:08
notmorganbknudson_: I kind of hate you right now ;)16:08
bknudson_that's how auth_token used to figure out if a token was PKI or UUID.16:08
notmorganrderose: PKI tokens.16:08
bknudson_it's probably still there.16:09
dstanekbknudson_: ++ MI6 would be cooler16:09
notmorganbknudson_: I thought we ripped that Mii crap out16:10
*** ayoung has joined #openstack-keystone16:10
notmorganthough we may not have removed the CMS code from everywhere.16:10
bknudson_actually, auth_token sends every token to keystone for validation now so it's just keystone would have to know that the token's an API key16:10
bknudson_API key would have to be scoped16:11
rderosebknudson_: yeah, agree16:12
prashkregagehugo:dstanek: Thank you!.16:12
*** markvoelker has joined #openstack-keystone16:12
rderosebknudson_: but if we treat API keys as a credential that auths and request a scoped token, then validation doesn't have to change (maybe)16:12
bknudson_sure. I was thinking of the case of being able to use api keys against nova directly.16:13
rderosebknudson_: I see16:13
notmorganbknudson_: if we do that can we just jump to signed requests.16:14
bknudson_which might be a useful feature16:14
notmorganit eliminates the secret on the wire.16:14
notmorganno more scrubbing of logs needed in ksm/nova16:14
notmorganno secrets in the logs16:14
bknudson_my problem with signed requests is I can't do them using curl16:15
notmorganwe could write a curl extension ;)16:15
bknudson_so auth_token middleware would validate the signature?16:15
notmorganATM would send to keystone. same as a time16:15
bknudson_the whole request?16:16
notmorganyes, minus body like glance image thing16:16
notmorgannot body, data like glance images16:16
bknudson_ok, so the headers would give you enough info to check that the user made the request...16:17
bknudson_it's not really to protect the data, just to prove the user was the sender16:17
bknudson_that sounds ok... maybe can limit the headers so it's not all of them.16:18
notmorganand keystone would return the values expected same as validation16:18
notmorganof tokens.16:18
*** lamt has joined #openstack-keystone16:18
bknudson_and limit the header size. so wouldn't be too much data16:18
bknudson_ok, let's do that.16:19
*** lamt has quit IRC16:19
bknudson_do we need to prevent replay attacks? So keystone needs to store the nonces already used?16:20
notmorganwe would use ksm for nonces IMO16:20
bknudson_we'd have to figure out how nova could "forward" the request.16:21
notmorgankeystone doesn't need to care, ksm can care for it, since I'd make endpoint part of the signature.16:21
notmorganto start, we can just pass back an actual token to nova for the forwarding.16:22
notmorganand make keystone tokens mostly a service-to-service thing16:22
notmorganthen clean that up as the next bit16:22
bknudson_would require a change to nova since it's not getting the token from auth_token16:22
notmorganksm would pass the token down in the context16:23
notmorgandon't need to change nova, ksm owns the request before it hits nova16:23
bknudson_y, we can make it work, just saying nova doesn't get the token from auth_token, it gets it from the original request.16:23
notmorganright, ksm can fudge that for nova16:24
bknudson_ah, I see.16:24
notmorgansince ksm can muck with the request object.16:24
bknudson_just update the request to set x-auth-token.16:24
notmorganthe idea is to separate concerns further. service to service is one workflow that is hard to change16:25
notmorganuser to service is easier in many ways16:25
*** dikonoor has joined #openstack-keystone16:25
notmorgangive users a better mechanism, with benefits, they'll use ot16:25
*** prashkre has quit IRC16:26
*** prashkre has joined #openstack-keystone16:26
notmorganservices are a lot of code change, so we focus on that as a separate concern. we may find service to service bearer tokens are the best choice and just keep it.16:26
notmorganalso if the catalog is static, user can just get the catalog (light weight keystone call) and send signed request to <endpoint>16:27
notmorganif discovery is needed.16:27
bknudson_I thought we were just going to use dns.16:28
notmorganI'd like that16:28
notmorganbut if we can't, ... we could still do keystone discovery16:29
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes
*** lamt has joined #openstack-keystone16:30
*** prashkre has quit IRC16:30
*** ducttape_ has joined #openstack-keystone16:30
*** ducttape_ has left #openstack-keystone16:31
openstackgerritMerged openstack/keystone master: Fix some typo in releasenotes
*** h5t4 has quit IRC16:41
*** agrebennikov_ has joined #openstack-keystone16:42
*** pcaruana has quit IRC16:42
*** prashkre has joined #openstack-keystone16:46
openstackgerritColleen Murphy proposed openstack/keystone master: Fix duplicate handling for user-specified IDs
*** browne has joined #openstack-keystone16:48
*** _cjones_ has joined #openstack-keystone16:49
*** _cjones_ has quit IRC16:49
*** _cjones_ has joined #openstack-keystone16:50
*** egonzalez has quit IRC17:08
*** dave-mcc_ has joined #openstack-keystone17:12
*** dave-mccowan has quit IRC17:13
*** dave-mccowan has joined #openstack-keystone17:15
*** dave-mcc_ has quit IRC17:17
*** aasthad has joined #openstack-keystone17:19
openstackgerritGage Hugo proposed openstack/keystone master: Change is_admin_project to False by default
dstanekbknudson_: ++ to using api keys against the services17:29
bknudson_seems handy but I'm not sure how many would wind up using it since they'll still be using existing tools.17:30
bknudson_but if I was writing a new tool to check server status it would be easier to just use nova.17:31
dstanekbknudson_: the intent is for users to use it in place of passwords or tokens in config files17:33
lbragstadprashkre i left my comments on
bknudson_right, so you can get a regular token using an api key17:34
lbragstadprashkre i think we should just remove the notification to persist the revocation event17:34
lbragstadprashkre instead of moving the validation bits17:34
bknudson_but as an extension maybe could also support using api key against another service.17:35
lbragstadprashkre i have to step away for a minute17:35
ayoungCan I just +2A my own damn patch that has been sitting since October with only stevemar having looked at it.  and17:36
dstanekbknudson_: sure you could if we didn't want to push the key to the service17:36
*** lucasxu has quit IRC17:36
lbragstadayoung i'm still reviewing it17:37
lbragstadi started looking at the series yesterday17:37
ayounglbragstad, TYVM17:37
ayounglbragstad, but it should not be a PTL responsibility to review every patch17:37
lbragstadayoung i'm not reviewing it from a PTL only perspective, i'm truly interested in it :)17:38
ayounglbragstad, that is still only one reviewer.  stevemar only +1ed it17:38
*** lucasxu has joined #openstack-keystone17:38
* lbragstad runs away to grab lunch17:38
dstanekayoung: i've blocked out most of my morning tomorrow to review patches! so i'm excited about that17:40
ayoungdstanek, Thanks17:40
* dstanek might be sick in the head17:40
ayoungthe goal is to get down to the point where the only thing failing is the Tempest tests on the is_admin checks for Nova, Keystone, etc17:42
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements
openstackgerritKristi Nikolla proposed openstack/keystone master: Remove password_expires_ignore_user_ids
*** browne has quit IRC17:49
*** adrian_otto has joined #openstack-keystone17:52
*** tesseract has quit IRC17:52
ayounglbragstad, so the error on the last patch in the series is Tempest based:  they are making admin users all over the place as opposed to onlu\y in the admin project
*** h5t4_ has joined #openstack-keystone17:53
ayoungIn other words, the patch is right, the tests are wrong.17:53
ayoungSame is true-ish for the tests in Nova17:53
*** lucasxu has quit IRC17:54
*** spzala has quit IRC18:06
*** erlon has joined #openstack-keystone18:07
openstackgerritRon De Rose proposed openstack/keystone-specs master: Add API access key credentials
*** lamt has quit IRC18:16
ayoungrderose,  what is the point?18:17
ayoungsounds like you are mixing two different concepts there:18:17
ayoung1.  Servcie users18:17
ayoung2. Delegations18:17
ayoungwhat's driving that?18:18
*** jaosorior has quit IRC18:19
openstackgerritRon De Rose proposed openstack/keystone-specs master: Add API access key credentials
openstackgerritRon De Rose proposed openstack/keystone-specs master: Add API access key credentials
rderoseayoung: this came out of the ptg, the main use case is allowing me as a developer to give limited access to my scripts or jobs that run against my project resources18:27
rderoseayoung: so that I'm not putting my username/password in configuration files18:28
rderoseayoung: jamielennox started this conversation, he has spec out there that's similar, but was more about having different authorization for each type of auth method:18:29
*** edmondsw has quit IRC18:29
ayoungrderose, so its roughly comparable to allowing an average user to create a service user and giving them a non-redelegatable limited access trust18:30
ayoungyep, I've talked about that with him18:30
rderoseayoung: yeah, I suppose (that was a mouth full :) )18:30
*** Krishna has joined #openstack-keystone18:30
*** dikonoor has quit IRC18:31
*** Krishna has quit IRC18:31
ayoungthe unified delegation stuff that amakarov was working on a while back would support this18:31
rderoseayoung: oh really18:31
*** kris7987 has joined #openstack-keystone18:31
ayoungyep, the idea is that we should not have different delegation mechanisms for role assignments, trusts, OAUTH, and now this18:32
*** edmondsw has joined #openstack-keystone18:32
*** lucasxu has joined #openstack-keystone18:32
ayoungrderose, I like where you are going with this, but please look at the existing mechanisms and reuse where ever possible18:32
rderoseayoung: okay18:32
kris7987is there any effort going to support Cassandra as backend for Keystone? if so what is the timeline?18:33
rderoseayoung: are you thinking, in terms of existing mechanisms, as OAuth and/or delegation?18:34
ayoungkris7987, no and I would not pursue18:34
ayoungrderose, look at the unified delegation patches...I think they are still posted18:34
rderoseayoung: cool, will do.  thx18:34
ayoungrderose, IE...its hard to get this right.  You want to reuse the mechanisms in the trusts code18:34
kris7987@ayoung is there any reason?18:35
ayoungkris7987, yes, long history.  We origianlly were built on a Key-value-pair based architecture18:35
ayoungits all SQL now due to the complexity of the interelationships between the objects18:36
ayoungthat is a really short version, probably unsatisfying, but let me ask...why Cassandra?18:36
*** edmondsw has quit IRC18:36
kris7987@ayoung thanks18:36
ayoungBTW, no @ sign needed in IRC18:36
kris7987@young well or any other distributed DB's for handling Multi-DC situations.18:37
ayoungkris7987, the biggest frustration most people have with the MySQL based approach is multi-site.  Is that the problem you are trying to deal with?18:37
openstackgerritMerged openstack/keystone master: Removing group role assignments results in overly broad revocation events
ayoungkris7987, yeah, Gallera multi-site seems to be what the operators have all settled on.  With Keystone and Fernet tokens, the worst of the lag problems are handled OK18:40
ayoungyou can issue tokens from one server and validate them on another OK18:40
kris7987yes i was thinking along the same line.18:41
notmorganthere is nothing that prevents a cassandra backend... but keeping parity with the codebase is a challenge.18:41
ayoungfernet does not hit the Database.  Doesn't help when you are doing updates, but those should be rare enough cross database...18:41
openstackgerritRon De Rose proposed openstack/keystone-specs master: Add API access key credentials
ayoungnotmorgan, you removed the KVS code yourself, you hippogriff18:41
notmorganayoung: yes i did18:41
notmorganit doesn't mean someone can't make their own backend that is out-of-tree18:41
notmorgansorry i wasn't clear on that18:41
ayoungnotmorgan, I like what Termie said about plugins in his "OpenStack is doomed" talk]18:42
ayoungbasically its our way of saying "we don;t want that"18:42
notmorganplugins don't bother me. [they have a place, aka like ksa auth plugins"]18:42
notmorganthose (much more in line with what termie was talking about) are terrible18:42
notmorganand i agree cause doom-y-things18:43
*** spzala has joined #openstack-keystone18:43
ayoungnotmorgan, yeah, he was referring more to 3rd party plugins, like Cinder's Augean stable of drivers that thingee cleaned way back when18:43
kris7987I was also thinking of making keystone as RBAC system for managing non openstack roles18:43
ayoungkris7987, so was I, once upon a time18:43
notmorgankris7987: you can do that but be warned... keystone really has gaps on that front and was designed with openstack in mind18:43
notmorgani would like it if keystone could easily perform that as a generic authz service18:44
ayoungKeystone was not designed18:44
notmorganit... well, it does things weird.18:44
notmorganayoung: lol true enough.18:44
ayoungit emerged.  Crawled from the slime of dark Scottish Loch18:44
*** jose-phi_ has joined #openstack-keystone18:44
notmorganayoung: nothing that cool, def. didn't come from scotland. it was dredged out of the SF bay18:45
ayoungI think it was dredged from a river in San Antonio prepraring for the River Walk revitalization18:45
ayoungyou are thinking of Treasure Island18:46
*** jose-phillips has quit IRC18:46
kris7987you know with some changes.keystone really has a shot on becoming a generic RBAC/ API gateway solution ;-)18:51
*** spzala has quit IRC18:51
*** jdennis has quit IRC18:51
*** jdennis has joined #openstack-keystone18:57
*** kris7987 has quit IRC18:58
*** _cjones_ has quit IRC19:01
*** _cjones_ has joined #openstack-keystone19:01
lbragstadravelar what happens if we do valdiation in the controller for the federated attributes?
*** _cjones_ has quit IRC19:06
*** adrian_otto has quit IRC19:07
lbragstadravelar for v3, we typically try to keep validation of requests in the controller layer, instead of buried in the manager19:07
ravelarlbragstad validation already happens with json schema right?19:08
lbragstadravelar what happens if we move validation from identity/ to identity/
ravelarlbragstad what validation exactly are you referring to?19:08
lbragstadravelar right - we define a scheme of things we accept and the schema is enforced at the controller level19:08
lbragstadravelar for example is our schema for identity related objecst19:09
*** thorst has quit IRC19:09
lbragstadravelar which we apply in the controllers
ravelarlbragstad yes19:09
*** thorst has joined #openstack-keystone19:10
lbragstadravelar your patch does some additional validation in the identity manager -
ravelarlbragstad right, unit tests call manager directly with self.identity_api which bypass this in some cases19:10
lbragstadravelar I'm wondering what happens if we move the validation you're introducing in into the schema we already have defined in identity/schema.py19:10
rderoselbragstad ravelar: so the main issue is we can't enforce that fed != [] without fixing a ton of tests, right?19:10
ravelaryeah, moral of the story is you can validate it anywhere and it will fail regardless if you force the constraint of all or nothing19:11
lbragstadravelar so your patch works now because you have the validation in core.py19:11
lbragstadravelar but if you move that validation into jsonschema, then it fails because you're bypassing the controller19:12
lbragstadand other tests are hitting the issue because they aren't going through the controller19:12
ravelarlbragstad exactly19:12
lbragstadravelar i see19:13
ravelarlbragstad alot of unit tests for user go straight to self.identity_api.create_user and then recycle the user to again go back into identity_api19:13
lbragstadso - in order for us to do this properly (in the sense that we keep validation in the controller) we have to refactor a lot of tests19:13
lbragstadbecause we do things like self.identity_api.create_user() **everywhere** in the tests to set things up, which calls directly into the manage and bypasses validation19:14
*** edmondsw has joined #openstack-keystone19:14
*** thorst has quit IRC19:14
ravelarlbragstad yup, its actually quiet intersting19:14
lbragstadravelar do you know how many tests fail as a byproduct of moving this all into controller validation?19:15
*** adrian_otto has joined #openstack-keystone19:16
ravelarlbragstad let me get that for you19:17
knikollai'm already in the process of trying to refactor ldap tests, so i can help if you decide to tackle this19:18
knikollarefactoring is fun19:18
*** lucasxu has quit IRC19:18
lbragstadknikolla i would say it depends on the refactor ;)19:19
*** lucasxu has joined #openstack-keystone19:19
ravelarlbragstad ++19:19
ravelarknikolla has a go to attitude19:19
*** prashkre has quit IRC19:20
*** adrian_otto has quit IRC19:23
*** adrian_otto has joined #openstack-keystone19:25
lbragstadknikolla ravelar rderose so - ideally we would want our v3 tests to use'v3/users/') instead of self.identity_api.create_user()19:25
ravelarlbragstad knikolla test that fail from no validation in core for attribute 2019:25
ravelarlbragstad knikolla current times that self.identity_api.some_user_method is called to bypass controller 200+19:26
lbragstadfor some reason I think i was expecting that to be more19:27
ravelarlbragstad well the tests inside api unit testing like test_v3_identity already call self.post19:28
ravelarits the ones inside things like identity/test_core19:28
ravelarthat essentially do this19:28
lbragstadravelar knikolla maybe we should start an etherpad19:28
knikollalbragstad: ++19:29
lbragstadknikolla ravelar rderose
ravelarlbragstad so my question is, we still call self.identity_api.create_user, etc when we are specifically trying to test the functionality of the method19:30
ravelarlbragstad only in the instance of the failing tests we should use something like unit.new_user when we want to just create a new user for things that dont require going to self.identity_api.create_user?19:30
lbragstadravelar I think that would be the starting point because it's the least amount of work for us to merge that patch19:33
lbragstadravelar but I think we eventually need to come to consensus on how we go about setting things up in tests.19:33
ravelarlbragstad ah I see :)19:35
*** lamt has joined #openstack-keystone19:35
knikollawe need to also take into consideration nonwritable backends19:35
knikollaotherwise a lot of ldap code will stay there indefinitely19:35
knikollabut that's a next step19:36
rderoselbragstad: following the etherpad and agree19:36
*** lamt has quit IRC19:36
rderoselbragstad: but for 426449, we could keep the check in core for now19:36
rderoselbragstad ravelar: and do this refactoring/fixing in subsequent patches19:37
*** lamt has joined #openstack-keystone19:37
rderoseknikolla: ^19:37
knikollarderose: that can work too.19:37
robcresswelllbragstad: o/ Just had a thought, we probably dont have much to discuss in the cross-project this week. Should I cancel this weeks one?19:37
*** MasterOfBugs has joined #openstack-keystone19:37
lbragstadrobcresswell sure - that sounds good19:37
knikollarderose: nothing will change behaviour-wise19:37
rderoseknikolla: right19:38
lbragstadrobcresswell i thought last weeks dicussion was good19:38
robcresswelllbragstad: Me too! It's got me thinking about trying to setup weekly meetings with other projects19:38
lbragstadrobcresswell ++19:38
*** spilla has quit IRC19:38
lbragstadrobcresswell i like the pattern and it proved productive, at least for our groups19:39
robcresswellWe've solved a bunch of issues and then have more in the pipeline. Very productive19:39
*** adrian_otto has quit IRC19:45
*** edmondsw has quit IRC19:47
lbragstadravelar do you have a diff of moving the validation into I was going to run all the tests with it to get a list of things we need to fix19:47
ravelarlbragstad removed it earlier to work on another patch, but I quickly added the change again19:49
ravelarlbragstad one sec19:49
lbragstadravelar i have a copy locally too that i'm working on too19:49
*** edmondsw has joined #openstack-keystone19:50
ravelarhere is the one I did when I made the changes you wanted19:50
ravelarahh it disappeared19:51
*** ayoung has quit IRC19:53
lbragstadravelar sweet - that's pretty much what i changed locally19:55
*** jamielennox|away is now known as jamielennox20:02
knikollalbragstad: thoughts on ? should i go ahead and change the router?20:14
openstackLaunchpad bug 1669070 in OpenStack Identity (keystone) "Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200" [Undecided,New]20:14
lbragstadknikolla yeah - i saw that one yesterday, i still need to dig into it20:16
lbragstadknikolla are you able to recreate it?20:16
knikollayeah. the list_grants call is registered for both get and head, so roles/ gives back the head of listing.20:17
lbragstadravelar do the failures in the etherpad look consistent with the ones you found?20:17
lbragstadknikolla hmm20:17
*** lamt has quit IRC20:23
lbragstadknikolla interesting - i think there are two bugs there, right?20:23
lbragstadknikolla one is that head shouldn't return a body20:23
lbragstadknikolla and the other is that if you pass that call a non-existent role, it returns 200 instead of a 400 or 40420:23
knikollalbragstad: it's not returning a body. well, it's setting content-type to json, but there is no body.20:24
lbragstadknikolla ah - ok, for some reason I was thinking a body was getting returned20:24
*** lamt has joined #openstack-keystone20:25
knikollalbragstad: the other one is because it's going to the listing api call (which also supports head)20:25
lbragstadso GET returns the body HEAD does not, right?20:25
knikollalbragstad: yes20:25
knikollalbragstad: the bug isn't as much as a "non-existant" role, but an empty role. if you pass 123 as the role it gives back 404 correctly.20:26
knikollawith no role present it strips the ending "/" and does a head on role list20:27
knikollaso the fix is either making role listing with HEAD return 40420:27
knikollaor leaving the current behaviour20:27
lbragstadknikolla oh20:27
lbragstadgot it20:28
*** chris_hultin is now known as chris_hultin|AWA20:28
dstaneki'm not quite understanding the osc->osc_lib transition all wrapped un in cliff20:28
lbragstadso it's the difference between and
knikollalbragstad: yes20:28
lbragstadknikolla ah... so it ultimately makes no sense to call HEAD on the list_grants api20:30
dstanekknikolla: is that really what it's doing? getting the first role?20:31
lbragstaddstanek well we have two apis that are similar, one checks the grant and the other lists the grants,20:32
knikolladstanek: no, it's just giving back the head of role listing when no role_id has been provided. as it strips our the ending "/"20:32
lbragstadbut it doesn't make sense to call HEAD on the list grants api because there is no body20:32
lbragstadreturned from keystone20:32
* lbragstad dstanek
openstackLaunchpad bug 1669070 in OpenStack Identity (keystone) "Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200" [Undecided,New]20:32
lbragstadknikolla the issues is that i think we'd be breaking backwards compatibility if we changed that 200 to be a 400 :(20:34
dstanekcan you do a GET on that resource?20:35
*** h5t4_ has quit IRC20:35
*** thorst has joined #openstack-keystone20:35
knikollalbragstad: that's my concern too, and why i asked for opinions20:36
knikollalbragstad: it's undocumented behaviour, but something might rely on doing head to list_grants20:37
lbragstadknikolla i would imagine they are broken since you'd be expecting something back but getting nothing :(20:38
knikollalbragstad: not really. GET works.20:38
knikollalbragstad: the ONLY weird thing is that if you don't validate that you are passing an empty role_id, you will default to the role listing20:39
knikollaand if you rely on that for checking if you have a role20:39
lbragstadwhich doesn't make any sense when listing things20:39
lbragstaddoes the logic for listing check role assignment?20:40
knikollalbragstad: that should work and give you back only the roles you have20:40
knikollain my testing case, i have no roles on the domain20:41
knikollaso it's empty20:41
knikollai don't think anything is really broken from this bug, just awkward behaviour20:41
lbragstadclients written to get anything useful out of HEAD list assignments are probably mislead20:42
lbragstadand if anyone is checking a specific assignment, they should be checking for it explicitly20:42
lbragstadusing head to list assignment doesn't really make much sense to me20:43
knikollalbragstad: check rather than list, if they don't validate strings and pass an empty one20:43
knikollalbragstad: yeah20:43
lbragstadcurious to hear if dstanek has an opinion20:43
lbragstadbut yeah - it sounds like if a client isn't validating roles properly before using those api, it could get weird20:44
lbragstadbecause they would effectively be seeing a 200 OK from HEAD list assignment instead of HEAD check assignments20:45
knikollawe need opinionated api people20:47
lbragstadi wonder if anyone from the API WG is in this channel?20:47
*** DFFlanders has joined #openstack-keystone20:47
*** jose-phillips has joined #openstack-keystone20:52
*** jose-phi_ has quit IRC20:53
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault
openstackgerritEric Brown proposed openstack/keystone master: Modify examples to use v3 URLs
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault
*** adriant has joined #openstack-keystone20:59
bknudson_apache converts HEAD calls to GET calls.21:05
bknudson_so if you're running in mod_wsgi apache keystone is never going to see a HEAD request.21:06
dstanekbknudson_: the backward compat rules don't allow a 2xx to go to a 4xx21:06
dstanekbknudson_: oops...mean lbragstad and knikolla21:07
lbragstadI left a comment21:07
dstanekHEAD should really be allowed on anything that allows a GET21:07
* lbragstad goes to see if SpamapS is in -dev21:07
lbragstaddstanek but do we have to worry about the case where a client is trying to call check_grant but accidentally calls list_grants because they didn't validate the role id before building the url?21:08
dstaneklbragstad: it's certainly an unfortunate API flaw, but the bug would be in the client21:11
knikolladstanek: that's what i thought too about being generally acceptable for HEAD. if you can do a GET, you can do a HEAD.21:11
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault
lbragstadso maybe our best plan of action is to clearly document it in the API reg21:12
dstanekand bknudson_ is right. keystone won't know it's a head request. apache will ask for a GET and show off the body21:12
knikolladstanek: is that always the case? i think i changed the router to only register GET for list_grants and doing HEAD gave me a 40421:14
knikolladstanek: under apache21:14
dstanekknikolla: i'm pretty sure. i'd have to try though21:15
knikolladstanek: trying now, give me a sec21:16
dstanekknikolla: you can't give a 404 for a head of the same resource that give a 200 for a get21:16
dstanekfirst line says why that's invalid
knikolladstanek: i understand that it's invalid, i was just curious if what you said about apache is true21:17
knikollai changed the router to register only get for that url, and head gave a 404, while get a 20021:17
dstanekknikolla: added to mod_wsgi a long time ago maybe they changed it?21:18
knikollabknudson_: ^^21:18
dstanekknikolla: are you using mod_wsgi, uwsgi or something else?21:19
knikolladstanek: stock devstack, so mod_wsgi21:19
openstackgerritSean Dague proposed openstack/keystone-specs master: WIP: early rough draft of unified limits
bknudson_ says "20. Always change a HEAD request into a GET request."21:20
dstanekbknudson_: you copied my link :P21:20
bknudson_it's possible the behavior of mod_wsgi has changed.21:21
*** adrian_otto has joined #openstack-keystone21:21
knikollaor our framework is doing fancy stuff21:21
dstanekknikolla: it can't be us - we don't have control over that21:22
*** lamt has quit IRC21:22
knikolladstanek: bknudson_:
knikollanumber 1221:26
bknudson_oh, cool21:27
bknudson_maybe changed when got a newer ubuntu21:27
knikollabknudson_: yeah, xenial has 4.3.021:28 it will now do it sometimes :-)21:28
bknudson_wish we had tempest testing for more keystone functions21:29
*** edmondsw has quit IRC21:31
*** edmondsw has joined #openstack-keystone21:35
ravelarlbragstad sorry for late comment, meetings. Yeah they are all results of calling the api directly21:43
*** dave-mccowan has quit IRC21:44
*** chris_hultin|AWA is now known as chris_hultin21:45
*** chris_hultin is now known as chris_hultin|AWA21:49
lbragstadravelar so it's all ldap tests21:49
ravelarlbragstad pretty much21:50
ravelarall the tests were located in either test_v3_identity or identity/backends21:50
*** anteaya has quit IRC21:54
*** cburgess has quit IRC21:54
*** cburgess has joined #openstack-keystone22:00
*** ravelar has quit IRC22:01
*** rderose has quit IRC22:03
*** mwheckmann has joined #openstack-keystone22:04
*** cburgess has quit IRC22:04
*** ravelar has joined #openstack-keystone22:05
*** anteaya has joined #openstack-keystone22:07
*** thorst has quit IRC22:08
mwheckmannhello. I added a couple of comments to bug # 968696 and I'm wondering if I'm wait out on left field.. Should I even expect those things to work right now or we still in the incremental process of fixing the admin issue?22:09
*** ravelar has quit IRC22:09
*** cburgess has joined #openstack-keystone22:10
knikollalbragstad: i plan to remove the "update" tests in a later patch22:12
knikollalbragstad: i have a patch now which removes every instance of delete in ldap tests and code22:12
knikollaupdate is next22:12
lbragstadknikolla nice - ravelar should be able to rebase on those then22:13
knikollalbragstad: we could get the patch in with the logic in the manager, like it is now, and we can move it over to the controller after that is done.22:14
notmorganknikolla: what logic is the issue?22:14
lbragstadknikolla that's true22:15
notmorganbknudson_: re HEAD/GET If Apache 2.X, this will not however be done if there are no Apache output filters registered which could change the response headers or content.22:16
notmorganbknudson_: this is just what is passed to the backend, apache should *still* respond with the correct data from a GET.22:16
*** cburgess has quit IRC22:16
notmorganknikolla: ah22:16
*** cburgess has joined #openstack-keystone22:22
*** ngupta_ has joined #openstack-keystone22:32
*** rderose has joined #openstack-keystone22:33
notmorgancburgess: welcome back.22:34
*** ngupta has quit IRC22:34
*** ngupta_ has quit IRC22:36
*** thorst has joined #openstack-keystone22:36
*** catintheroof has quit IRC22:40
*** thorst has quit IRC22:41
openstackgerritKristi Nikolla proposed openstack/keystone master: Move driver loading inside of dict
cburgessnotmorgan Thanks... my znc bouncer got horked up some how.22:49
notmorgancburgess: use weechat22:51
notmorgancburgess: or irccloud. :P22:51
cburgessnotmorgan Is that what all the cool kids use now?22:52
notmorganeh. most cool kids don't use IRC. you must have us confused with some other group of people :P22:53
*** ravelar has joined #openstack-keystone22:55
dstanekmwheckmann: it depends of what you are trying to get to work23:01
dstanekmwheckmann: from your comment on the bug it looks like neutron isn't quite working properly. you may want to submit you patch to them through gerrit23:04
mwheckmanndstanek: ok. I will do that. What about my first comment though? About keystone not setting the "is_admin_project" for domain scoped tokens23:06
dstanekmwheckmann: i believe that should be set when you have a token scoped to a project and that project is the admin project. is that not happening for you?23:12
mwheckmannthat is happening, but the problem is if I present a domain scoped token. I get full admin rights on certain projects because "is_admin_project" is not set and it defaults to True for legacy support. It's basically a security hole.23:13
mwheckmannThere was a patch for that in Keystone (Token model class) but that function never seems to get called.23:14
mwheckmannI have to go pick up my daughter... I can continue talking about it tomorrow.. sorry.23:15
dstanekmwheckmann: sure, np23:15
*** adrian_otto has quit IRC23:16
*** mwheckmann has left #openstack-keystone23:16
*** thorst has joined #openstack-keystone23:17
*** thorst has quit IRC23:19
*** lucasxu has quit IRC23:22
*** ngupta has joined #openstack-keystone23:23
*** erlon has quit IRC23:25
*** adrian_otto has joined #openstack-keystone23:32
*** MasterOfBugs has quit IRC23:32
*** MasterOfBugs has joined #openstack-keystone23:33
*** jamielennox is now known as jamielennox|away23:37
*** MasterOfBugs has quit IRC23:38
*** _cjones_ has joined #openstack-keystone23:55
*** _cjones_ has quit IRC23:55
*** _cjones_ has joined #openstack-keystone23:55
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements

Generated by 2.14.0 by Marius Gedminas - find it at!