16:00:19 <lbragstad> #startmeeting policy
16:00:19 <openstack> Meeting started Wed Jul 19 16:00:19 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:23 <openstack> The meeting name has been set to 'policy'
16:00:30 <lbragstad> ping raildo, ktychkova, rderose, htruta, hrybacki, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, morgan, raj_singh, johnthetubaguy, knikolla, nhelgeson
16:00:41 <lbragstad> in case anyone is around
16:00:53 <edmondsw> o/
16:01:04 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:01:07 <lbragstad> agenda ^
16:01:07 <gagehugo> o/
16:01:11 <blancos> o/
16:01:14 <lamt> o/
16:01:16 * morgan lurks
16:01:31 <lbragstad> alright - let's go ahead and get started
16:01:36 <lbragstad> #topic open discussion
16:01:37 <lbragstad> :)
16:01:58 <lbragstad> we don't have anything on the agenda - which i think is fine since a lot of folks are focused on finishing up feature work
16:02:18 <lbragstad> but we can certainly have open discussion
16:02:33 <edmondsw> I'm seeking another +2 on https://review.openstack.org/#/c/482359/
16:03:30 <edmondsw> pretty bad bug we introduced in pike with our policy changes
16:03:55 <lbragstad> yeah - we should get that into pike for sure
16:04:01 <lbragstad> (no release note needed)
16:04:14 <edmondsw> right... it worked before, and it will work again once we get this change merged
16:05:18 <lbragstad> something else i wanted to run by the group before I start working on it
16:05:23 <lbragstad> #link https://review.openstack.org/#/c/464763/
16:05:30 <lbragstad> ^ so that's the specification for global roles
16:05:38 <lbragstad> which i have a wip implementation up for
16:06:11 <lbragstad> and this question is an implementation detail, but how do we want to denote global scope in the request for a token?
16:06:15 <lbragstad> anyone have ideas there?
16:07:09 <lbragstad> cc morgan ^
16:07:11 <edmondsw> "scope": {"global": True} ?
16:07:24 <morgan> hm
16:07:30 <morgan> i don't know if we need to do that
16:07:34 <lbragstad> edmondsw: yeah - that's was samueldmq said too https://review.openstack.org/#/c/464763/15/specs/keystone/backlog/global-roles.rst
16:07:39 <morgan> but i'm fine with it
16:07:50 <edmondsw> morgan why wouldn't we need to?
16:07:52 <morgan> do we explicitly say we will always have a scope block?
16:07:59 <morgan> if we don't, we could just omit the scope block
16:08:11 <edmondsw> morgan no, can't do that... there is a difference between globally-scoped and unscoped
16:08:13 <morgan> or empty scope = global
16:08:26 <morgan> no roles = unscoped
16:08:39 <edmondsw> ?
16:08:44 <lbragstad> no global roles == unscoped?
16:08:46 <edmondsw> you don't specify roles on a token request
16:08:58 <morgan> wait for in the requesT?
16:09:03 <morgan> oh wait i was thinking in the response
16:09:14 <lbragstad> morgan: yeah the request
16:09:23 <morgan> sure we can do global = true
16:09:33 <morgan> not a huge fan of it, but i can
16:09:37 <morgan> 't  think of a better way
16:09:42 <edmondsw> same here
16:09:44 <lbragstad> yeah - i couldn't really either
16:09:49 <lbragstad> and samueldmq said the same thing
16:10:07 <lbragstad> it's also pretty consistent with scoping to a domain or project
16:10:15 <morgan> hm.
16:10:27 <morgan> i don't like it needing to be explicitly "true"
16:10:47 <lbragstad> morgan: would you prefer "scope": "global" ?
16:10:49 <morgan> what happens if you scope: {project: xxxxx, global: true}
16:10:51 <edmondsw> "scope": {"type": "global"} ?
16:10:58 <morgan> edmondsw: that would be better
16:11:04 <lbragstad> morgan: i would say that is a 4XX
16:11:12 <edmondsw> lbragstad +1
16:11:23 <morgan> actually that more accurately dictates what i want to implement in a more generic auth route
16:11:24 <lbragstad> that'd be like scoping to a project and a domain at the same time
16:11:28 <morgan> s/dictates/mirrors
16:11:52 <morgan> lbragstad: ^ what edmondsw suggested looks way better
16:11:56 <morgan> type: "global"
16:12:09 <lbragstad> morgan: ok - so how would we convert that to support projects and domain?
16:12:15 <lbragstad> you'd have to supply an ID with it
16:12:25 <morgan> we could support type: project, id: XXXX
16:12:26 <edmondsw> lbragstad I'm not following
16:12:40 <edmondsw> just leave projects and domains as they are
16:12:41 <morgan> but we wouldn't change anything for project/domain scoping today
16:12:42 <lbragstad> morgan: yeah - project would require another field in the request for the id
16:12:51 <edmondsw> i.e., type isn't required for them
16:12:58 <morgan> edmondsw: ++
16:12:59 <lbragstad> right
16:13:14 <morgan> if we do an iteration on auth to move it to /auth (See backlog) we can make type required there
16:13:17 <lbragstad> it would be a little weird to have the inconsistency - but i do see the reason for it
16:13:17 <edmondsw> oh, are we talking about the response now?
16:13:30 <lbragstad> i'm still focused on the request
16:13:34 <morgan> lbragstad: we could support both mechanisms
16:13:39 <morgan> and i'd just support it
16:13:43 <edmondsw> so yeah, no changes to project or domain-scoped requests, I think
16:13:46 <morgan> type: "project", id: XXX
16:13:49 <morgan> would be trivial to add it
16:13:53 <morgan> but not needed
16:14:00 * lbragstad grabs an etherpad
16:14:08 <morgan> we would continue to support "project: id-xxxxx"
16:14:20 <lbragstad> #link https://etherpad.openstack.org/p/keystone-global-roles-scratchpaper
16:14:26 <edmondsw> if you did want to support type: "project" on /auth, you'd still need a project: {} block, not just an id, so it could be a name and domain name, etc.
16:14:47 <edmondsw> as it is today
16:16:38 <morgan> lbragstad: so, i think we always accept type
16:16:45 <morgan> but it's optional for project/domain,
16:16:50 <morgan> ?
16:16:53 <morgan> *shrug*
16:16:56 <edmondsw> yep
16:17:30 <lbragstad> ok - so the top three are already implemented
16:17:39 <lbragstad> and we have to support those
16:18:13 <morgan> really? we support "scoped": "unscoped"?!
16:18:16 <morgan> *sigh*
16:18:18 <lbragstad> yeah....
16:18:19 <morgan> wow that is terrible
16:18:21 <edmondsw> ugh
16:18:25 <morgan> what the hell.
16:18:30 <edmondsw> I thought unscoped was just not specifying the scope block
16:18:32 <morgan> when did that creep in?
16:18:38 <lbragstad> a long time ago
16:18:43 <lbragstad> i spent a day trying to figure it out
16:18:50 <edmondsw> can you also just not specify the scope block?
16:18:53 <lbragstad> edmondsw: right
16:19:00 <edmondsw> ok, I didn't imagine that, at least
16:19:01 <morgan> ok so we could do "scope": "global"
16:19:04 <lbragstad> edmondsw: but not if the user has a default project and a role on that default project
16:19:06 <morgan> *sobs"
16:19:16 <edmondsw> oh, default projects... ugh...
16:19:23 <edmondsw> that's a v2 thing, right? So we can get rid of it soon?
16:19:25 <morgan> yeah default projects should have died
16:19:26 <morgan> no
16:19:28 <morgan> it's also in v3
16:19:30 <edmondsw> boo
16:19:35 <lbragstad> well - kind of
16:19:39 <morgan> yeah.. lets just... pretend it isn't
16:19:40 <morgan> for now
16:19:41 <lbragstad> it's in v3 enough to be a pain
16:19:44 <edmondsw> lol
16:19:53 <lbragstad> it's kinda there but not really...
16:20:01 <lbragstad> it certainly wasn't a clean break
16:20:21 <edmondsw> keystone v4! with new auth! ;)
16:20:25 <morgan> edmondsw: actually
16:20:31 <morgan> v4, no auth in /v4
16:20:33 <lbragstad> let's do it
16:20:43 <edmondsw> morgan that was just to get your reaction :P
16:20:51 <morgan> and i'm being serious
16:20:54 <lbragstad> edmondsw: we're already sold on it
16:21:04 <edmondsw> yeah, I know
16:21:28 <lbragstad> morgan: i have a post it on my monitor to try and write up what we discussed in atlanta
16:21:36 <morgan> yeah
16:21:36 <edmondsw> I guess default projects aren't really part of the auth API, so they could go away in v4?
16:22:06 <morgan> edmondsw: no, they could be removed in a new auth version
16:22:09 * edmondsw thinks this is more like a keystone meeting than a policy meeting
16:22:12 <morgan> anyway
16:22:21 <morgan> there is't much in policy atm to talk about
16:22:22 <morgan> anyway
16:22:25 <lbragstad> since it's a major revision - it could go away
16:22:48 <lbragstad> yeah - this is helpful, i mostly wanted to try and figure out what it would look like for requesting a global token
16:23:15 <morgan> so lets *not* do scope: global
16:23:23 <morgan> lets do scope { type: global }
16:23:28 <morgan> it is *more* consistent
16:23:57 <lbragstad> if we went the type route eventually - we would need to port the existing project and domain scoping to it
16:24:06 <morgan> trivial to do so
16:24:20 <morgan> type supersedes non-specified project block
16:24:36 <edmondsw> if we have "scope": "unscoped" should we just have "scope": "global" instead of "scope": {"type": "global"} ?
16:24:49 <morgan> allowing scope { type: project, project: {id: xxx}, domain: {id: yyy}}
16:25:03 <morgan> and we would support type: unscoped
16:25:19 <morgan> oh fff.
16:25:23 <morgan> this is not discoverable
16:25:29 <morgan> *sigh*
16:25:49 <morgan> edmondsw: i would prefer to add support for type: unscoped
16:25:57 <morgan> than more non-dict forms of the scope-key
16:25:58 <edmondsw> morgan fine by me
16:26:03 <edmondsw> yeah
16:26:14 * morgan notes we need to make this discoverable
16:26:21 <morgan> but that is a separate issue.
16:26:49 <edmondsw> morgan now you have me concerned about how we make this discoverable...
16:26:49 <lbragstad> morgan: which part specifically isn't discoverable?
16:27:05 <edmondsw> lbragstad that keystone supports global scoping
16:27:26 <morgan> ^^
16:27:32 <lbragstad> bah
16:27:40 <lbragstad> we need a GET /auth/scopes
16:27:42 <lbragstad> endpoint
16:27:58 * morgan grabs laptop to wire up /auth as soon as tests for new-filesystem catalog are done
16:28:48 <morgan> lbragstad: /auth/ having info for this is probably a good place to start.
16:29:36 <lbragstad> the first step for making this discoverable would be allowing keystone to answer "what scopes do you support?"
16:29:37 <lbragstad> right?
16:29:42 <morgan> yeah
16:29:52 <morgan> and i don't want to add that to /v3/auth if that makes sense
16:30:26 <morgan> i mean we can... but i think /v3/auth doesn't actually do anything interesting with a GET right now
16:30:30 <morgan> and no token
16:30:37 <morgan> so, i don't want to change that behavior
16:31:52 <lbragstad> yeah - that's fine
16:32:03 <lbragstad> this feels like something we could do with versionless auth
16:32:08 <lbragstad> or at least start fresh with
16:32:11 <morgan> yeah
16:32:13 <lbragstad> morgan: https://github.com/openstack/keystone/blob/025e844fc485c23be1de033473f3cadd7486b642/keystone/auth/core.py#L231-L244
16:32:28 <morgan> yeah.
16:33:23 <lbragstad> morgan: some of the `unscoped` bits bled into https://github.com/openstack/keystone/blob/025e844fc485c23be1de033473f3cadd7486b642/keystone/auth/schema.py#L56-L61
16:34:04 <morgan> yep
16:34:32 <lbragstad> but - that issues pre-existed our jsonschema validation
16:34:36 <lbragstad> which was done in 2014
16:34:43 <lbragstad> it's been there a while
16:34:45 <morgan> yah
16:34:51 <morgan> anyway
16:35:47 <lbragstad> ok - so in summary
16:36:09 <lbragstad> it sounds like if we do global roles and want to scope globally
16:36:21 <lbragstad> we can do so with "scope": {"type": "global"}
16:36:45 <lbragstad> which would be inconsistent with the rest of how scope is done
16:36:55 <lbragstad> but it would be consistent if/when we do versionless auth
16:38:45 <lbragstad> or - we could do "scope": {"global": "true"} to be more consistent with project and domain scoping
16:40:16 <morgan> sure. but i don't think a different key matters
16:40:18 <morgan> in this case
16:40:27 <morgan> most consistent with current would be "scope": "global"
16:40:31 <morgan> as much as i hate it
16:40:46 <lbragstad> ok - so
16:40:58 <lbragstad> 1.) "scope": {"type": "global"}
16:41:01 <morgan> and that is just because of prior art for unscoped
16:41:12 <lbragstad> 2.) "scope": {"global": "true"}
16:41:17 <lbragstad> 3.) "scope": "global"
16:41:38 <lbragstad> 3 would be the most consistent given the warts with "unscoped"
16:41:45 <morgan> 4<snark>.) "scope": {"global": {"yes_really": True}}
16:42:02 <lbragstad> ++
16:42:09 <morgan> correct, 3 is most consistent with v3 auth
16:42:20 <morgan> 2. is most consistent with other "scoped" operations
16:42:27 <lbragstad> 2 isn't as bad and still offers consistency with project and domain scoping
16:42:40 <morgan> 1 is the best overall option, but is most inconsistent with v3 auth
16:42:41 <lbragstad> but the "global": "true" part doesn't really make much sense
16:43:08 <morgan> so, i vote either 1 or 3
16:43:13 <morgan> i don't like 2 at all
16:43:19 <lbragstad> ok
16:43:26 * lbragstad votes for #4
16:43:44 <lbragstad> i can detail both options in the spec
16:43:51 <morgan> wfm
16:44:17 <lbragstad> cool - i think that's all I had for open discussion
16:44:22 <lbragstad> anyone have anything else?
16:45:55 <lbragstad> alright - looks like we'll get some time back
16:45:57 <lbragstad> thanks all
16:45:58 <lbragstad> #endmeeting