Friday, 2018-10-26

kmallocmgagne: no problem! happy to help00:43
openstackgerritMorgan Fainberg proposed openstack/keystone master: Emit CADF notifications on authentication for invalid users  https://review.openstack.org/61345500:48
*** itlinux has joined #openstack-keystone00:49
openstackgerritMerged openstack/keystoneauth master: Add missing release note for ironic discovery fix  https://review.openstack.org/61287201:36
*** lbragstad has quit IRC01:49
*** lbragstad has joined #openstack-keystone01:49
*** ChanServ sets mode: +o lbragstad01:49
*** rcernin has joined #openstack-keystone01:55
*** Dinesh_Bhor has joined #openstack-keystone01:55
openstackgerritMerged openstack/keystone master: Update keystone-manage bootstrap port instructions  https://review.openstack.org/61316302:26
openstackgerritMerged openstack/keystone master: Fix api-ref v3.9 release identifier  https://review.openstack.org/61325702:26
openstackgerritVishakha Agarwal proposed openstack/keystone master: Set Default and resource limit as defined schema  https://review.openstack.org/61047902:47
*** erus has quit IRC02:50
*** Dinesh_Bhor has quit IRC02:58
*** Dinesh_Bhor has joined #openstack-keystone03:06
*** erus has joined #openstack-keystone03:21
*** Dinesh_Bhor has quit IRC04:11
*** dave-mccowan has quit IRC04:14
*** shyamb has joined #openstack-keystone05:25
*** Dinesh_Bhor has joined #openstack-keystone05:35
*** shyamb has quit IRC05:37
*** mchlumsky_ has joined #openstack-keystone05:46
*** shyamb has joined #openstack-keystone05:47
*** cwright_ has joined #openstack-keystone05:51
*** hemna_ has joined #openstack-keystone05:54
*** ianw_ has joined #openstack-keystone05:54
*** dims_ has joined #openstack-keystone05:54
*** mchlumsky has quit IRC05:55
*** dims has quit IRC05:55
*** hemna has quit IRC05:55
*** mattoliverau has quit IRC05:55
*** ianw has quit IRC05:55
*** cwright has quit IRC05:55
*** jlvillal has quit IRC05:55
*** ianw_ is now known as ianw05:55
*** irclogbot_1 has quit IRC05:58
*** shyamb has quit IRC06:13
*** shyamb has joined #openstack-keystone06:31
openstackgerritwangxiyuan proposed openstack/keystone master: Drop unhash password column  https://review.openstack.org/61351307:02
*** rcernin has quit IRC07:22
*** shyamb has quit IRC07:28
*** xek has joined #openstack-keystone07:35
*** shyamb has joined #openstack-keystone07:39
*** Dinesh_Bhor has quit IRC07:39
*** shyamb has quit IRC08:03
vishakhacmurphy: 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-keystone08:18
vishakhacmurphy: 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-keystone08:32
*** aojea has quit IRC08:36
*** shyamb has joined #openstack-keystone09:05
*** sapd1 has quit IRC09:25
*** shyamb has quit IRC09:43
*** shyamb has joined #openstack-keystone10:12
*** shyamb has quit IRC10:24
*** dave-mccowan has joined #openstack-keystone11:15
*** shyamb has joined #openstack-keystone11:15
*** tridde is now known as trident11:17
*** Dinesh_Bhor has quit IRC11:22
*** erus has quit IRC11:48
*** shyamb has quit IRC12:12
*** raildo has joined #openstack-keystone12:13
cmurphyvishakha: 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 provider12:15
cmurphyvishakha: 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 yourself12:16
*** shyamb has joined #openstack-keystone12:34
openstackgerritJuan Antonio Osorio Robles proposed openstack/oslo.policy master: Handle JSON responses in the http and https checks  https://review.openstack.org/61357012:43
*** shyamb has quit IRC12:47
*** dave-mccowan has quit IRC13:00
*** pooja_jadhav has quit IRC13:14
*** erus has joined #openstack-keystone13:30
erushi, good morning o/13:30
*** cwright_ is now known as cwright13:32
*** aojea has joined #openstack-keystone13:42
openstackgerritLance Bragstad proposed openstack/keystone master: Remove deprecated secure_proxy_ssl_header config  https://review.openstack.org/49979813:49
knikollao/13:50
knikollamorning13:50
*** bnemec has joined #openstack-keystone13:54
*** aojea has quit IRC14:05
lbragstadhola14:07
erushola14:08
erusI've been checking https://bugs.launchpad.net/keystone/+bugs?field.tag=low-hanging-fruit but not sure how to start14:09
*** dave-mccowan has joined #openstack-keystone14:11
lbragstaderus is there one in particular that you want to work on?14:12
*** dave-mccowan has quit IRC14:15
erusmaybe this one https://bugs.launchpad.net/keystone/+bug/1698455, but not sure if I could :)14:16
openstackLaunchpad 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
lbragstaderus it looks like that one is still under discussion14:22
lbragstaderus are you familiar with the different bug states?14:22
erusnot really14:26
lbragstadno worries - sometimes when you see a bug in Incomplete status, it means we're probably waiting for more information from the reporter14:28
lbragstadwhich could be things like how to recreate the bug, or justification on why this is a keystone-specific issue14:28
lbragstadwhich is what cmurphy is asking about in comment #1014:29
lbragstadwhen the reporter supplies that information, we can either update the status to be Triaged/Confirmed or Invalid, depending on the feedback14:29
erusohh I see, I thought that incomplete means that need to be completed(?) hehe thanks14:31
erusso, I don't know, I want to choose one that fit my knowledge, I mean that I could be able to do it14:31
lbragstadthis 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
erusit's difficult to give you a real answer since it's my first time with keystone and openstack in general14:37
*** aojea has joined #openstack-keystone14:39
lbragstadthat'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 reported14:40
openstackLaunchpad 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 IRC14:40
*** aojea has joined #openstack-keystone14:41
erusI wanted to try this project because of the identity federation and federation protocols14:41
erusand wanted to know more about openstack14:41
erusknow and learn14:41
erusthanks, I will try to recreate it14:44
*** aojea has quit IRC14:45
lbragstaderus no problem, let us know if you have more questions14:48
coreycbhi 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
coreycbhttps://review.openstack.org/#/c/61140114:56
coreycbhttps://review.openstack.org/#/c/61119014:56
coreycb(note ldapppool needs to land before keystone py36 tests can succeed)14:56
*** dansmith is now known as SteelyDan15:01
openstackgerritMerged openstack/keystone master: Delete administrator federation guide  https://review.openstack.org/61340815:12
*** itlinux has quit IRC15:13
openstackgerritguang-yee proposed openstack/keystonemiddleware master: Skip the services with no endpoints when parsing service catalog  https://review.openstack.org/61341015:14
*** gyee has joined #openstack-keystone15:23
*** itlinux has joined #openstack-keystone15:56
kmalloccoreycb: +2/+A on ldappool15:56
coreycbkmalloc: awesome, thanks. once that lands can we get a new release cut?16:00
kmallocyeah, propose the release review and lbragstad and i will +1 for the release team to push it out16:04
kmallocwill be monday at the earliest though, no releases on friday16:04
openstackgerritMerged openstack/ldappool master: PY3: switch to using unicode text values  https://review.openstack.org/61140116:08
kmalloccoreycb: ^ should be good to propose the release of ldappool now16:12
coreycbkmalloc: ok will do16:12
*** bnemec is now known as beekneemech16:13
coreycbkmalloc: lbragstad: here you go - https://review.openstack.org/#/c/61363216:21
coreycbi assume that's right, haven't done it before :)16:22
openstackgerritMorgan Fainberg proposed openstack/keystone master: Provide a Location on HTTP 300  https://review.openstack.org/61363316:23
kmalloclooking16:23
kmalloccoreycb: go with 2.3.1 and we will need to backport the fix to stable/queens branch (and stable/pike?)16:24
coreycbkmalloc: ok yeah was wondering if that would make more sense16:24
kmalloccoreycb: i'll comment on the review.16:25
coreycbkmalloc: updated16:26
kmalloccool.16:26
kmallocand we might need to / probably will need to cherry-pick to the stable branches...16:26
kmallocdepending on what version is used in your version of openstack (can you confirm)16:26
kmallocit might be 2.3.016:26
openstackgerritLance Bragstad proposed openstack/oslo.policy master: Add domain scope support for scope types  https://review.openstack.org/61144316:27
coreycbkmalloc: yep i have stable/queens going at https://review.openstack.org/#/c/613615. that's enough for us at least.16:29
kmalloclbragstad: the new token model doesn't suffer from this, does it: https://bugs.launchpad.net/keystone/+bug/165201216:31
openstackLaunchpad bug 1652012 in OpenStack Identity (keystone) "token model assumes a token is is_admin_project" [Low,Triaged]16:31
lbragstadlemme check16:31
coreycbkmalloc: 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
kmallocright16:31
kmallocbut i figure we should be most correct wherever we can be16:32
kmalloclbragstad: or at least that is not an issue because we're moving to scopes16:32
kmalloclbragstad: which might be just worth closing that bug as "wont fix, moving to scope_types instead"16:32
openstackgerritMichael Johnson proposed openstack/keystonemiddleware master: Fix audit target service selection  https://review.openstack.org/61009916:33
*** dave-mccowan has joined #openstack-keystone16:33
lbragstadyeah - looks like i didn't include that logic in the new model16:34
lbragstadhttps://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/render_token.py#n9416:34
kmalloccool16:34
lbragstadbut it is in the render_token code16:34
lbragstadbut it looks completely config driven16:34
kmallocwhich sounds to me close "invalid" we don't assume this anymore16:35
lbragstadi'll update the bug16:35
* kmalloc is trying to cleanup a many of our bugs as we can16:35
kmallocguess i'm still on the janitor(tm) job for the next few days16:35
kmalloc(more doctor appointments, so can't focus on other things as much)16:35
lbragstadsounds good16:38
lbragstadhttps://bugs.launchpad.net/keystone/+bug/1652012/comments/616:38
openstackLaunchpad bug 1652012 in OpenStack Identity (keystone) "token model assumes a token is is_admin_project" [Low,Invalid]16:38
kmallocthnx16:39
*** dnguyen has joined #openstack-keystone16:51
coreycbkmalloc: i added stable/rocky branch to that review as there currently isn't one for ldappool16:57
*** dave-mccowan has quit IRC16:58
erusI have a question, git-review is like git fetch?17:08
*** aojea has joined #openstack-keystone17:13
kmalloccoreycb: thanks17:14
erusI mean does it use git fetch internally?17:15
kmallocerus it can do rebasing, but typically it just pushes the data to gerrit17:15
erusso it use git push "internally"?17:16
kmallocbasically17:16
kmalloci'd have to go look at what it does17:16
erusok ok got it17:16
kmallocto be super sure on how it works, it's been a while since i've written code for git-review itself :)17:16
erusand how can I retrieve a change? like git fetch or git pull?17:17
kmalloci use git fetch17:17
kmallocoh you mean from gerrit?17:17
erusyep17:17
*** aojea has quit IRC17:17
erusi used git fetch and17:17
kmallocyou can use git review -d XXXX17:17
erusit doesn't work17:17
kmallocwhere XXX is the review17:17
erusohh I didn't understand the use of -d thans17:18
kmallocnow 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
erusthanks*17:18
kmallocsure thing!17:18
openstackgerritCorey Bryant proposed openstack/keystone master: PY3: switch to using unicode text values  https://review.openstack.org/61119017:22
*** dnguyen has quit IRC17:34
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Stop supporting revocation list  https://review.openstack.org/61365117:34
*** dnguyen has joined #openstack-keystone17:35
kmalloclbragstad: no elbragstad today?17:37
lbragstadbah17:37
*** lbragstad is now known as elbragstad17:37
*** xek has quit IRC17:58
*** dnguyen has quit IRC18:00
*** aojea has joined #openstack-keystone18:06
*** dnguyen has joined #openstack-keystone18:08
openstackgerritLance Bragstad proposed openstack/keystone master: Implement scope_type checking for credentials  https://review.openstack.org/59454718:15
openstackgerritLance Bragstad proposed openstack/keystone master: Implement scope_type checking for credentials  https://review.openstack.org/59454718:15
openstackgerritLance Bragstad proposed openstack/keystone master: Pass context objects to policy enforcement  https://review.openstack.org/60553918:15
openstackgerritLance Bragstad proposed openstack/keystone master: Implement scope_types for user API  https://review.openstack.org/61117918:16
*** aojea has quit IRC18:20
openstackgerritMerged openstack/keystonemiddleware master: Expect paste.deploy and gnocchi/panko options  https://review.openstack.org/51529118:29
elbragstadgmann actuall - i think i reworked the credentials patch to not fail tempests tests ^18:29
elbragstadit should mean that the tests will pass until we enable enforce_scope18:30
elbragstadby default18:30
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Stop supporting revocation list  https://review.openstack.org/61365118:31
*** aojea has joined #openstack-keystone18:58
openstackgerritMaria N. proposed openstack/keystone master: replace missing topic to related  https://review.openstack.org/61367019:11
*** dave-mccowan has joined #openstack-keystone19:18
*** aojea has quit IRC19:31
*** ayoung has joined #openstack-keystone19:38
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Stop supporting revocation list  https://review.openstack.org/61365119:38
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Remove PKI/PKIZ support  https://review.openstack.org/61367519:38
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Remove PKI/PKIZ support  https://review.openstack.org/61367519:44
kmallocelbragstad: btw - this feels good +19, -237619:44
ayoungYAAAS!19:57
ayoungwhere do I +3?19:57
ayoung+8 on the patch are the release note19:58
ayoungkmalloc, its like getting a popcorn kernel out from between your teeth, isn't it?20:02
elbragstadi kinda have a mind bender of a question20:02
elbragstadayoung that's how the token provider API refactor was for me20:03
ayoungHai!20:03
elbragstadok - i'm wondering what the right behavior is on upgrade20:03
elbragstadlet's say someone is overriding "identity:credential_create" with a custom check string "role:manager" or whatever20:04
elbragstadand 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
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: [WIP] Correct auth_token headers to be WSGI compliant  https://review.openstack.org/61368120:05
elbragstadwhat should happen when operators install the version with the updated name and check strings?20:05
elbragstadshould 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-keystone20:07
elbragstador 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
ayoungwe should not do that20:08
elbragstadwhich one?20:08
kmallocsame behavior as before, logical or fall through to the old check string and warn that they are using a deprecated name20:08
ayoungthis is deckchairs on the titanic20:08
ayoungrenaming policy20:08
elbragstadthe first or the second?20:08
ayoungUntil we fix 968696.20:08
ayoungDo nothing20:08
ayoungniothing that will slow that down20:08
elbragstadthis isn't slowing anything down i don't think20:08
elbragstadi'm just applying conventions20:09
kmallocayoung: neg. renaming policy is not going to slow that down, renaming policy is for scope types which is part of that fix20:09
ayoungmake it the route20:09
ayoungGET /v3/users  etc20:09
elbragstadhttps://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies20:09
ayoungwe going the wrong way20:09
kmallocthere was a ML discussion on it20:09
kmallocfor normalizing the policy action names in all of openstack20:09
ayoungThat just means everyone is wrong together.  It is called group think20:09
kmallocthe URI is not representative there are cases (especially in keystone) we enforce the same action on multiple routes20:10
ayoungGlance doesn't even namespace. GO fix it there and THEN come back to Keyustone20:10
kmalloci surrendered on the URI.20:10
ayoungkmalloc, that is so irrelelvant20:10
kmallocURI enforcement is separate from the action name.20:10
ayoungits like the 1% (and brokne) aopi messing up the rest20:10
ayoungyeah, actions20:10
ayoungactions suck20:10
ayoungand so the Policy on key20:10
ayoungand then there are all the Neutronisms20:11
ayounghmmm20:11
kmallocidentity:user:list is easy to read20:11
kmallocfor example20:11
ayoungkmalloc, Deck chairs.  Lusitainia20:11
kmalloc /v3/users is not as usable20:11
kmallocas an action name20:11
ayoungno20:12
kmallocand it NEEDS an action name because of how policy works20:12
ayoungI meant the Action API in nova20:12
kmallocthat is what you're advocating20:12
kmallocso policy needs an enforcement key.20:12
ayoungelbragstad, seriously, a much better use of time would be to fix policy in code in the other proejcts20:12
ayoungcome back to this after20:12
kmallocand 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/string20:12
kmallocto allow upgrades without just breaking people20:13
ayounghttps://developer.openstack.org/api-ref/compute/#add-associate-floating-ip-addfloatingip-action-deprecated20:13
ayoungGet a read only role first20:13
kmallocthis 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 brokenly20:13
kmallocnote, read-only role is going in.20:14
ayoungchange the important things, then rekey the dictionary20:14
kmallocthis is part of the deal20:14
ayoungOK...so, GLance20:14
kmallocglance is on the long list20:14
ayoungthis is going to be an issue there, because they don't even namespace...what should that be like20:14
kmallocright now, it's keystone + nova20:14
ayoungGlance needs help20:14
kmallocand then help other folks follow through20:14
kmallocyes, they will20:14
ayoungand Glance has snapshots.20:14
kmallocbut having keystone + nova means we can set it as a community goal20:14
ayoungThey won't get to it without us.  too understaffed20:14
ayoungso, back to elbragstad's quesion20:15
ayounghttps://github.com/openstack/glance/blob/master/etc/policy.json20:15
ayounglets take the big ones20:15
kmallocso, the correct answer is: logical OR the old policy, warn that there is a new name20:15
ayoungadd_image https://github.com/openstack/glance/blob/master/etc/policy.json#L520:15
kmallocregardless of where the change is20:15
ayoungyes20:15
elbragstadi'm operating under the assumption that the projects doing this have policy in code and a mechanism to use to deprecate policies20:16
kmallocand since we are doing the work in keystone and nova before trying to bend other folks to the direction20:16
ayoungelbragstad, Glance does not20:16
kmallocayoung: and we'll need to hit that20:16
elbragstadmy question is how we should handle that when the policy name and check string doesn't20:16
ayoungyeah20:16
kmallocas part of the community goal20:16
elbragstadayoung i'm aware, i have the patch up to implement it20:16
kmallocelbragstad: force a move to policy-in-code20:16
ayoungyeah...so lets say that langs20:16
ayounglands20:16
kmallocwe cannot work under the assumption policy-in-code is optional20:17
kmallocso it loads more work in20:17
kmallocbut needed.20:17
kmallocelbragstad: don't try and work around deprecation mechanisms, implement the deprecation mechanisms before changing20:17
elbragstadoslo.policy already has the deprecation mechansim20:17
kmallocright20:18
kmallocso, there is no "move to a new check string" if you can't do that20:18
kmallocif there is a "this action doesn't exist anymore" we're in a place where you've broken API contract20:18
kmallocsince new policy shouldn't imply anything under the hood has changed20:19
ayoungelbragstad, can we do something like this:20:19
ayoungI want to make it possible to disable the namespaces for people that have custom policy, and have not upgraded yet20:19
ayoungbut otherwise, enforce the namespace20:20
ayoungso, when we parse the policy files, look for any policies that we know should be namespaced, and...20:20
ayoungI don't think we want to fail to deploy20:20
kmallocayoung: 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) usually20:21
elbragstadright - https://review.openstack.org/#/c/594547/29 is change policy check strings for credentials20:21
elbragstadbut i also want to change the policy names for credentials to adhere to the new conventions20:21
ayoungfor custom policy, we are going to have to work with json files for the time being20:21
ayoungit could be that if there is a JSON file, accept the old format20:21
ayoungif there is none, well, it would only be the new one20:21
kmallocelbragstad: if you can't deprecate, point to a new action-name20:21
kmallocelbragstad: we need that in olso.policy20:22
kmallocthe same as how (cringe) oslo.config works with multiple deprecated opts20:22
elbragstadi do have deprecations in place https://review.openstack.org/#/c/594547/29/keystone/common/policies/credential.py@3820:22
kmalloc(sometimes)20:22
kmallocfor the action-names?20:22
elbragstadno - just the check strings20:23
elbragstadi was going to update https://review.openstack.org/#/c/594547/29/keystone/common/policies/credential.py@38 in a separate patch20:23
kmallocright20:23
ayoungsome part of me feels like this should be in oslo-db.  The scope check.  It should be like the SELinux field on files20:23
ayoungidnoes20:23
ayounginodes20:23
kmallocok, so can we deprecate/logical-or two distinct action names right now20:23
kmalloc?20:23
kmallocbecause that is needed as well20:23
kmallocESPECIALLY for glance20:23
openstackgerritLance Bragstad proposed openstack/keystone master: Implement scope_type checking for credentials  https://review.openstack.org/59454720:24
openstackgerritLance Bragstad proposed openstack/keystone master: Remove obsolete credential policies  https://review.openstack.org/59718720:24
ayoungSo...what about list_trusts20:24
openstackgerritLance Bragstad proposed openstack/keystone master: Implement consistent policy names for credentials  https://review.openstack.org/61368220:24
kmallocif we can't aggregate/fall-through-to-an-old-action name, we need that in osli.policy20:24
elbragstad^20:24
ayoungidentity:list_trusts is actually supposed to be called unscoped20:25
ayoungand by the trustor20:25
ayoung"show me all the trusts I have"20:25
ayoungnot sure why and admin would ever have to do that.  But the policies would be different, right?20:26
kmallocand that will load the deployer's old identity:create_credential from policy.json when we call identity:credential:create ?20:26
kmallocelbragstad: ^20:26
ayoungAnd...that would be a case of splitting a current policy20:26
kmallocbecause that is what i'm advocating for20:26
elbragstadkmalloc i think the old policy will be in the rule set20:26
ayoungso, 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
kmallocif that is the case, we need to just warn that we're loading from an old policy-action name20:27
elbragstadbut i'm wonder if we should override the new policy with the old value?20:27
kmalloclogical or20:27
kmallocwe fall back to the old check_Str20:27
ayoungwhat if the old policy only covered one of the paths?20:27
elbragstador 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
ayoungDo we ignore it on the other path, or force it to cover both?20:28
kmallocelbragstad: i would warn, i wouldn't break things20:28
kmallocand not start20:28
kmallocmake it part of upgrade-test20:28
kmallocand policy-cli20:28
kmallocand even doctor20:28
elbragstadit would be a keystone-status upgrade check20:28
kmallocand policy-cli20:28
kmallocbut yeah, warnings20:28
kmallocno breaking20:28
kmallocand upgrade note "we recommend you alwasy use the most recent action-name"20:29
ayoungI'm thinking more Neutron here, where a lot of deployers want to disable certain operations for non-power users20:29
elbragstadthis is already supported, https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L593-L60020:29
kmallocwell, the operations should have their own PEP then, right?20:30
elbragstader - 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-L60020:30
kmallocayoung: ^20:30
kmallocayoung: so, it ultimately would be doable in either case20:30
kmallocwe're not combining/changing policy-enforcement-points20:30
kmallocwe're allowing for a consistent naming policy.20:30
elbragstadwhich results in http://paste.openstack.org/raw/733156/20:30
ayoungthis 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 policy20:30
kmallocelbragstad: we should ensure that if the *new* policy name is customized, we only use that20:31
kmallocelbragstad: we do not logically OR the old with the new if the new is overidden20:31
kmallocwhich i *think* solves ayoung's concern20:31
ayoungyeah that would be bad20:31
ayoungOr means openeing up holes20:31
kmallocayoung: right20:31
ayoungok...what is the workflow like right now20:32
*** imacdonn has quit IRC20:32
elbragstadok - https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L593-L600 doesn't do that today20:32
elbragstadit just detects that there is a change happening and it logs a warning20:32
kmallocelbragstad: we need to fix that before we land the change to keystone/anywhere else to rename policy20:32
*** imacdonn has joined #openstack-keystone20:32
kmallocelbragstad: overriding the new stops the fallback to the old cases20:32
ayoungassuming, 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
kmallocif the new is "default" logically OR the old.20:32
ayoungwhat do we say about adding a new one?20:33
ayoungObviously, new ones only come about upon named releases20:33
kmallocright.20:33
ayoungif there is a default policy in the customized file, it will cover the new policy20:33
ayoungbut20:33
kmallocand new ones usually correlate with new APIs20:34
ayoungif that policy is for an API that used to be covered by an old policy rule, things now might break20:34
kmallocif we're adding a rename/new-more-correct form, we encourage migrating old policy to new20:34
kmalloclocation20:34
ayounglike, say we take list_trusts and create a new rule list_trusts_for_trustor20:34
ayoungAThe new default would be what we put in code.20:35
ayoungAnd, I'd argue, is probably the right logic,20:35
kmallocyes.20:35
ayoungIS.  trust.trustor == user.id20:35
elbragstadso we'd protect the API with list_trusts_for_trustor20:35
ayoungor summat20:35
kmallochowever, so nothing breaks: we do (rule:list_trusts_for_trustor OR rule:list_trusts_20:35
kmallocfor the deprecation window20:35
ayoungonly for the new branch, right?20:36
kmallocif someone customizes list_trusts_for_trustor, the OR is no longer implied20:36
kmallocbranch = new release?20:36
kmallocor branch = new api?20:36
ayoungI mean the new code branch20:36
kmalloconly forward looking releases have the new enforcement point/data20:36
kmallocand eventually we stop the logical or in the case of new-action is default20:37
ayoungonly the OR on the identity:list_trusts_for_user rule, which did not exist before...that gets ORed with list_trusts,20:37
kmallocyes20:37
kmallocbecause list_trusts() would call enforce_call(action='identity:list_trusts_for_trustor')20:37
ayoungI think we're going to want better tooling20:37
kmallocwhich behind the scenes ORs as long as list_trusts_for_trustor is default20:37
ayoungI am thinking maybe an online service where a user can upload policy and we tell them where we will break it in the next release20:38
kmallocbut that is a bad example, because it would be identity:trusts:list, and that would use identity:list_trusts as an or20:38
kmallocunless identity:trusts:lists was customized20:38
kmallocwhich case we don't OR.20:38
kmallocand in a future release (1, 2, 3, 4? cycles) the implicit OR for identity:list_trusts is deleted20:39
kmallocthe whole while up to that we throw warnings/errors etc20:39
*** aojea has quit IRC20:40
kmallocthis is a two-fold change20:40
kmalloc1) 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
kmalloci also suffer from constant off-by-one errors20:40
kmallocelbragstad: this looks wrong <service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>]20:42
kmallocbtw20:42
kmallocsince there are variable bits of information between resource and action20:42
*** openstackstatus has quit IRC20:42
*** openstack has joined #openstack-keystone20:43
*** ChanServ sets mode: +o openstack20:43
*** openstackstatus has joined #openstack-keystone20:43
*** ChanServ sets mode: +v openstackstatus20:43
kmallocso give me an example with a subresource, attribute and tell me how easy it is to understand20:43
kmallocservice-resource-action should *always* be in fixed locations20:43
kmallocsimilar with attributes/subactions20:43
elbragstadnetwork:ip-address:fix-ip-address:create20:44
elbragstadis an example of subresources20:44
kmallocnow add in attributes and subactions20:44
kmallocand what the hell is going on20:44
kmallocwe're back to useless names20:44
elbragstadcompute:flavor:private:list is an example of a policy for protecting an API for listing private flavors20:44
kmallocsub-resource, attribute and subaction should 100% be identified separately/in a distinct way20:45
kmallocthat is awful20:45
kmalloccompute:flavor(private):list would be fine20:45
kmallocbut looking at it, i have to guess contextually that list is the action20:45
kmallocbecause we're now back to things being in arbitrary locations/different levels of split20:45
kmalloccompute:flavor,private:list,subaction20:46
kmallocthat would be a way i'd do it20:46
elbragstadwell - you can propose a patch to change it then if you'd like20:46
kmalloci think i missed that part of the convo/review20:46
kmalloci would have -2'd it as is20:46
kmallocthat is, imo, worse than what we have now20:47
kmallocpre-normalization20:47
* kmalloc sighs20:47
kmalloci 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
kmallocs/don't care/don't have enough bandwidth/20:47
kmallocmy level of willingness to fight open source political battles is pretty low20:48
kmallocand it is emotional bandwidth not code-writing-evaluating stuff20:48
elbragstadkmalloc no one is fighting with you, it was simply an oversight and not intention20:50
kmallocsee the PM.20:50
*** ayoung has joined #openstack-keystone20:55
*** imus has quit IRC20:56
ayoungelbragstad, 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
elbragstadayoung it's not really what i think... i'm working on what operators are asking for21:05
ayoungelbragstad, what is the motivation?21:06
elbragstadconsistency across services and apis21:06
*** raildo has quit IRC21:08
*** erus has quit IRC21:09
*** aojea has joined #openstack-keystone21:10
*** dnguyen has quit IRC21:40
*** dnguyen has joined #openstack-keystone21:41
*** aojea has quit IRC21:42
*** itlinux has quit IRC22:05
*** aojea has joined #openstack-keystone22:11
*** erus has joined #openstack-keystone22:19
*** aojea has quit IRC22:37
*** pcaruana has quit IRC23:10
*** dnguyen has quit IRC23:28
*** rcernin has joined #openstack-keystone23:43
*** rcernin has quit IRC23:51
*** itlinux has joined #openstack-keystone23:52
*** gyee has quit IRC23:55

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