kmalloc | mgagne: no problem! happy to help | 00:43 |
---|---|---|
openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Emit CADF notifications on authentication for invalid users https://review.openstack.org/613455 | 00:48 |
*** itlinux has joined #openstack-keystone | 00:49 | |
openstackgerrit | Merged openstack/keystoneauth master: Add missing release note for ironic discovery fix https://review.openstack.org/612872 | 01:36 |
*** lbragstad has quit IRC | 01:49 | |
*** lbragstad has joined #openstack-keystone | 01:49 | |
*** ChanServ sets mode: +o lbragstad | 01:49 | |
*** rcernin has joined #openstack-keystone | 01:55 | |
*** Dinesh_Bhor has joined #openstack-keystone | 01:55 | |
openstackgerrit | Merged openstack/keystone master: Update keystone-manage bootstrap port instructions https://review.openstack.org/613163 | 02:26 |
openstackgerrit | Merged openstack/keystone master: Fix api-ref v3.9 release identifier https://review.openstack.org/613257 | 02:26 |
openstackgerrit | Vishakha Agarwal proposed openstack/keystone master: Set Default and resource limit as defined schema https://review.openstack.org/610479 | 02:47 |
*** erus has quit IRC | 02:50 | |
*** Dinesh_Bhor has quit IRC | 02:58 | |
*** Dinesh_Bhor has joined #openstack-keystone | 03:06 | |
*** erus has joined #openstack-keystone | 03:21 | |
*** Dinesh_Bhor has quit IRC | 04:11 | |
*** dave-mccowan has quit IRC | 04:14 | |
*** shyamb has joined #openstack-keystone | 05:25 | |
*** Dinesh_Bhor has joined #openstack-keystone | 05:35 | |
*** shyamb has quit IRC | 05:37 | |
*** mchlumsky_ has joined #openstack-keystone | 05:46 | |
*** shyamb has joined #openstack-keystone | 05:47 | |
*** cwright_ has joined #openstack-keystone | 05:51 | |
*** hemna_ has joined #openstack-keystone | 05:54 | |
*** ianw_ has joined #openstack-keystone | 05:54 | |
*** dims_ has joined #openstack-keystone | 05:54 | |
*** mchlumsky has quit IRC | 05:55 | |
*** dims has quit IRC | 05:55 | |
*** hemna has quit IRC | 05:55 | |
*** mattoliverau has quit IRC | 05:55 | |
*** ianw has quit IRC | 05:55 | |
*** cwright has quit IRC | 05:55 | |
*** jlvillal has quit IRC | 05:55 | |
*** ianw_ is now known as ianw | 05:55 | |
*** irclogbot_1 has quit IRC | 05:58 | |
*** shyamb has quit IRC | 06:13 | |
*** shyamb has joined #openstack-keystone | 06:31 | |
openstackgerrit | wangxiyuan proposed openstack/keystone master: Drop unhash password column https://review.openstack.org/613513 | 07:02 |
*** rcernin has quit IRC | 07:22 | |
*** shyamb has quit IRC | 07:28 | |
*** xek has joined #openstack-keystone | 07:35 | |
*** shyamb has joined #openstack-keystone | 07:39 | |
*** Dinesh_Bhor has quit IRC | 07:39 | |
*** shyamb has quit IRC | 08:03 | |
vishakha | cmurphy: Hello. I started installing federation for learning purpose. Have few queries regarding that for now. 1. is federation setup is multi-node or single-node. ? I was looking into the jobs and saw that keystone-dsvm-functional is a single node whereas I have created two VM's installed devstack in each of them. So how do this job works?? | 08:16 |
*** Dinesh_Bhor has joined #openstack-keystone | 08:18 | |
vishakha | cmurphy: 2. I also noticed that keystone.conf is not created by default in /etc/apache2/sites-available?? I created one with the changes mentioned https://docs.openstack.org/keystone/latest/advanced-topics/federation/shibboleth.html#configure-apache-httpd-for-mod-shibboleth. Also enabled it. But apache2 restart failed. | 08:20 |
*** aojea has joined #openstack-keystone | 08:32 | |
*** aojea has quit IRC | 08:36 | |
*** shyamb has joined #openstack-keystone | 09:05 | |
*** sapd1 has quit IRC | 09:25 | |
*** shyamb has quit IRC | 09:43 | |
*** shyamb has joined #openstack-keystone | 10:12 | |
*** shyamb has quit IRC | 10:24 | |
*** dave-mccowan has joined #openstack-keystone | 11:15 | |
*** shyamb has joined #openstack-keystone | 11:15 | |
*** tridde is now known as trident | 11:17 | |
*** Dinesh_Bhor has quit IRC | 11:22 | |
*** erus has quit IRC | 11:48 | |
*** shyamb has quit IRC | 12:12 | |
*** raildo has joined #openstack-keystone | 12:13 | |
cmurphy | vishakha: the federation job uses 1 node because it only needs one node to set up keystone as a service provider and then uses testshib.org as the identity provider | 12:15 |
cmurphy | vishakha: the apache config file will depend on what deployment method you're using, with devstack it will be something like /etc/apache2/sites-available/wsgi-keystone.conf, if you're installing from distro packages it might be something else, if you're installing some other way you might have to create it yourself | 12:16 |
*** shyamb has joined #openstack-keystone | 12:34 | |
openstackgerrit | Juan Antonio Osorio Robles proposed openstack/oslo.policy master: Handle JSON responses in the http and https checks https://review.openstack.org/613570 | 12:43 |
*** shyamb has quit IRC | 12:47 | |
*** dave-mccowan has quit IRC | 13:00 | |
*** pooja_jadhav has quit IRC | 13:14 | |
*** erus has joined #openstack-keystone | 13:30 | |
erus | hi, good morning o/ | 13:30 |
*** cwright_ is now known as cwright | 13:32 | |
*** aojea has joined #openstack-keystone | 13:42 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove deprecated secure_proxy_ssl_header config https://review.openstack.org/499798 | 13:49 |
knikolla | o/ | 13:50 |
knikolla | morning | 13:50 |
*** bnemec has joined #openstack-keystone | 13:54 | |
*** aojea has quit IRC | 14:05 | |
lbragstad | hola | 14:07 |
erus | hola | 14:08 |
erus | I've been checking https://bugs.launchpad.net/keystone/+bugs?field.tag=low-hanging-fruit but not sure how to start | 14:09 |
*** dave-mccowan has joined #openstack-keystone | 14:11 | |
lbragstad | erus is there one in particular that you want to work on? | 14:12 |
*** dave-mccowan has quit IRC | 14:15 | |
erus | maybe this one https://bugs.launchpad.net/keystone/+bug/1698455, but not sure if I could :) | 14:16 |
openstack | Launchpad bug 1698455 in OpenStack Identity (keystone) "Install and configure in Installation Guide: Populate the Identity service database step fails on CentOS7" [Medium,Incomplete] | 14:16 |
lbragstad | erus it looks like that one is still under discussion | 14:22 |
lbragstad | erus are you familiar with the different bug states? | 14:22 |
erus | not really | 14:26 |
lbragstad | no worries - sometimes when you see a bug in Incomplete status, it means we're probably waiting for more information from the reporter | 14:28 |
lbragstad | which could be things like how to recreate the bug, or justification on why this is a keystone-specific issue | 14:28 |
lbragstad | which is what cmurphy is asking about in comment #10 | 14:29 |
lbragstad | when the reporter supplies that information, we can either update the status to be Triaged/Confirmed or Invalid, depending on the feedback | 14:29 |
erus | ohh I see, I thought that incomplete means that need to be completed(?) hehe thanks | 14:31 |
erus | so, I don't know, I want to choose one that fit my knowledge, I mean that I could be able to do it | 14:31 |
lbragstad | this might a tough question to answer since you're new to the project, but are there areas of keystone you feel more comfortable with? | 14:35 |
erus | it's difficult to give you a real answer since it's my first time with keystone and openstack in general | 14:37 |
*** aojea has joined #openstack-keystone | 14:39 | |
lbragstad | that's fine - i was just curious, in that case you could give https://bugs.launchpad.net/keystone/+bug/1698455 a shot by trying to recreate the issue Marcin reported | 14:40 |
openstack | Launchpad bug 1698455 in OpenStack Identity (keystone) "Install and configure in Installation Guide: Populate the Identity service database step fails on CentOS7" [Medium,Incomplete] | 14:40 |
*** aojea has quit IRC | 14:40 | |
*** aojea has joined #openstack-keystone | 14:41 | |
erus | I wanted to try this project because of the identity federation and federation protocols | 14:41 |
erus | and wanted to know more about openstack | 14:41 |
erus | know and learn | 14:41 |
erus | thanks, I will try to recreate it | 14:44 |
*** aojea has quit IRC | 14:45 | |
lbragstad | erus no problem, let us know if you have more questions | 14:48 |
coreycb | hi folks, can I beg for a review of the following? py3 ldap backend is broken and we're trying to use it on queens+: | 14:56 |
coreycb | https://review.openstack.org/#/c/611401 | 14:56 |
coreycb | https://review.openstack.org/#/c/611190 | 14:56 |
coreycb | (note ldapppool needs to land before keystone py36 tests can succeed) | 14:56 |
*** dansmith is now known as SteelyDan | 15:01 | |
openstackgerrit | Merged openstack/keystone master: Delete administrator federation guide https://review.openstack.org/613408 | 15:12 |
*** itlinux has quit IRC | 15:13 | |
openstackgerrit | guang-yee proposed openstack/keystonemiddleware master: Skip the services with no endpoints when parsing service catalog https://review.openstack.org/613410 | 15:14 |
*** gyee has joined #openstack-keystone | 15:23 | |
*** itlinux has joined #openstack-keystone | 15:56 | |
kmalloc | coreycb: +2/+A on ldappool | 15:56 |
coreycb | kmalloc: awesome, thanks. once that lands can we get a new release cut? | 16:00 |
kmalloc | yeah, propose the release review and lbragstad and i will +1 for the release team to push it out | 16:04 |
kmalloc | will be monday at the earliest though, no releases on friday | 16:04 |
openstackgerrit | Merged openstack/ldappool master: PY3: switch to using unicode text values https://review.openstack.org/611401 | 16:08 |
kmalloc | coreycb: ^ should be good to propose the release of ldappool now | 16:12 |
coreycb | kmalloc: ok will do | 16:12 |
*** bnemec is now known as beekneemech | 16:13 | |
coreycb | kmalloc: lbragstad: here you go - https://review.openstack.org/#/c/613632 | 16:21 |
coreycb | i assume that's right, haven't done it before :) | 16:22 |
openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Provide a Location on HTTP 300 https://review.openstack.org/613633 | 16:23 |
kmalloc | looking | 16:23 |
kmalloc | coreycb: go with 2.3.1 and we will need to backport the fix to stable/queens branch (and stable/pike?) | 16:24 |
coreycb | kmalloc: ok yeah was wondering if that would make more sense | 16:24 |
kmalloc | coreycb: i'll comment on the review. | 16:25 |
coreycb | kmalloc: updated | 16:26 |
kmalloc | cool. | 16:26 |
kmalloc | and we might need to / probably will need to cherry-pick to the stable branches... | 16:26 |
kmalloc | depending on what version is used in your version of openstack (can you confirm) | 16:26 |
kmalloc | it might be 2.3.0 | 16:26 |
openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: Add domain scope support for scope types https://review.openstack.org/611443 | 16:27 |
coreycb | kmalloc: yep i have stable/queens going at https://review.openstack.org/#/c/613615. that's enough for us at least. | 16:29 |
kmalloc | lbragstad: the new token model doesn't suffer from this, does it: https://bugs.launchpad.net/keystone/+bug/1652012 | 16:31 |
openstack | Launchpad bug 1652012 in OpenStack Identity (keystone) "token model assumes a token is is_admin_project" [Low,Triaged] | 16:31 |
lbragstad | lemme check | 16:31 |
coreycb | kmalloc: we can always cherry-pick a patch to distro versons too. i'm more concerned with getting upstream reviews before cherry picking to distro. | 16:31 |
kmalloc | right | 16:31 |
kmalloc | but i figure we should be most correct wherever we can be | 16:32 |
kmalloc | lbragstad: or at least that is not an issue because we're moving to scopes | 16:32 |
kmalloc | lbragstad: which might be just worth closing that bug as "wont fix, moving to scope_types instead" | 16:32 |
openstackgerrit | Michael Johnson proposed openstack/keystonemiddleware master: Fix audit target service selection https://review.openstack.org/610099 | 16:33 |
*** dave-mccowan has joined #openstack-keystone | 16:33 | |
lbragstad | yeah - looks like i didn't include that logic in the new model | 16:34 |
lbragstad | https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/render_token.py#n94 | 16:34 |
kmalloc | cool | 16:34 |
lbragstad | but it is in the render_token code | 16:34 |
lbragstad | but it looks completely config driven | 16:34 |
kmalloc | which sounds to me close "invalid" we don't assume this anymore | 16:35 |
lbragstad | i'll update the bug | 16:35 |
* kmalloc is trying to cleanup a many of our bugs as we can | 16:35 | |
kmalloc | guess i'm still on the janitor(tm) job for the next few days | 16:35 |
kmalloc | (more doctor appointments, so can't focus on other things as much) | 16:35 |
lbragstad | sounds good | 16:38 |
lbragstad | https://bugs.launchpad.net/keystone/+bug/1652012/comments/6 | 16:38 |
openstack | Launchpad bug 1652012 in OpenStack Identity (keystone) "token model assumes a token is is_admin_project" [Low,Invalid] | 16:38 |
kmalloc | thnx | 16:39 |
*** dnguyen has joined #openstack-keystone | 16:51 | |
coreycb | kmalloc: i added stable/rocky branch to that review as there currently isn't one for ldappool | 16:57 |
*** dave-mccowan has quit IRC | 16:58 | |
erus | I have a question, git-review is like git fetch? | 17:08 |
*** aojea has joined #openstack-keystone | 17:13 | |
kmalloc | coreycb: thanks | 17:14 |
erus | I mean does it use git fetch internally? | 17:15 |
kmalloc | erus it can do rebasing, but typically it just pushes the data to gerrit | 17:15 |
erus | so it use git push "internally"? | 17:16 |
kmalloc | basically | 17:16 |
kmalloc | i'd have to go look at what it does | 17:16 |
erus | ok ok got it | 17:16 |
kmalloc | to be super sure on how it works, it's been a while since i've written code for git-review itself :) | 17:16 |
erus | and how can I retrieve a change? like git fetch or git pull? | 17:17 |
kmalloc | i use git fetch | 17:17 |
kmalloc | oh you mean from gerrit? | 17:17 |
erus | yep | 17:17 |
*** aojea has quit IRC | 17:17 | |
erus | i used git fetch and | 17:17 |
kmalloc | you can use git review -d XXXX | 17:17 |
erus | it doesn't work | 17:17 |
kmalloc | where XXX is the review | 17:17 |
erus | ohh I didn't understand the use of -d thans | 17:18 |
kmalloc | now the other option is to go to review.openstack.org and pick the change and download it (there is a series of links at the top right) | 17:18 |
erus | thanks* | 17:18 |
kmalloc | sure thing! | 17:18 |
openstackgerrit | Corey Bryant proposed openstack/keystone master: PY3: switch to using unicode text values https://review.openstack.org/611190 | 17:22 |
*** dnguyen has quit IRC | 17:34 | |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware master: Stop supporting revocation list https://review.openstack.org/613651 | 17:34 |
*** dnguyen has joined #openstack-keystone | 17:35 | |
kmalloc | lbragstad: no elbragstad today? | 17:37 |
lbragstad | bah | 17:37 |
*** lbragstad is now known as elbragstad | 17:37 | |
*** xek has quit IRC | 17:58 | |
*** dnguyen has quit IRC | 18:00 | |
*** aojea has joined #openstack-keystone | 18:06 | |
*** dnguyen has joined #openstack-keystone | 18:08 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement scope_type checking for credentials https://review.openstack.org/594547 | 18:15 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement scope_type checking for credentials https://review.openstack.org/594547 | 18:15 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Pass context objects to policy enforcement https://review.openstack.org/605539 | 18:15 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement scope_types for user API https://review.openstack.org/611179 | 18:16 |
*** aojea has quit IRC | 18:20 | |
openstackgerrit | Merged openstack/keystonemiddleware master: Expect paste.deploy and gnocchi/panko options https://review.openstack.org/515291 | 18:29 |
elbragstad | gmann actuall - i think i reworked the credentials patch to not fail tempests tests ^ | 18:29 |
elbragstad | it should mean that the tests will pass until we enable enforce_scope | 18:30 |
elbragstad | by default | 18:30 |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware master: Stop supporting revocation list https://review.openstack.org/613651 | 18:31 |
*** aojea has joined #openstack-keystone | 18:58 | |
openstackgerrit | Maria N. proposed openstack/keystone master: replace missing topic to related https://review.openstack.org/613670 | 19:11 |
*** dave-mccowan has joined #openstack-keystone | 19:18 | |
*** aojea has quit IRC | 19:31 | |
*** ayoung has joined #openstack-keystone | 19:38 | |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware master: Stop supporting revocation list https://review.openstack.org/613651 | 19:38 |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware master: Remove PKI/PKIZ support https://review.openstack.org/613675 | 19:38 |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware master: Remove PKI/PKIZ support https://review.openstack.org/613675 | 19:44 |
kmalloc | elbragstad: btw - this feels good +19, -2376 | 19:44 |
ayoung | YAAAS! | 19:57 |
ayoung | where do I +3? | 19:57 |
ayoung | +8 on the patch are the release note | 19:58 |
ayoung | kmalloc, its like getting a popcorn kernel out from between your teeth, isn't it? | 20:02 |
elbragstad | i kinda have a mind bender of a question | 20:02 |
elbragstad | ayoung that's how the token provider API refactor was for me | 20:03 |
ayoung | Hai! | 20:03 |
elbragstad | ok - i'm wondering what the right behavior is on upgrade | 20:03 |
elbragstad | let's say someone is overriding "identity:credential_create" with a custom check string "role:manager" or whatever | 20:04 |
elbragstad | and in this release, we're changing both the name and the check string of the default to something like "identity:credential:create": "(role:admin and system_scope:all) or target.credential.%(user_id)" | 20:05 |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware master: [WIP] Correct auth_token headers to be WSGI compliant https://review.openstack.org/613681 | 20:05 |
elbragstad | what should happen when operators install the version with the updated name and check strings? | 20:05 |
elbragstad | should we override "identity:credential:create" with "role:manager" since that is what they were specifying in their older deployment? | 20:07 |
*** aojea has joined #openstack-keystone | 20:07 | |
elbragstad | or should we write an upgrade checker to fail if that's the case and have them get rid of the old policy name they are overriding and port their override to the new name? | 20:07 |
ayoung | we should not do that | 20:08 |
elbragstad | which one? | 20:08 |
kmalloc | same behavior as before, logical or fall through to the old check string and warn that they are using a deprecated name | 20:08 |
ayoung | this is deckchairs on the titanic | 20:08 |
ayoung | renaming policy | 20:08 |
elbragstad | the first or the second? | 20:08 |
ayoung | Until we fix 968696. | 20:08 |
ayoung | Do nothing | 20:08 |
ayoung | niothing that will slow that down | 20:08 |
elbragstad | this isn't slowing anything down i don't think | 20:08 |
elbragstad | i'm just applying conventions | 20:09 |
kmalloc | ayoung: neg. renaming policy is not going to slow that down, renaming policy is for scope types which is part of that fix | 20:09 |
ayoung | make it the route | 20:09 |
ayoung | GET /v3/users etc | 20:09 |
elbragstad | https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies | 20:09 |
ayoung | we going the wrong way | 20:09 |
kmalloc | there was a ML discussion on it | 20:09 |
kmalloc | for normalizing the policy action names in all of openstack | 20:09 |
ayoung | That just means everyone is wrong together. It is called group think | 20:09 |
kmalloc | the URI is not representative there are cases (especially in keystone) we enforce the same action on multiple routes | 20:10 |
ayoung | Glance doesn't even namespace. GO fix it there and THEN come back to Keyustone | 20:10 |
kmalloc | i surrendered on the URI. | 20:10 |
ayoung | kmalloc, that is so irrelelvant | 20:10 |
kmalloc | URI enforcement is separate from the action name. | 20:10 |
ayoung | its like the 1% (and brokne) aopi messing up the rest | 20:10 |
ayoung | yeah, actions | 20:10 |
ayoung | actions suck | 20:10 |
ayoung | and so the Policy on key | 20:10 |
ayoung | and then there are all the Neutronisms | 20:11 |
ayoung | hmmm | 20:11 |
kmalloc | identity:user:list is easy to read | 20:11 |
kmalloc | for example | 20:11 |
ayoung | kmalloc, Deck chairs. Lusitainia | 20:11 |
kmalloc | /v3/users is not as usable | 20:11 |
kmalloc | as an action name | 20:11 |
ayoung | no | 20:12 |
kmalloc | and it NEEDS an action name because of how policy works | 20:12 |
ayoung | I meant the Action API in nova | 20:12 |
kmalloc | that is what you're advocating | 20:12 |
kmalloc | so policy needs an enforcement key. | 20:12 |
ayoung | elbragstad, seriously, a much better use of time would be to fix policy in code in the other proejcts | 20:12 |
ayoung | come back to this after | 20:12 |
kmalloc | and when we're ripping apart policy and changing fundamental behaviors we're doing the new action name with an implied OR for the old location/string | 20:12 |
kmalloc | to allow upgrades without just breaking people | 20:13 |
ayoung | https://developer.openstack.org/api-ref/compute/#add-associate-floating-ip-addfloatingip-action-deprecated | 20:13 |
ayoung | Get a read only role first | 20:13 |
kmalloc | this is allowing for a change of default towards fixing 98...whatever number, and not breaking people and communicating that they need to not do things brokenly | 20:13 |
kmalloc | note, read-only role is going in. | 20:14 |
ayoung | change the important things, then rekey the dictionary | 20:14 |
kmalloc | this is part of the deal | 20:14 |
ayoung | OK...so, GLance | 20:14 |
kmalloc | glance is on the long list | 20:14 |
ayoung | this is going to be an issue there, because they don't even namespace...what should that be like | 20:14 |
kmalloc | right now, it's keystone + nova | 20:14 |
ayoung | Glance needs help | 20:14 |
kmalloc | and then help other folks follow through | 20:14 |
kmalloc | yes, they will | 20:14 |
ayoung | and Glance has snapshots. | 20:14 |
kmalloc | but having keystone + nova means we can set it as a community goal | 20:14 |
ayoung | They won't get to it without us. too understaffed | 20:14 |
ayoung | so, back to elbragstad's quesion | 20:15 |
ayoung | https://github.com/openstack/glance/blob/master/etc/policy.json | 20:15 |
ayoung | lets take the big ones | 20:15 |
kmalloc | so, the correct answer is: logical OR the old policy, warn that there is a new name | 20:15 |
ayoung | add_image https://github.com/openstack/glance/blob/master/etc/policy.json#L5 | 20:15 |
kmalloc | regardless of where the change is | 20:15 |
ayoung | yes | 20:15 |
elbragstad | i'm operating under the assumption that the projects doing this have policy in code and a mechanism to use to deprecate policies | 20:16 |
kmalloc | and since we are doing the work in keystone and nova before trying to bend other folks to the direction | 20:16 |
ayoung | elbragstad, Glance does not | 20:16 |
kmalloc | ayoung: and we'll need to hit that | 20:16 |
elbragstad | my question is how we should handle that when the policy name and check string doesn't | 20:16 |
ayoung | yeah | 20:16 |
kmalloc | as part of the community goal | 20:16 |
elbragstad | ayoung i'm aware, i have the patch up to implement it | 20:16 |
kmalloc | elbragstad: force a move to policy-in-code | 20:16 |
ayoung | yeah...so lets say that langs | 20:16 |
ayoung | lands | 20:16 |
kmalloc | we cannot work under the assumption policy-in-code is optional | 20:17 |
kmalloc | so it loads more work in | 20:17 |
kmalloc | but needed. | 20:17 |
kmalloc | elbragstad: don't try and work around deprecation mechanisms, implement the deprecation mechanisms before changing | 20:17 |
elbragstad | oslo.policy already has the deprecation mechansim | 20:17 |
kmalloc | right | 20:18 |
kmalloc | so, there is no "move to a new check string" if you can't do that | 20:18 |
kmalloc | if there is a "this action doesn't exist anymore" we're in a place where you've broken API contract | 20:18 |
kmalloc | since new policy shouldn't imply anything under the hood has changed | 20:19 |
ayoung | elbragstad, can we do something like this: | 20:19 |
ayoung | I want to make it possible to disable the namespaces for people that have custom policy, and have not upgraded yet | 20:19 |
ayoung | but otherwise, enforce the namespace | 20:20 |
ayoung | so, when we parse the policy files, look for any policies that we know should be namespaced, and... | 20:20 |
ayoung | I don't think we want to fail to deploy | 20:20 |
kmalloc | ayoung: and the path forward for glance is fairly trivial, it's going to be "ensure glance has it's own policy file and not intermixed with any other services' until it supports/migrated to namespaces" | 20:20 |
kmalloc | ^ that is not far out from waht folks do anyway (separate policy.json per service) usually | 20:21 |
elbragstad | right - https://review.openstack.org/#/c/594547/29 is change policy check strings for credentials | 20:21 |
elbragstad | but i also want to change the policy names for credentials to adhere to the new conventions | 20:21 |
ayoung | for custom policy, we are going to have to work with json files for the time being | 20:21 |
ayoung | it could be that if there is a JSON file, accept the old format | 20:21 |
ayoung | if there is none, well, it would only be the new one | 20:21 |
kmalloc | elbragstad: if you can't deprecate, point to a new action-name | 20:21 |
kmalloc | elbragstad: we need that in olso.policy | 20:22 |
kmalloc | the same as how (cringe) oslo.config works with multiple deprecated opts | 20:22 |
elbragstad | i do have deprecations in place https://review.openstack.org/#/c/594547/29/keystone/common/policies/credential.py@38 | 20:22 |
kmalloc | (sometimes) | 20:22 |
kmalloc | for the action-names? | 20:22 |
elbragstad | no - just the check strings | 20:23 |
elbragstad | i was going to update https://review.openstack.org/#/c/594547/29/keystone/common/policies/credential.py@38 in a separate patch | 20:23 |
kmalloc | right | 20:23 |
ayoung | some part of me feels like this should be in oslo-db. The scope check. It should be like the SELinux field on files | 20:23 |
ayoung | idnoes | 20:23 |
ayoung | inodes | 20:23 |
kmalloc | ok, so can we deprecate/logical-or two distinct action names right now | 20:23 |
kmalloc | ? | 20:23 |
kmalloc | because that is needed as well | 20:23 |
kmalloc | ESPECIALLY for glance | 20:23 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement scope_type checking for credentials https://review.openstack.org/594547 | 20:24 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove obsolete credential policies https://review.openstack.org/597187 | 20:24 |
ayoung | So...what about list_trusts | 20:24 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Implement consistent policy names for credentials https://review.openstack.org/613682 | 20:24 |
kmalloc | if we can't aggregate/fall-through-to-an-old-action name, we need that in osli.policy | 20:24 |
elbragstad | ^ | 20:24 |
ayoung | identity:list_trusts is actually supposed to be called unscoped | 20:25 |
ayoung | and by the trustor | 20:25 |
ayoung | "show me all the trusts I have" | 20:25 |
ayoung | not sure why and admin would ever have to do that. But the policies would be different, right? | 20:26 |
kmalloc | and that will load the deployer's old identity:create_credential from policy.json when we call identity:credential:create ? | 20:26 |
kmalloc | elbragstad: ^ | 20:26 |
ayoung | And...that would be a case of splitting a current policy | 20:26 |
kmalloc | because that is what i'm advocating for | 20:26 |
elbragstad | kmalloc i think the old policy will be in the rule set | 20:26 |
ayoung | so, if an end deployer then uploaded custom policy, that only covered one of the use cases, what would be the right thing to do? | 20:27 |
kmalloc | if that is the case, we need to just warn that we're loading from an old policy-action name | 20:27 |
elbragstad | but i'm wonder if we should override the new policy with the old value? | 20:27 |
kmalloc | logical or | 20:27 |
kmalloc | we fall back to the old check_Str | 20:27 |
ayoung | what if the old policy only covered one of the paths? | 20:27 |
elbragstad | or if we should write an upgrade check to say "hey, you're overriding an old policy name, which we don't use anymore, fix that before running keystone." | 20:27 |
ayoung | Do we ignore it on the other path, or force it to cover both? | 20:28 |
kmalloc | elbragstad: i would warn, i wouldn't break things | 20:28 |
kmalloc | and not start | 20:28 |
kmalloc | make it part of upgrade-test | 20:28 |
kmalloc | and policy-cli | 20:28 |
kmalloc | and even doctor | 20:28 |
elbragstad | it would be a keystone-status upgrade check | 20:28 |
kmalloc | and policy-cli | 20:28 |
kmalloc | but yeah, warnings | 20:28 |
kmalloc | no breaking | 20:28 |
kmalloc | and upgrade note "we recommend you alwasy use the most recent action-name" | 20:29 |
ayoung | I'm thinking more Neutron here, where a lot of deployers want to disable certain operations for non-power users | 20:29 |
elbragstad | this is already supported, https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L593-L600 | 20:29 |
kmalloc | well, the operations should have their own PEP then, right? | 20:30 |
elbragstad | er - this is what is currently supported by oslo.policy today for changing policy names https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L593-L600 | 20:30 |
kmalloc | ayoung: ^ | 20:30 |
kmalloc | ayoung: so, it ultimately would be doable in either case | 20:30 |
kmalloc | we're not combining/changing policy-enforcement-points | 20:30 |
kmalloc | we're allowing for a consistent naming policy. | 20:30 |
elbragstad | which results in http://paste.openstack.org/raw/733156/ | 20:30 |
ayoung | this is more than a change, though, right? You might actually still have the old name in place, just a new policy in additon, for an API that used to be covered by a single policy | 20:30 |
kmalloc | elbragstad: we should ensure that if the *new* policy name is customized, we only use that | 20:31 |
kmalloc | elbragstad: we do not logically OR the old with the new if the new is overidden | 20:31 |
kmalloc | which i *think* solves ayoung's concern | 20:31 |
ayoung | yeah that would be bad | 20:31 |
ayoung | Or means openeing up holes | 20:31 |
kmalloc | ayoung: right | 20:31 |
ayoung | ok...what is the workflow like right now | 20:32 |
*** imacdonn has quit IRC | 20:32 | |
elbragstad | ok - https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L593-L600 doesn't do that today | 20:32 |
elbragstad | it just detects that there is a change happening and it logs a warning | 20:32 |
kmalloc | elbragstad: we need to fix that before we land the change to keystone/anywhere else to rename policy | 20:32 |
*** imacdonn has joined #openstack-keystone | 20:32 | |
kmalloc | elbragstad: overriding the new stops the fallback to the old cases | 20:32 |
ayoung | assuming, for a moment, that a site has customized json for policy, we state that the policy rules are not going to change during a single release. If one is going away, we deprecate... | 20:32 |
kmalloc | if the new is "default" logically OR the old. | 20:32 |
ayoung | what do we say about adding a new one? | 20:33 |
ayoung | Obviously, new ones only come about upon named releases | 20:33 |
kmalloc | right. | 20:33 |
ayoung | if there is a default policy in the customized file, it will cover the new policy | 20:33 |
ayoung | but | 20:33 |
kmalloc | and new ones usually correlate with new APIs | 20:34 |
ayoung | if that policy is for an API that used to be covered by an old policy rule, things now might break | 20:34 |
kmalloc | if we're adding a rename/new-more-correct form, we encourage migrating old policy to new | 20:34 |
kmalloc | location | 20:34 |
ayoung | like, say we take list_trusts and create a new rule list_trusts_for_trustor | 20:34 |
ayoung | AThe new default would be what we put in code. | 20:35 |
ayoung | And, I'd argue, is probably the right logic, | 20:35 |
kmalloc | yes. | 20:35 |
ayoung | IS. trust.trustor == user.id | 20:35 |
elbragstad | so we'd protect the API with list_trusts_for_trustor | 20:35 |
ayoung | or summat | 20:35 |
kmalloc | however, so nothing breaks: we do (rule:list_trusts_for_trustor OR rule:list_trusts_ | 20:35 |
kmalloc | for the deprecation window | 20:35 |
ayoung | only for the new branch, right? | 20:36 |
kmalloc | if someone customizes list_trusts_for_trustor, the OR is no longer implied | 20:36 |
kmalloc | branch = new release? | 20:36 |
kmalloc | or branch = new api? | 20:36 |
ayoung | I mean the new code branch | 20:36 |
kmalloc | only forward looking releases have the new enforcement point/data | 20:36 |
kmalloc | and eventually we stop the logical or in the case of new-action is default | 20:37 |
ayoung | only the OR on the identity:list_trusts_for_user rule, which did not exist before...that gets ORed with list_trusts, | 20:37 |
kmalloc | yes | 20:37 |
kmalloc | because list_trusts() would call enforce_call(action='identity:list_trusts_for_trustor') | 20:37 |
ayoung | I think we're going to want better tooling | 20:37 |
kmalloc | which behind the scenes ORs as long as list_trusts_for_trustor is default | 20:37 |
ayoung | I am thinking maybe an online service where a user can upload policy and we tell them where we will break it in the next release | 20:38 |
kmalloc | but that is a bad example, because it would be identity:trusts:list, and that would use identity:list_trusts as an or | 20:38 |
kmalloc | unless identity:trusts:lists was customized | 20:38 |
kmalloc | which case we don't OR. | 20:38 |
kmalloc | and in a future release (1, 2, 3, 4? cycles) the implicit OR for identity:list_trusts is deleted | 20:39 |
kmalloc | the whole while up to that we throw warnings/errors etc | 20:39 |
*** aojea has quit IRC | 20:40 | |
kmalloc | this is a two-fold change | 20:40 |
kmalloc | 1) normalizing how we call policy things, 2) allowing projects like glance to get namespaced, 3) be smart about handling new vs old PEP references. | 20:40 |
kmalloc | i also suffer from constant off-by-one errors | 20:40 |
kmalloc | elbragstad: this looks wrong <service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>] | 20:42 |
kmalloc | btw | 20:42 |
kmalloc | since there are variable bits of information between resource and action | 20:42 |
*** openstackstatus has quit IRC | 20:42 | |
*** openstack has joined #openstack-keystone | 20:43 | |
*** ChanServ sets mode: +o openstack | 20:43 | |
*** openstackstatus has joined #openstack-keystone | 20:43 | |
*** ChanServ sets mode: +v openstackstatus | 20:43 | |
kmalloc | so give me an example with a subresource, attribute and tell me how easy it is to understand | 20:43 |
kmalloc | service-resource-action should *always* be in fixed locations | 20:43 |
kmalloc | similar with attributes/subactions | 20:43 |
elbragstad | network:ip-address:fix-ip-address:create | 20:44 |
elbragstad | is an example of subresources | 20:44 |
kmalloc | now add in attributes and subactions | 20:44 |
kmalloc | and what the hell is going on | 20:44 |
kmalloc | we're back to useless names | 20:44 |
elbragstad | compute:flavor:private:list is an example of a policy for protecting an API for listing private flavors | 20:44 |
kmalloc | sub-resource, attribute and subaction should 100% be identified separately/in a distinct way | 20:45 |
kmalloc | that is awful | 20:45 |
kmalloc | compute:flavor(private):list would be fine | 20:45 |
kmalloc | but looking at it, i have to guess contextually that list is the action | 20:45 |
kmalloc | because we're now back to things being in arbitrary locations/different levels of split | 20:45 |
kmalloc | compute:flavor,private:list,subaction | 20:46 |
kmalloc | that would be a way i'd do it | 20:46 |
elbragstad | well - you can propose a patch to change it then if you'd like | 20:46 |
kmalloc | i think i missed that part of the convo/review | 20:46 |
kmalloc | i would have -2'd it as is | 20:46 |
kmalloc | that is, imo, worse than what we have now | 20:47 |
kmalloc | pre-normalization | 20:47 |
* kmalloc sighs | 20:47 | |
kmalloc | i honestly just don't care enough to fight these battles i'll just bow out of reviewing those things and let you drive it. | 20:47 |
kmalloc | s/don't care/don't have enough bandwidth/ | 20:47 |
kmalloc | my level of willingness to fight open source political battles is pretty low | 20:48 |
kmalloc | and it is emotional bandwidth not code-writing-evaluating stuff | 20:48 |
elbragstad | kmalloc no one is fighting with you, it was simply an oversight and not intention | 20:50 |
kmalloc | see the PM. | 20:50 |
*** ayoung has joined #openstack-keystone | 20:55 | |
*** imus has quit IRC | 20:56 | |
ayoung | elbragstad, let me ask it this way: do you think the improvement of identity:user:list is such an improvement that it is worth the pain it will make to people who customize policy? | 21:02 |
elbragstad | ayoung it's not really what i think... i'm working on what operators are asking for | 21:05 |
ayoung | elbragstad, what is the motivation? | 21:06 |
elbragstad | consistency across services and apis | 21:06 |
*** raildo has quit IRC | 21:08 | |
*** erus has quit IRC | 21:09 | |
*** aojea has joined #openstack-keystone | 21:10 | |
*** dnguyen has quit IRC | 21:40 | |
*** dnguyen has joined #openstack-keystone | 21:41 | |
*** aojea has quit IRC | 21:42 | |
*** itlinux has quit IRC | 22:05 | |
*** aojea has joined #openstack-keystone | 22:11 | |
*** erus has joined #openstack-keystone | 22:19 | |
*** aojea has quit IRC | 22:37 | |
*** pcaruana has quit IRC | 23:10 | |
*** dnguyen has quit IRC | 23:28 | |
*** rcernin has joined #openstack-keystone | 23:43 | |
*** rcernin has quit IRC | 23:51 | |
*** itlinux has joined #openstack-keystone | 23:52 | |
*** gyee has quit IRC | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!