17:01:56 #startmeeting keystone-office-hours 17:01:57 Meeting started Tue Jul 3 17:01:56 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:01 The meeting name has been set to 'keystone_office_hours' 17:11:19 Morgan Fainberg proposed openstack/keystone master: Make keystone.server.flask more interesting for importing https://review.openstack.org/579928 17:14:17 Morgan Fainberg proposed openstack/keystone master: Fix keystone.common.rbac_enforcer.__init__.py expoorting https://review.openstack.org/579930 17:19:15 Morgan Fainberg proposed openstack/keystone master: Fix keystone.common.rbac_enforcer.__init__.py exporting https://review.openstack.org/579930 20:15:38 kmalloc: i worked my way through all flask patches i think 20:42:12 lbragstad: responded to comments 20:42:26 lbragstad: specificall the one you -1'd. That is just a double down on policy-in-code 20:42:44 lbragstad: if a rule isn't defined, we are locked down, it's a safety concern within keystone. 20:43:02 for security projects (we are one), default closed, open where needed 20:43:18 i agree about the concern, more or less questioning the backwards compatibility bit? 20:43:36 i don't think it's backwards incompat 20:43:49 there is zero reason we have un-accounted for rules with policy-in-code 20:43:55 or if we do, we should know about it fast 20:45:04 if we want to reference an action, ensure it is registered 20:45:37 prior to policy-in-code, the "default open" or "Default closed" was a more reasonable thing to reference 20:46:11 since the definition of the policy itself was in the policy.json 20:46:32 so, there was a high likelihood of a non-existant action 20:46:44 with policy-in-code it is impossible (short of a programming error) for a non-existent action 20:47:07 (an operator can no longer remove an action from policy.json causing a fallback to the default rule) 20:55:55 Morgan Fainberg proposed openstack/keystone master: Do not use flask.g imported as g https://review.openstack.org/579985 20:59:58 lbragstad, knikolla, wxy: ^ 21:11:05 Lance Bragstad proposed openstack/oslo.policy master: Teach Enforcer.enforce to deal with context objects https://review.openstack.org/578995 21:38:59 wow this mfa stuff is just completely undocumented http://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/resource_options.py#n85 21:39:08 you have to hunt through the code to find out it's there 21:44:04 yeah - outside of the original patch, i'm not sure the docs were ever amended https://review.openstack.org/#/c/274901/ 23:32:36 cmurphy: nope, not at all. It doesn't exists outside of the circle of people who know it from the code :P 23:33:27 Which honestly is a good thing until we get the auth receipts done, because using it as is was messy anyway 01:19:26 wangxiyuan proposed openstack/keystone master: Delete project limits when deleting project https://review.openstack.org/538371 01:37:55 Yeah :( 03:20:16 wangxiyuan proposed openstack/keystone master: Implement enforcement model logic in Manager https://review.openstack.org/562715 03:20:16 wangxiyuan proposed openstack/keystone master: Expose endpoint to return enforcement model https://review.openstack.org/562716 03:20:17 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 03:20:17 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 03:20:18 wangxiyuan proposed openstack/keystone master: [WIP] Add show hierarchy filter https://review.openstack.org/579331 05:22:57 Merged openstack/keystone master: Add registered_limit_id column for limit https://review.openstack.org/577751 05:36:28 Kristi Nikolla proposed openstack/keystone-tempest-plugin master: Keystone to Keystone tests https://review.openstack.org/580041 05:38:03 i should be sleeping now, why am i pushing code 06:51:35 lbragstad: Thank you very much 07:30:06 Hi hello.. 07:30:41 i have created a group in keystone. 07:30:53 and using that group to rote the keys.. 07:31:03 but it throws below error.. 07:31:08 ValueError: Unknown group 'new' in --keystone-group 07:31:19 new -- group name i have created.. 07:31:36 can anyone point me what is the issue.. 07:34:28 vigneshwar: are you using keystone-manage xx_rotate command? 07:38:13 If so, the "--keystone-group" here does not mean the group resource in Keystone, it means the linux group which the keystone process runs with. the same as "--keystone-user" 08:58:57 wxy: i tried with the same as user , still it is throwing same issue 09:00:24 actually i am just using keystone-manage fernet_setup command,, 09:00:39 which is not helpful..returning none.. 09:00:58 so checked the log , it throws "ValueError: Unknown group 'new' in --keystone-group" 09:08:05 vigneshwar: http://paste.openstack.org/show/724962/ 09:30:43 wxy : thank you very much 09:36:48 wangxiyuan proposed openstack/keystone master: Implement enforcement model logic in Manager https://review.openstack.org/562715 09:36:49 wangxiyuan proposed openstack/keystone master: Expose endpoint to return enforcement model https://review.openstack.org/562716 09:36:49 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 09:36:50 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 09:36:50 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 09:36:53 vigneshwar: :) 12:45:23 Pavlo Shchelokovskyy proposed openstack/keystone master: Ignore .eggs dir as well https://review.openstack.org/580154 13:41:59 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 13:42:11 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 13:42:22 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 14:07:02 Stephen Finucane proposed openstack/keystone master: Replace support matrix ext with common library https://review.openstack.org/527808 18:04:50 Merged openstack/keystone master: Ignore .eggs dir as well https://review.openstack.org/580154 03:20:46 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 03:20:46 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 03:20:47 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 03:20:47 wangxiyuan proposed openstack/keystone master: [WIP]Update project depth check https://review.openstack.org/580258 06:55:42 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 06:55:43 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 06:55:43 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 06:55:44 wangxiyuan proposed openstack/keystone master: Update project depth check https://review.openstack.org/580258 07:27:29 Adrian Turjak proposed openstack/keystone master: Implement auth receipts spec https://review.openstack.org/572286 09:14:16 Adrian Turjak proposed openstack/keystone master: Implement auth receipts spec https://review.openstack.org/572286 09:22:57 Adrian Turjak proposed openstack/keystone master: Implement auth receipts spec https://review.openstack.org/572286 09:33:34 wangxiyuan proposed openstack/keystone master: [WIP]Add project hierarchical tree check when Keystone start https://review.openstack.org/580331 12:30:26 wangxiyuan proposed openstack/keystone master: Add project hierarchical tree check when Keystone start https://review.openstack.org/580331 12:44:00 o/ 14:25:07 o/ 14:36:44 riddle me this, 14:36:59 we're debating in #openstack-placement that keystone project/user ids have to be uuids or not 14:37:04 i didn't think they had to be uuids 14:43:30 Anyone interested in co-presenting at the Summit? I have an idea for a talk. Tentatice title "Pushing Keystone over the Edge" on dealing with the multi-site issues 14:43:43 mriedem, define "have to" 14:44:01 I made them work as DNs back in early LDAP days, but that is yucky 14:44:13 we assign UUIDs or things that look like them to Federated Ids that come in 14:44:26 I wanted them to be sha256 hashes, which are longer 14:45:37 Kristi Nikolla proposed openstack/keystone master: Copy shibboleth logs in v3 functional jobs https://review.openstack.org/580401 14:46:49 Kristi Nikolla proposed openstack/keystone-tempest-plugin master: Keystone to Keystone tests https://review.openstack.org/580041 14:51:07 ayoung: is it safe to assume that project and user ids in openstack are UUIDs 14:51:19 or can they be other things based on how the deployment is configured 14:51:32 because a few years ago sdague asserted they don't have to be uuids and some deployments didn't make them uuids 14:51:53 or they encoded domain-specific things in the project id for some deployments 14:55:50 mriedem: for projects, unless they are using their own custom made driver, yes. for users, not. ldap users don't have UUIDs. 14:56:05 bf97c38af9e3a2db2f63190683180b138c57f393a2ebea70287698e1fc427072 | demo 15:04:48 knikolla: ack thanks 15:13:09 Kristi Nikolla proposed openstack/keystonemiddleware master: Document endpoint interface and region behavior https://review.openstack.org/505396 15:13:29 Kristi Nikolla proposed openstack/keystonemiddleware master: Document endpoint interface and region behavior https://review.openstack.org/505396 15:18:38 Kristi Nikolla proposed openstack/keystone master: Only upload SP metadata to testshib.org if IDP id is testshib https://review.openstack.org/545471 15:41:59 Hi, I am having an issue with Keystone and LDAP, is anyone around who could give me a few pointers? When active directory users are authenticating through keystone we are getting a 504 timeout. tracing through the logs it looks like it is authenticating against ldap but the clients receive a "ConnectFailure: Unable to establish connection to https://openstack.nubes.rl.ac.uk:5000/v3/auth/tokens: ('Connection aborted.', 15:41:59 BadStatusLine("''",))" 16:38:36 Stephen Finucane proposed openstack/keystone master: Replace support matrix ext with common library https://review.openstack.org/527808 18:13:16 Hello! 18:13:56 I'm trying to configure Keystone as a SP using a third-party IdP 18:15:02 but when horizon redirects to the OS-FEDERATION url, keystone logs tht it's "missing entity ID from environment" 18:16:01 I'm having trouble understanding exactly how to tell keystone the ID of the entity I want to use... has anyone had such issue? 18:26:32 nicodemus_: that error could have a lot of different causes but the gist is that horizon is trying to redirect to a keystone federation endpoint but it's failing to go through the apache saml mod which means it's failing to set the right headers in the apache request 18:26:47 the first thing to check is that remote_id_attribute is set correctly in keystone.conf 18:27:03 the next thing is to look at the directives in the vhost and make sure they're correct 18:27:26 and then also check that the OPENSTACK_KEYSTONE_URL in horizon's local_settings.py is correct 18:34:47 cmurphy: so when horizon does the redirect to keystone, the request should contain a specific header telling keystone which identity-provider to use? Is that correct? 18:36:36 nicodemus_: not exactly, when horizon does the redirect to keystone it should be redirecting to one of the paths protected by directives in the apache vhost, and the apache mod will set the needed headers before passing it on to keystone 18:37:51 I see. I've configured the remote_id_attribute in keystone.conf as per https://docs.openstack.org/keystone/pike/advanced-topics/federation/federated_identity.html (I'm using mellon, so the attribute is set to MELLON_IDP) 18:39:12 but it's unclear the effect that variable would have 18:42:05 that setting just tells keystone how to process the data that apache is passing to it 18:43:40 if you're using mellon then you should have some pieces in your keystone vhost that look something like this http://paste.openstack.org/show/725136/ 18:44:44 but the paths need to match the routes you're actually using, for example you may or may not have your keystone using a /identity endpoint and you need to make sure the idp and protocol parts of the path match what you configured 18:47:09 I see... so the stanza shouldn't have the MellonSPPrivateKeyFile directives? Those I've configured in the section 18:49:19 nicodemus_: no those are correct to have there, for example this has worked for me in the past http://paste.openstack.org/show/725137/ 18:49:44 sorry i just clipped it out because that's usually not the tricky part 18:55:06 thanks cmurphy ! That's quite helpful 18:55:33 much obliged 18:55:50 you're welcome, hope you work it out 19:29:55 cmurphy: let me ask you yet another question (that might be obvious) 19:30:40 in the last paste, there's a that goes on the vhost conf on keystone, and another that goes on the horizon vhost? 19:31:52 nicodemus_: no, sorry that comment is misleading, they're all for keystone 19:32:04 oh, ok 19:32:44 so horizon simply does a redirect, and all the mellon magic happens in keystone 19:33:38 do you by any chance know which header would mellon include in the header? I'm trying to validate if mellon is in fact doing something or not 19:36:18 nicodemus_: I think it will literally be 'MELLON_IDP', and if it's working properly you should be able to see it in the keystone debug logs 19:37:23 Got it. Thanks again !! 19:37:37 np 20:59:31 Kristi Nikolla proposed openstack/keystone master: Copy shibboleth logs in v3 functional jobs https://review.openstack.org/580401 21:06:25 cmurphy: I'm making progress! But still have another doubt regarding the traffic flow 21:07:24 I'm being redirected to the SAML host for login, but after using valid credentials there's a "bad request" page waiting for me. 21:07:46 Once the SAML host receives the credencials, it is supposed to do a callback to horizon, or to keystone? 21:11:04 nicodemus_: i have a diagram for you http://www.gazlene.net/demystifying-keystone-federation.html#websso-with-keystone-and-horizon 21:11:13 it should call back to keystone at that point 21:11:35 Wonderful! Many thanks !! 21:11:37 is the bad request coming from keystone? or horizon? or the idp? 21:11:43 It's clear 21:12:03 it comes from keystone 21:12:31 if you turn on insecure_debug = true in keystone.conf it should give you a clear error message of what went wrong 21:16:34 I see that I have an encrypted SAML response, but when it's POSTed to keystone on an URL that ends with 'auth/mellon/postResponse' I get the 400 error - bad request. Perhaps Keystone isn't able to decrypt the response? 21:19:07 it should be able to decrypt it because exchanging the service provider's public key with the identity provider is part of uploading its metadata 21:20:43 Perhaps if the user that configures the IdP didn't configure my metadata properly, I should expect a 400 error 21:20:55 (I didn't mention that I'm not configuring the IdP) 21:22:15 you might try setting it up with testshib.org and if you can get that working then you can compare to your idp 21:23:24 the regular apache logs might have more information on mellon-specific errors if the keystone logs don't have anything 21:23:39 certanly, there's an error in the apache logs 21:24:04 http://paste.openstack.org/show/725149/ 21:27:01 hmm I've never seen that one, but https://github.com/UNINETT/mod_auth_mellon/issues/112 seems to indicate that something might be wrong in the MellonIdPMetadataFile file 21:27:16 Looks like it 21:30:10 Do you know if the 'MellonIdP' value in the apache vhost for keystone should be the entityID from the metadata of the IdP? 21:34:04 I don't think so, I just use "IDP". From the docs I think it's setting the name of the header, as in MELLON_IDP 21:34:40 it's the name of the header that will have the entityID as its value 22:17:07 cmurphy: you still about? 23:03:43 * kmalloc tries to vacation... keeps looking at code 23:07:27 kmalloc: I was home sick yesterday... still followed up on code review 23:09:30 Trying to keep away from work when stuff is a little time sensitive is hard, and also work/life balance is a thing so many people suck at! 23:40:26 Morgan Fainberg proposed openstack/keystone master: Flesh out and add testing for flask_RESTful scaffolding https://review.openstack.org/578190 23:40:36 Morgan Fainberg proposed openstack/keystone master: Make keystone.server.flask more interesting for importing https://review.openstack.org/579928 23:40:41 Morgan Fainberg proposed openstack/keystone master: Fix keystone.common.rbac_enforcer.__init__.py exporting https://review.openstack.org/579930 23:40:49 Morgan Fainberg proposed openstack/keystone master: Do not use flask.g imported as g https://review.openstack.org/579985 00:05:37 adriant: hm. that is one massive patchset 00:06:04 kmalloc: the auth receipts one? 00:06:06 adriant: not sure if it could have been broken up, but (as guilty as I am of 1000+ line changes right now), that is a lot to review at once. 00:06:07 yeah 00:06:23 I mean, I could break the provider logic and tests into one patch 00:06:33 that might make it a lot easier to review 00:06:39 at 2000+ lines of change 00:06:41 then add the auth controller logic and tests in another 00:06:47 THEN the docs 00:06:49 yeah and i would prob add the docs in the final one 00:07:07 if you don't mind, i mean, I'll review it if that is too much work (as is) 00:07:22 but it also means that if one bit changes you can keep it somewhat isolated. 00:07:44 i tried to do a lot of that wiht flask code, but sometimes you still end up with 500LOC and 500 lines of test. 00:09:43 I don't think it will be too hard to split them... 00:10:01 * adriant says tentatively 00:10:40 although the provider patch will still be large 00:10:44 since that's the bulk of it 00:11:56 yeah, the provider logic (plus conf, plus cli) and tests still looks to be around 1500-2000 LOC 00:13:52 docs I can easily split out, and I think doing that is probably not a bad idea, since I can tackle the docs in one or two patch for MFA as a whole, and those aren't exactly going to be a feature freeze issue, so safer to cut those out of the patch that is time sensitive 00:35:06 kmalloc: I'll split the docs out, but I'm not sure how else to split the rest nicely when there is a bit of overlap, and most of the controller logic is tiny anyway.' 01:30:37 Adrian Turjak proposed openstack/keystone master: Implement auth receipts spec https://review.openstack.org/572286 01:30:38 Adrian Turjak proposed openstack/keystone master: [WIP] Add documentation for Auth Receipts and MFA https://review.openstack.org/580535 01:31:52 kmalloc: I've cut the doc changes out at least, but I think I'll leave the giant patch as is other wise :/ 01:51:36 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 01:51:36 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 01:51:37 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 01:51:37 wangxiyuan proposed openstack/keystone master: Update project depth check https://review.openstack.org/580258 01:51:38 wangxiyuan proposed openstack/keystone master: [WIP]Add project hierarchical tree check when Keystone start https://review.openstack.org/580331 02:41:19 Tuan Do Anh proposed openstack/keystone master: Change "a SQL" to "an SQL" https://review.openstack.org/579432 02:41:27 Morgan Fainberg proposed openstack/keystone master: Flesh out and add testing for flask_RESTful scaffolding https://review.openstack.org/578190 02:43:27 Morgan Fainberg proposed openstack/keystone master: Make keystone.server.flask more interesting for importing https://review.openstack.org/579928 02:43:33 Morgan Fainberg proposed openstack/keystone master: Fix keystone.common.rbac_enforcer.__init__.py exporting https://review.openstack.org/579930 02:43:39 Morgan Fainberg proposed openstack/keystone master: Do not use flask.g imported as g https://review.openstack.org/579985 02:43:47 o 02:43:48 ok 04:28:02 Kristi Nikolla proposed openstack/keystone master: Fix keystone-manage saml_idp_metadata under python3 https://review.openstack.org/580553 04:29:47 Kristi Nikolla proposed openstack/keystone master: Added keystone identity provider installation to Devstack plugin https://review.openstack.org/484121 04:30:51 Kristi Nikolla proposed openstack/keystone-tempest-plugin master: Keystone to Keystone tests https://review.openstack.org/580041 04:32:31 it's too hot to sleep :/ 05:48:51 adriant: sorry I was asleep 06:57:32 wangxiyuan proposed openstack/keystone master: Add project hierarchical tree check when Keystone start https://review.openstack.org/580331 09:26:13 wangxiyuan proposed openstack/keystone master: Remove enable config option of trust feature https://review.openstack.org/580587 09:33:32 Gergely Csatari proposed openstack/keystone master: Clarifications to API & Scenario Tests https://review.openstack.org/580589 13:42:27 wangxiyuan proposed openstack/keystone master: Remove enable config option of trust feature https://review.openstack.org/580587 14:00:55 o/ 14:44:30 Morning! 14:47:16 I'm trying to configure Keystone federation, with keystone as an SP and an external IdP. I'm using Mellon for handling the SAML part, but have an error: http://paste.openstack.org/show/725267/ 14:47:32 Has anyone seen such error before? 16:31:50 nicodemus_: have you created an identity provider in keystone? 16:50:07 larsks: I did 16:50:23 but it turned out that the callback was failing 16:50:28 Well, that's everything I know about federation :) 16:51:07 rule of thumb, use the same path for the single sign on as in the Mellon endpoint 16:51:35 I've recently been tacking openid federation in tripleo and the keystone puppet module. Mellon is next on my list... 16:51:41 s/tacking/tackling/ 18:09:24 adriant: i left a bunch of comments on the receipt patch 18:09:53 adriant: i skipped reviewing the tests for now. they looked ok-ish, but there are some other changes I'd like to see that may impact the tests. 23:15:55 Gage Hugo proposed openstack/keystone master: Expose random uuid bug in cadf notifications https://review.openstack.org/580780 01:53:49 Gage Hugo proposed openstack/keystone master: Expose random uuid bug in cadf notifications https://review.openstack.org/580780 08:14:30 wangxiyuan proposed openstack/keystone master: Remove enable config option of trust feature https://review.openstack.org/580587 08:50:14 Gergely Csatari proposed openstack/keystone master: Clarifications to API & Scenario Tests https://review.openstack.org/580589 12:41:36 o/ 12:49:46 o/ 12:58:47 Gergely Csatari proposed openstack/keystone master: Clarifications to API & Scenario Tests https://review.openstack.org/580589 13:03:54 Hi, I tried to use kuryr-kubernetes on openstack and I have trouble with keystoneauth1 that I don't understand. 13:04:30 I have a config file with the following keystone url https://keystone.lal.in2p3.fr:5000/v3 13:05:52 When kuryr tries to create a keystone clien I have an error which tells me that it is not possible to connect to the url https://keystone-admin.lal.in2p3.fr:35357/v3 13:06:24 I don't understand why the url is not unchanged 13:09:03 Note that I can create subnet, ... using neutron cli 14:07:39 o/ 14:07:46 morning 14:12:56 Mornin 14:17:19 lbragstad: we need to stop using exception.NotImplemented() for abstract base classes 14:17:42 kmalloc: and just replace it with pass? 14:17:43 An http NotImplemented is different than what we are using it for 14:17:45 No. 14:17:54 Raise NotImplementedError() 14:18:36 Http not implemented indicates GET or PUT isn't implemented, NotImplementedError is saying "Python code isn't implemented" 14:18:47 ahh 14:18:56 A plain 500 rather than 501 14:19:13 This is the only case a 500 should be expected in code :) 14:19:16 it does seem slightly confusing... 14:19:24 Yeah. 14:19:35 since the python code is what's implementing the GET/PUT/etc... 14:20:34 Right, in the cases we don't have a put/post etc, 501 is fine 14:20:35 would it make a different to someone consuming those APIs? 14:20:55 But most of these cases we have a put/post/etc and someone failed to write code. 14:21:25 what's a case where we wouldn't have a PUT/POST/GET/DELETE and should return a 501? 14:21:26 (except they didn't because abc, but we did it elsewhere and let it bubble up) 14:21:42 The API spec doesn't implemnt post 14:21:50 The API is a get/head only. 14:22:04 * lbragstad thought that was always a 404 14:22:19 but maybe that's wrong 14:22:44 That is probably wrong. 14:22:55 it's that how we treat it today? 14:23:00 Some cases. 14:23:05 We are inconsistent. 14:23:23 But the easiest is never raise a 501. 14:23:34 That is more correct than we do today. 14:23:43 Esp. in say, read-only backends. 14:24:23 Read-only backends (catalog) raise 501 on write ops.. 14:24:43 Not a huge deal, just a "hey, this is wrong" and we should be aware of it. 14:24:56 we should probably write this down in a bug report 14:24:57 Other things I found when doing flask things. 14:25:14 i assume flask makes this type of stuff easier to adhere to 14:25:14 Yeah. On mobile till post coffee. Can write it down after. 14:25:18 Yep. 14:25:21 sounds good, thanks 14:25:45 Flask restful, if we don't implement a get/post/put/whatever method, it 501s. 14:25:53 Built in. :) 14:28:34 Also, need to circle up on the policy passthrough, I think we solved the whole reason to support "unknown" rules (passthrough or fail) when we went to in-code. Someone can no longer remove a line from the policy.json and force a fall-through to the default rule by accident, we fall back on the default in code now. 14:29:34 Previous to in-code, removing a line from policy.json meant the enforcement action was unknown, and the default "pass/deny" is used. With in-code, an action is never unknown. 14:29:46 As it has a default registered.. 15:09:59 Hello. I'm facing an issue regarding cache and inherited roles, and I'd like to know if someone already experienced it. I have a role assigned to a user on a domain, with the flag inherited (and also without). When I create a new project in this domain, I expect the role to be assigned on this project, so that when I list the project, I can see the new one created. However, the cache is not disabled, and listing I can't find the new project 15:09:59 until the cache is expired. I triedwhile disabling the role cache, it works directly. Anyone experienced it ? Is it bug material ?? 15:15:38 kimamisa: it sounds like the project cache needs to be invalidated when the inherited role assignment happens 15:15:49 kimamisa: does that sound coorect? 15:16:37 lbragstad: well, the role assignment happened before the project creation in my case 15:17:09 oh - so the project creation should invalidate the cache then? 15:17:16 what release are you using? 15:17:38 lbragstad: I think the role cache should be invalidated when a new project is created AND there are inherited role in the domain 15:18:37 I'm on queens 15:19:04 kimamisa: if you'd like to write down that steps you took to recreate in a bug report, you can do that here https://bugs.launchpad.net/keystone/+filebug 15:22:25 lbragstad: ok. I wanted to check that I wasn't doing anything impossible before reporting a bug. Thanks 15:22:52 kimamisa: no problem, we can continue to investigate in the bug report 15:42:04 lbragstad: launchpad found an old bug which points to one of your comments: https://bugs.launchpad.net/keystone/+bug/1780159 15:42:04 Launchpad bug 1780159 in OpenStack Identity (keystone) "Some inherited projects missing when listing user's projects" [Undecided,Invalid] 15:44:15 the bug is exactly what I'm facing. Do you think there is any hope in improving this ? 15:50:48 kimamisa: hmmmm 15:51:18 ayoung: is there a reason to not keep https://bugs.launchpad.net/keystone/+bug/1780159 open? 15:51:18 Launchpad bug 1780159 in OpenStack Identity (keystone) "Some inherited projects missing when listing user's projects" [Undecided,Invalid] 15:51:38 lbragstad, it was a cache problem 15:51:46 right 15:52:10 we don't invalidate the cache in certain inherited role assignment cases 15:52:12 so, cache is going to introduce delay. 15:52:38 ah...you think it should be cache invalidation...ok, keep it open 15:53:03 restored it to the "new" state 15:53:24 we could go either way with it... but dealing with the invalidation directly is a pattern we have in other places 15:53:46 kimamisa: in that case, we can reuse that report, can't we? 15:53:57 yes 15:54:36 I almost had the same ready ! 15:54:49 cool - setting to medium since the workaround is to set low cache TTL for that specific subsystem 15:55:02 ayoung: thanks for working that report 16:09:26 Can someone explain K2K to me? 16:09:37 I get SAML. WHat I don't get is how it keeps assignment data straight 16:09:55 say I have 2 setups, call em old and new 16:10:22 and I add a project to old. How does that show up as anything in new without making a direct call to new to create the project? 16:10:58 Merged openstack/keystone-tempest-plugin master: fix tox python3 overrides https://review.openstack.org/573862 16:11:39 if I want to have a rule that says "anything in old Dom 1 gets mirrored in new Dom 5" there is nothing that keeps people also from assigning to things in new dom 5. Fine, I get that 16:12:44 what makes the new Dom 5 project in the first place, or is it just assumed that you will start with some top level sync, like "let old and new each get a set of domains, and we'll explicitly create projects in the remote ones" so using a domain level assiugnment? 16:31:54 Merged openstack/keystone master: Clarifications to API & Scenario Tests https://review.openstack.org/580589 16:45:46 Lance Bragstad proposed openstack/oslo.policy master: Teach Enforcer.enforce to deal with context objects https://review.openstack.org/578995 16:47:05 Lance Bragstad proposed openstack/oslo.policy master: Teach Enforcer.enforce to deal with context objects https://review.openstack.org/578995 19:24:56 Gage Hugo proposed openstack/keystone master: Add docs for case-insensitivity in keystone https://review.openstack.org/576640 20:38:45 kmalloc: might need your eyes on the policy bits here and the @protected stuff https://review.openstack.org/#/c/579330/8/keystone/limit/controllers.py 20:39:02 context: https://review.openstack.org/#/c/579330/2/keystone/limit/controllers.py 20:39:39 Headed to the doctor, will look when back. 20:39:44 ack 20:39:53 But #1 priority on my list. 20:40:05 Post non-code things. 20:40:07 :) 20:42:55 awesome - thanks 00:17:43 anyone know what this error means when syncing config to db in pike : InvalidDomainConfig: Invalid domain specific configuration: The value of group signing specified in the config should be a dictionary of options. 00:21:22 this is the config I;m trying to sync to db: http://paste.openstack.org/show/725379/ 01:04:44 lbragstad: looking now 01:04:50 lbragstad: just got back from appt... 01:18:00 lbragstad, wxy: sorry -1, we cannot hard-code role names. The answer is (any option works): 1) Prohibit Filtering on project_id; 2) check service-token only (mostly insufficient as anyone can provide a service token; 3) use callback and make your own cred/target dict that can confirm "project_id" filter is there (pass directly to the enforcer); 4) Wait for oslo_policy and new check types (Stein release); 5) Maybe 01:18:00 doable via backflips i can add in Flask-RBAC Enforcer. 01:39:27 kmalloc: given the refactor work in progress for tokens, I'm tempted to push the auth receipt stuff to Stein until the refactor is done for tokens. Then I can sync up with what we end up with so the receipt and token patterns are the same. 01:41:29 None of the other pieces for MFA with receipts would be ready until Stein anyway, so it's not a huge issue, and now that I have something that works with the API side mostly defined I can start the work in keystoneauth + elsewhere so it's ready once auth receipts is merged into master during Stein 01:43:24 Wfm 01:43:42 lbragstad: that work for you? I've started working through all your token provider refactors, and once those are close to done can sync my stuff with them. 01:44:19 kmalloc: seems like the most sensible solution rather than me inventing a third pattern for auth receipts when it should really match tokens. 01:45:12 ++ 02:05:49 kmalloc: ++ for the policy enforcer way. I tried it in my first patch, but it doesn't work as I thought. So I really like your proposal during last weekly meeting. I want to wait for new oslo_policy, but without "project_id" filter, the "show_hierarchy" filter will be blocked as well (https://review.openstack.org/#/c/579331/8/keystone/limit/core.py@131). So I'd like choose 2) in R, and continue 4) in S. 02:06:18 Sounds good. 02:07:11 The only reason I could build the enforcer (custom) is because I've just been working heavily in the enforcer ;) 02:08:12 I might make this doable with moving to flask. 02:08:36 FYI, but need to land the bits before I move apis to flask. 02:08:46 kmalloc: I'll dig into your flask-enforcer patches today. 02:09:06 It's mostly ready, just needs some extra +2s 03:18:40 wxy: we might need a separate api for security reasons if the reason we limit project_id filter is security 03:19:01 wxy: because anyone could provide a service token, it just wont be useful for other service-only things 03:19:13 wxy: lets chat w/ lbragstad tomorrow and come to a good solution :) 03:24:59 Adrian Turjak proposed openstack/keystone master: Implement auth receipts spec https://review.openstack.org/572286 03:25:17 kmalloc: then a new policy like "limit_limits_with_project_id: role: admin or service"?. I thought it's a little heave so I dropped this choice when coding. But I'm ok with it if we like it. 03:38:32 kmalloc, lbragstad: auth receipts marked as -1 workflow for now then, and I've added myself to all reviews for https://bugs.launchpad.net/keystone/+bug/1778945 so I can keep an eye on how they shape up, will at some stage start work on KeystoneAuth using the existing auth-receipts patch as the API interaction is unlikely to change. 03:38:32 Launchpad bug 1778945 in OpenStack Identity (keystone) "Complexity in token provider APIs" [Medium,In progress] - Assigned to Lance Bragstad (lbragstad) 03:39:02 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 03:39:02 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 03:39:03 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 03:39:03 wangxiyuan proposed openstack/keystone master: Update project depth check https://review.openstack.org/580258 03:39:04 wangxiyuan proposed openstack/keystone master: Add project hierarchical tree check when Keystone start https://review.openstack.org/580331 03:39:04 wangxiyuan proposed openstack/keystone master: Filter project_id for list limits https://review.openstack.org/581177 03:39:42 adriant: ok 03:40:18 wxy: yeah, let's chat tomorrow. But that might be the path forward, but I want to check a couple things. 03:40:26 I have some ideas. 03:40:33 kmalloc: cool 04:08:37 adriant: ok - that sounds fine 04:08:53 to be fair - the rest of that refactor shouldn't take too long 04:09:07 it's just a bit of testing concerns and that should be about it 04:25:30 wxy: did you say you were waiting for a new version of oslo.policy? 05:07:53 lbragstad: the "does element in Target dict" check I proposed n 05:08:02 Right now we can't do that at all. 05:12:01 ah 05:12:56 it could be done with a callback or custom call to enforce 05:13:04 it would be wonky/difficult 05:13:13 flask work makes it easier, but not "easy" 05:13:26 a "does element exist in target" would make a big difference 06:35:29 Vu Cong Tuan proposed openstack/python-keystoneclient master: Switch to stestr https://review.openstack.org/581213 07:23:11 Vu Cong Tuan proposed openstack/pycadf master: Switch to stestr https://review.openstack.org/581228 07:32:53 wangxiyuan proposed openstack/keystone master: Strict two level limit model https://review.openstack.org/557696 07:32:54 wangxiyuan proposed openstack/keystone master: Add project_id filter for listing limit https://review.openstack.org/579330 07:32:54 wangxiyuan proposed openstack/keystone master: Add show hierarchy filter https://review.openstack.org/579331 07:32:55 wangxiyuan proposed openstack/keystone master: Update project depth check https://review.openstack.org/580258 07:32:55 wangxiyuan proposed openstack/keystone master: Add project hierarchical tree check when Keystone start https://review.openstack.org/580331 07:37:22 lbragstad: yes if oslo.policy can check the request filter in policy way like kmalloc mentioned during last weekly meeting. But we can't just wait, we should find another solution in R. 08:37:23 Vu Cong Tuan proposed openstack/python-keystoneclient master: Switch to stestr https://review.openstack.org/581213 09:34:14 Merged openstack/keystone master: Implement enforcement model logic in Manager https://review.openstack.org/562715 10:14:56 Vu Cong Tuan proposed openstack/ldappool master: Switch to stestr https://review.openstack.org/581307 11:23:28 Vu Cong Tuan proposed openstack/keystone-specs master: Switch to stestr https://review.openstack.org/581326 11:36:10 Vu Cong Tuan proposed openstack/keystone-specs master: Switch to stestr https://review.openstack.org/581326 12:29:26 Sami Makki proposed openstack/keystone master: Invalidate 'computed assignments' cache when creating or deleting project. https://review.openstack.org/581346 14:56:32 wxy: interesting. 14:57:21 wxy: so i think the best plan is a service API that is locked to a better rule for filtering by project_id. 14:57:32 wxy: rather than a list interface. 14:57:44 wxy: that way we have a separate action that can be controlled. 14:57:59 wxy: i slept on the whole design and the "change behavior based upon filter" seems weird. 14:58:03 lbragstad: ^ cc 14:58:49