19:00:53 <lbragstad> #startmeeting keystone-office-hours
19:00:55 <openstack> Meeting started Tue Dec  5 19:00:53 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:58 <openstack> The meeting name has been set to 'keystone_office_hours'
19:07:06 <cmurphy> o/
19:12:32 <lbragstad> i need to get up to speed on https://review.openstack.org/#/c/522461/
19:15:08 <cmurphy> lbragstad: this one goes with that one https://review.openstack.org/#/c/523005/
19:15:25 <lbragstad> i just noticed that, too
19:15:37 <lbragstad> getting up to speed on https://review.openstack.org/#/c/523005 first
19:17:36 <lbragstad> aha- ok
19:17:50 <lbragstad> nevermind, i think i was getting things mixed up
19:18:08 <lbragstad> we should be able to remove https://review.openstack.org/#/c/523005
19:18:16 <lbragstad> s/remove/merge/
19:18:31 <gagehugo> o/
19:18:37 <lbragstad> because it's only removing the usage of those configuration options and removing a couple things we don't need anymore
19:18:52 <lbragstad> which can be done before we deprecate those configuration options
19:19:25 <cmurphy> right it's just removing a function that never gets called
19:19:33 <kmalloc> i don't understand how someone might still be using it in v3?
19:19:40 <kmalloc> lbragstad: the memberid thing
19:20:21 <lbragstad> approving https://review.openstack.org/#/c/523005/
19:20:28 <cmurphy> ensure_default_role() gets called in bootstrap which creates the _member_ role
19:20:54 <cmurphy> that's the only place it's actually used
19:22:49 <lbragstad> yeah - iiuc a deployment can run bootstrap and then start using the member id with v3 assignments, and not even expose v2.0 in the deployment
19:26:10 <lbragstad> cmurphy: edmondsw boostrap was designed to be idempotent for recovery cases
19:27:23 <lbragstad> so it could be used outside of install day activities
19:27:52 <edmondsw> lbragstad how so?
19:28:08 <edmondsw> what kind of recovery?
19:28:20 <cmurphy> losing the _member_ role could be recovered from without bootstrap
19:28:39 <lbragstad> if an admin user is deleted, i think
19:28:53 <lbragstad> we had a commit a while back to do this, let me see if i can dig up the context
19:29:05 <edmondsw> to cmurphy's point, I don't think this bit about _member_ would be needed for that case
19:31:53 <lbragstad> https://bugs.launchpad.net/keystone/+bug/1647800
19:31:53 <openstack> Launchpad bug 1647800 in OpenStack Identity (keystone) newton "keystone-manage bootstrap isn't completely idempotent" [High,Fix released] - Assigned to Lance Bragstad (lbragstad)
19:33:30 <lbragstad> that specific example is for running bootstrap during an upgrade
19:33:54 <lbragstad> maybe it's irrelevant
19:34:42 <cmurphy> lbragstad: what would you like to see in 522461? you want bootstrap to keep creating the role?
19:35:35 <lbragstad> i guess i wanted to make sure we didn't break anything if we wanted to remove it
19:35:44 <lbragstad> outside of the new install case
19:35:51 <cmurphy> my main worry is in deployment tool CI
19:36:08 <lbragstad> i was trying to think of times bootstrap gets run outside of new-install cases
19:36:23 <lbragstad> and i vaguely remembered that change, but it might not be relevant
19:36:31 <cmurphy> on upgrade cases people are reading the release notes anyways
19:36:40 <cmurphy> so they'll know if they have to do something different
19:37:37 <openstackgerrit> Merged openstack/oslo.policy master: Handle deprecation of inspect.getargspec  https://review.openstack.org/521979
19:43:45 <openstackgerrit> Colleen Murphy proposed openstack/keystone master: Handle deprecation of inspect.getargspec  https://review.openstack.org/525740
19:46:43 <lbragstad> fwiw - we'll have a new version of oslo.policy soon https://review.openstack.org/#/c/525623/1
19:48:40 <lbragstad> so all https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:add-scope-types should start passing
19:50:57 <cmurphy> \o/
19:57:39 <lbragstad> opinion time - do we want to hold off on https://bugs.launchpad.net/keystone/+bug/1689644 until we do microversions officially?
19:57:39 <openstack> Launchpad bug 1689644 in OpenStack Identity (keystone) "Keystone does not report microversion headers" [Medium,In progress] - Assigned to Rohan Arora (ra271w)
19:58:24 <lbragstad> knikolla: you said you have something locally for https://bugs.launchpad.net/keystone/+bug/1291157 right?
19:58:24 <openstack> Launchpad bug 1291157 in OpenStack Identity (keystone) "idp deletion should trigger token revocation" [Medium,In progress] - Assigned to Lance Bragstad (lbragstad)
19:58:57 <knikolla> lbragstad: yes, rebased the old review, now getting it to pass tests
19:59:11 <lbragstad> knikolla: awesome
19:59:18 <lbragstad> knikolla: thanks for picking that up
19:59:59 <cmurphy> lbragstad: i think that bug is not really valid, if/when we do microversions then a condition of that being done is having microversion headers
20:00:01 <lbragstad> we can probably close out https://bugs.launchpad.net/keystone/+bug/1662623 today
20:00:01 <openstack> Launchpad bug 1662623 in OpenStack Identity (keystone) "Testing keystone docs are outdated" [Wishlist,In progress] - Assigned to Lance Bragstad (lbragstad)
20:00:22 <lbragstad> cmurphy: yeah... after all the ms discussions, i inclined to agree with you
20:00:53 <lbragstad> i'm inclined*
20:01:29 <lbragstad> cmurphy: close with a comment?
20:02:08 <cmurphy> sure
20:06:40 <openstackgerrit> Colleen Murphy proposed openstack/keystone master: WIP Add Application Credentials manager  https://review.openstack.org/524747
20:06:40 <openstackgerrit> Colleen Murphy proposed openstack/keystone master: WIP Add Application Credentials controller  https://review.openstack.org/524423
20:06:41 <openstackgerrit> Colleen Murphy proposed openstack/keystone master: WIP Add application credential auth plugin  https://review.openstack.org/525346
20:08:17 <lbragstad> another opinion question - what are peoples thoughts on https://bugs.launchpad.net/keystone/+bug/1642988 ?
20:08:17 <openstack> Launchpad bug 1642988 in OpenStack Identity (keystone) "Optionally encode project IDs in fernet tokens" [Wishlist,Triaged] - Assigned to Jose Castro Leon (jose-castro-leon)
20:08:45 <lbragstad> it doesn't impact API behavior
20:09:10 <lbragstad> and it's opt in for deployers to migrate to fernet
20:09:16 <lbragstad> (or jwt eventually)
20:10:10 <lbragstad> i know cern has project ids that vary in format
20:10:19 <gagehugo> is it because of the dashes?
20:10:24 <lbragstad> yeah
20:10:34 <lbragstad> so when the project id get reinflated
20:10:45 <lbragstad> it gets reinflated without the dashes
20:10:51 <lbragstad> but their backend expects it
20:11:40 <lbragstad> s/it/dashes/
20:13:22 <lbragstad> so aa53ea1a-d9f8-11e7-957d-00163e88ac80 instead of abf4be76d9f811e7957d00163e88ac80
20:14:38 <gagehugo> UUID spec says the dashes are optional right?
20:14:58 <lbragstad> that's a good question, i'd have to check
20:16:03 <cmurphy> seems like they could extend the token provider to handle it?
20:16:18 <lbragstad> that was our original suggestion back to them
20:16:19 <ayoung> jamielennox, cmurphy lbragstad can we put oslo-context  to rest? https://review.openstack.org/#/c/523650/
20:16:43 <lbragstad> for example - http://cdn.pasteraw.com/htn79m729bk6wuikvgkwaj96phsozsi
20:18:46 <cmurphy> i'm not seeing whether they objected to that idea
20:19:25 <lbragstad> i don't see KwozyMan or jose-castro-leon online either
20:19:49 <cmurphy> ayoung: looking again
20:20:05 <ayoung> cmurphy, thanks.  Much smaller now
20:20:26 <lbragstad> ayoung: once we get a new version of oslo.policy - https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:add-scope-types should start passing
20:20:51 <ayoung> lbragstad, cool.  THe policy patch got approved, right?
20:21:01 <lbragstad> oslo.policy patch?
20:21:02 <lbragstad> yes?
20:21:03 <gagehugo> yeah I like the token provider extension
20:21:16 <lbragstad> ayoung: waiting on https://review.openstack.org/#/c/525623/1
20:21:32 <lbragstad> cmurphy: gagehugo we should update the bug report then
20:21:39 <ayoung> lbragstad, of course....
20:21:42 <gagehugo> ok
20:21:59 <ayoung> lbragstad, needs one more +2?
20:22:12 <lbragstad> from requirements, yes
20:22:14 <lbragstad> i think so
20:24:48 <ayoung> lbragstad, I only saw a requirements-stable-core group there, but it is roughly the same set of reviewers
20:25:06 <ayoung> dims, can you +2 A that one
20:25:13 <ayoung> https://review.openstack.org/#/c/525623/1
20:25:18 <lbragstad> ayoung: i think dims is at kubecon this week
20:25:28 <lbragstad> participating in container-things
20:25:32 <ayoung> almost certainly
20:26:19 <lbragstad> ayoung: you weighed in on https://bugs.launchpad.net/keystone/+bug/1642988 once
20:26:19 <openstack> Launchpad bug 1642988 in OpenStack Identity (keystone) "Optionally encode project IDs in fernet tokens" [Wishlist,Triaged] - Assigned to Jose Castro Leon (jose-castro-leon)
20:26:36 <lbragstad> think that is too specific to carry upstream?
20:34:10 <lbragstad> cmurphy: wxy fwiw - i'm going to try and spend the last hour of office hours proposing the rest of https://review.openstack.org/#/c/524657/
20:35:34 <lbragstad> oh - actually, it looks like wxy propose a version of that specification with limit IDs
20:55:47 <lbragstad> kmalloc: cmurphy wxy question on unified limits
20:55:58 <lbragstad> we have registered limits and project limits
20:56:06 <kmalloc> yeah
20:56:19 <lbragstad> thoughts on splitting them into their own specs?
20:56:26 <cmurphy> why?
20:56:48 <lbragstad> well - registered limits needs to be done first regardless
20:56:48 <kmalloc> why?
20:56:54 <kmalloc> what cmurphy said
20:56:55 <kmalloc> :P
20:56:57 <lbragstad> because project limits always act as overrides?
20:57:14 <cmurphy> do registered limits have any value if there isn't also project limits?
20:57:29 <lbragstad> kinda the other way around IMO
20:57:39 <kmalloc> i don't think anyone would use registered limits without project limits
20:58:09 <lbragstad> you can't use project limits with a registered limit, at least that how i understand things
20:58:16 <ayoung> cmurphy, TYVM
20:58:28 <cmurphy> ayoung: YW
20:58:52 <cmurphy> lbragstad: you need to have a registered limit in order for the project limit to override it
20:59:06 <cmurphy> project limits are invalid if there's nothing registered
20:59:06 <lbragstad> oh - sorry, s/with/without/
20:59:10 <lbragstad> yes
20:59:11 <cmurphy> oh yes
20:59:23 <lbragstad> i'm bad at typing lately
20:59:26 <cmurphy> lol
20:59:50 <cmurphy> registered limits have to be done first yes but they're not useful without project limits
21:00:05 <lbragstad> yeah
21:00:34 <lbragstad> ok - so another question
21:00:42 <lbragstad> project limits will always require a project
21:00:55 <kmalloc> yes
21:00:56 <lbragstad> do we put the project in the request body or the path?
21:01:13 <kmalloc> eh, either/or
21:01:20 <lbragstad> POST /limits/{project_id} or just POST /limits with the project id in the body
21:01:54 <cmurphy> i think POST /limits is more rest-y?
21:01:59 * cmurphy looks up guidelines
21:01:59 <kmalloc> cmurphy: ++
21:02:11 <kmalloc> the get /limits/{project_id} is the reference to the id
21:02:20 <lbragstad> ok - that current proposal im reviewing has POST /limits with option project id in the request body
21:02:26 <kmalloc> yeah
21:02:28 <kmalloc> that sounds fin
21:02:29 <kmalloc> e
21:02:32 <cmurphy> yeah that makes sense to me
21:02:34 <lbragstad> ok
21:02:35 <lbragstad> cool
21:04:16 <lbragstad> actually, the current proposal uses the project id from the request context...
21:04:21 <lbragstad> which makes sense, too
21:06:11 <kmalloc> that is also fine
21:06:22 <kmalloc> but the post with the body makes more sense
21:06:36 <kmalloc> since switching scope ... may be painful
21:06:52 <kmalloc> especially with say... admin RBAC future looking
21:07:03 <cmurphy> yeah i feel like it should be explicit in the body
21:09:11 <cmurphy> anyone want to push https://review.openstack.org/#/c/524882 through (or know why that happens?)
21:16:32 <lbragstad> cmurphy: done - and that also beats me
21:16:38 <lbragstad> seams like a system level thing?
21:16:48 <lbragstad> https://review.openstack.org/#/c/523524/ will close a bug
21:17:30 <cmurphy> yeah it's something to do with the os, i wasn't able to reproduce it but it was seen in ci and by mordred
21:18:10 <cmurphy> lbragstad: you keep linking that and i always click on it and then i'm sad i can't help :'(
21:18:18 <lbragstad> lol
21:18:42 <lbragstad> regardless - thanks for the review cmurphy
21:18:47 <cmurphy> :)
21:18:57 <lbragstad> it's the thought that counts, amiright?!
21:19:03 <cmurphy> lol
21:20:30 <cmurphy> lbragstad: re service_type/service_id see my and wxy's comments on https://review.openstack.org/#/c/455709/13/specs/keystone/queens/limits-api.rst
21:20:36 <cmurphy> service_type isn't guaranteed unique
21:22:52 <mordred> cmurphy: what did I do?
21:23:19 <cmurphy> mordred: the +00:00 thing
21:23:45 <lbragstad> ?!
21:23:55 <mordred> oh - that
21:24:03 <mordred> JEEZ don't even get me started on that
21:25:21 <lbragstad> i thought services had type built into the unique constraint
21:26:10 <cmurphy> i don't think so http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/sql/migrate_repo/versions/067_kilo.py#n115
21:26:25 <lbragstad> bah
21:26:41 <lbragstad> that kinda sucks
21:27:01 <cmurphy> http://paste.openstack.org/show/628219/
21:28:26 * lbragstad sigh
21:32:34 <lbragstad> it looks like i can abandon my follow on to that spec then
21:33:05 <mordred> cmurphy, lbragstad: I know of at least one existing deployment with non-unique service types - as much as it drives me completely bonkers
21:33:13 <mordred> I'd, of course, argue that it SHOULD be unique
21:33:40 <mordred> and that people with non-unique service types are making the world a terrible place
21:34:01 * lbragstad waits for the "this is why we can't have nice things" rant
21:34:23 <cmurphy> lbragstad: yeah i thnk all work can be done in the original spec
21:34:32 <lbragstad> sweet
21:35:16 <mordred> lbragstad: I figure everyone knows that rant by now ...
21:51:45 <kmalloc> mordred: so.. i agree
21:51:51 <kmalloc> unfortunately...
21:51:59 <kmalloc> mordred: it's an API break if we change that >.<
21:52:19 <kmalloc> mordred: i don't think many people would disagree about service-types need to be unique
22:00:03 <lbragstad> #endmeeting