16:00:02 <lbragstad> #startmeeting policy
16:00:03 <openstack> Meeting started Wed Jan 10 16:00:02 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:07 <openstack> The meeting name has been set to 'policy'
16:00:09 <lbragstad> ping raildo, ktychkova, rderose, htruta, hrybacki, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan_he, ayoung, kmalloc, raj_singh, johnthetubaguy, knikolla, nhelgeson
16:00:17 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-meeting
16:00:19 <cmurphy> o/
16:00:20 <edmondsw> o/
16:00:22 <lbragstad> o/
16:00:31 <lbragstad> so - we don't have anything on the agenda
16:00:36 <lbragstad> #topic open discussion
16:00:49 <lbragstad> but we can open it up in case anyone has topics
16:03:04 <edmondsw> don't everyone talk at once... ;)
16:03:14 <lbragstad> :)
16:03:32 <lbragstad> just fyi - in case anyone finds this interesting
16:03:42 <lbragstad> i'm refactoring all the system scope patches
16:03:50 <lbragstad> specifically the bits for role assignments
16:04:07 <lbragstad> so that we don't use ?scope.system as a boolean
16:05:06 <lbragstad> i should have those ready for review by eod
16:05:10 <lbragstad> i'm hoping
16:05:14 <lbragstad> but that's all i have
16:06:45 <cmurphy> lbragstad: you brought up some questions at yesterday's meeting but i don't think edmondsw was there, do you want to bring it up again now?
16:06:57 <lbragstad> sure - we can go through those
16:07:17 <edmondsw> what'd I miss?
16:07:37 <lbragstad> edmondsw: you know how the policy objects have an attribute for scope_types now?
16:07:58 <edmondsw> yeah
16:08:18 <lbragstad> i took a stab at trying to define those for all resources keystone owns
16:08:35 <lbragstad> #link https://review.openstack.org/#/q/topic:add-scope-types+(status:open+OR+status:merged)
16:09:13 <lbragstad> in doing so, it became apparent that different behaviors will be expected depending on the scope_types used in the request
16:09:32 <edmondsw> yes
16:09:33 <lbragstad> i attempted to highlight each of these cases with a FIXME https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py
16:09:36 <lbragstad> #link https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py
16:09:56 <lbragstad> yesterday, i brought it up during the keystone meeting to figure out how we should go about handling those
16:10:21 <lbragstad> (does each one get a bug report, do all FIXMEs for a single resource get tracked for a bug, how do we want to organize the scope check code in keystone, etc..)
16:10:23 <edmondsw> this was one of the things I brought up in Austin, I believe...
16:10:25 <edmondsw> :)
16:11:40 <lbragstad> the TL;DR at the end of the meeting was that we should filter some of the context information and policy information down to the managers (since this is essentially business logic)
16:11:49 <edmondsw> you might want a blueprint to tackle those across keystone, or just start picking away at them under an existing blueprint, rather than try to file 100 bugs
16:12:25 <lbragstad> yeah - yesterday we said pretty much the same thing, but instead of a blueprint, use a single bug "Fix all scope types for projects"
16:12:37 <lbragstad> and that patch would address all FIXMEs in #link https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py
16:13:12 <edmondsw> I guess even with a single bug could use multiple patches to fix it
16:13:20 <lbragstad> sure
16:13:40 <edmondsw> yep, will be very happy to see that fixed
16:13:51 <lbragstad> but it wouldn't require a bug for a the FIXME on line 20 and another bug for the FIXME on line 32, etc...
16:14:03 <edmondsw> yeah, that would get onerous
16:14:07 <lbragstad> right..
16:14:16 <lbragstad> so - that's what we talked about yesterday
16:14:22 <edmondsw> cool, tx for the recap
16:14:29 <lbragstad> but i expect each review to generate some discussion
16:14:39 <knikolla> makes sense
16:14:40 <lbragstad> at least for the resources that can be operated on with project scope and system scope
16:15:15 <lbragstad> but... i'm hoping folks review so we can accurately document the behavior we want for each scope in the fixme
16:15:31 <lbragstad> when the patch merges, i'll open a bug report for the resource and all of it's fixmes
16:16:00 <lbragstad> which should make it easier to divvy up work
16:16:30 <lbragstad> but things like:
16:16:33 <lbragstad> #linkhttps://review.openstack.org/#/c/525695/
16:16:35 <lbragstad> #link https://review.openstack.org/#/c/525695/
16:16:41 <lbragstad> and #link https://review.openstack.org/#/c/525696/
16:16:51 <lbragstad> should be pretty easy, since they only deal with system scope
16:17:42 <lbragstad> (so not every review will generate a bug, which is good)
16:18:57 <lbragstad> thoughts, comments, questions, or concerns?
16:20:49 <edmondsw> when I flip on the scope enforcement, will it treat someone with a project-scoped token for the admin project as if that was a system-scoped token?
16:21:25 <lbragstad> i haven't written any code that makes that mapping
16:21:46 <lbragstad> but if someone has a policy that looking for the admin project and allows it for a policy, then it would work
16:22:37 <edmondsw> without a warning? e.g. I don't want log warnings if I use an admin-project-scoped token to create an endpoint in the catalog
16:23:13 <edmondsw> at least I don't think I do... maybe I do?
16:23:24 <lbragstad> oslo policy issues the warning, but it doesn't understand the admin_project
16:23:45 <knikolla> probably when we deprecate admin project?
16:23:56 <lbragstad> it just attempts to look at the context passed in and determine project scope or system scope
16:24:26 <lbragstad> and then compares that to the scope_types of the policy being enforced
16:26:56 <edmondsw> I'm sorry I haven't kept up... but one of the things we talked about in Sydney was the need for clients (e.g. Horizon) to be able to do a variety of things with a single token, rather than have to get a differently-scoped token for everything
16:26:59 <edmondsw> is that supported?
16:27:39 <lbragstad> not - it isn't supported today.. but i do have an item on my list of things to do to write a PoC for a capabilities API
16:27:44 <edmondsw> e.g. see all VMs in all projects with a single request
16:28:15 <edmondsw> how would a capabilities API help?
16:28:17 <lbragstad> s/not/no/
16:28:27 <edmondsw> I think that solves a different problem
16:28:44 <edmondsw> WHAT can I do vs. ALLOW me to do
16:28:55 <lbragstad> well - it depends on how it is implemented
16:29:29 <lbragstad> you could have the capabilities API return operations and have scope_types be part of that
16:31:50 * lbragstad is open to suggestions here
16:31:52 <edmondsw> maybe horizon could get a project-scoped token for a domain that includes all projects if they want to list VMs in all projects with a single request... but nova would have to understand that that project-scope is the top-level domain
16:32:04 <lbragstad> yes
16:32:13 <lbragstad> in my mind, that's how it makes sense
16:32:14 <edmondsw> which would be tricky
16:33:13 <lbragstad> in order to do that, we'd need to get the hardcoded 'admin' role checks fixed
16:33:52 <edmondsw> that too, but I'm worried about how nova would know which project is the top-level project
16:34:13 <edmondsw> and all deployments would need to have a top-level project (domain)
16:34:26 <lbragstad> they'd need to make a callback to keystone?
16:34:35 <lbragstad> or get that information in middleware somehow?
16:34:59 <lbragstad> (a similar pattern is going to exist with the unified limit work)
16:35:02 <edmondsw> wait, what do we set as the parent for a top-level domain today?
16:35:08 <edmondsw> there's a hidden root domain, right?
16:35:30 <lbragstad> yes - but i think it is hidden to other services
16:35:46 <lbragstad> i don't think we actually expose it?
16:35:48 <edmondsw> we would need nova, etc. (or oslo_policy?) to understand that is the root so if someone has a token scoped to that they can do things across all projects
16:36:56 <edmondsw> I guess we also have the issue of what if someone is scoped to a domain that is not top-level, and wants to list all VMs anywhere in that domain. Or at any other level in the hierarchy... nova/etc. have to understand hierarchy
16:37:10 <lbragstad> yeah...
16:37:12 <edmondsw> ugh
16:37:13 <lbragstad> that's the idea
16:37:41 <lbragstad> which is going to be hard to do, but seems like the proper way to implement it
16:37:47 <edmondsw> yeah
16:38:33 <edmondsw> I wonder if anyone will actually use system scoping until all that is addressed
16:38:34 <lbragstad> this is what drove a lot of the questions i had yesterday
16:38:46 <lbragstad> that's another good question
16:39:14 <lbragstad> my guess is that people can use it for things that don't fall in the gray area between system scope and project scope
16:39:54 <lbragstad> (e.g. using system scope to have cloud administrator manage endpoints/services)
16:40:08 <lbragstad> or granting someone a reader role on the system
16:41:33 <lbragstad> but yeah - all of this certainly becomes more useful when we start working the hierarchy (if present) into the service
16:42:23 <edmondsw> yeah
16:42:40 <lbragstad> at the same time, there is only so much code you can write in a release :)
16:42:47 <edmondsw> no ;)
16:43:16 <edmondsw> yeah, hopefully you've made a good stab at things
16:43:25 <edmondsw> and we can build on it
16:43:31 <lbragstad> right - and that's my hope
16:43:42 <lbragstad> i'd like to get a good idea of this built out in keystone
16:43:46 <lbragstad> and start tackling it in nova
16:43:58 <lbragstad> then i'm hoping others will catch on and carry the model into their own projects
16:45:52 <edmondsw> I'd suggest building things out in keystone and nova in parallel, since they are pretty different
16:46:07 <edmondsw> will help us do things in a way that will work for both
16:46:15 <lbragstad> yeah
16:46:25 <lbragstad> i'll need to sit down with a few nova folks
16:46:40 <lbragstad> but that would be a good topic for the PTG
16:46:44 <edmondsw> yep
16:46:51 <lbragstad> cross project topic*
16:47:19 <edmondsw> and we went from having nothing to talk about to taking 45 minutes :)
16:47:26 <lbragstad> ++
16:48:11 <lbragstad> it sounds like we're all on the same page with the scope-types stuff
16:48:58 <edmondsw> I hope so
16:49:07 <edmondsw> I haven't been able to keep up with the reviews
16:51:17 <lbragstad> well - any feedback will be appreciated
16:51:37 <lbragstad> and there are some easy ones up
16:52:01 <edmondsw> the easy ones probably aren't the ones where my feedback would be valuable :)
16:52:24 <lbragstad> projects, role assignments, credentials
16:52:25 <edmondsw> honestly, I'm probably limited to attending this meeting at the moment
16:52:33 <edmondsw> just too much on my plate
16:52:42 <lbragstad> that's understandable
16:53:45 <lbragstad> anything else we want to discuss?
16:54:42 <edmondsw> it from me
16:55:33 <lbragstad> cool - well thanks for the time
16:55:42 <lbragstad> #endmeeting