18:00:17 <lbragstad> #startmeeting keystone
18:00:18 <openstack> Meeting started Tue Jan  9 18:00:17 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:21 <openstack> The meeting name has been set to 'keystone'
18:00:23 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he
18:00:31 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:35 <lbragstad> o/
18:00:39 <rderose> o/
18:00:40 <kmalloc> man, is it meeting time already? I just finished my coffee...
18:00:43 <kmalloc> i need more.
18:00:48 <kmalloc> moar!
18:00:49 <kmalloc> ;)
18:00:52 <lbragstad> better refill
18:01:07 <kmalloc> it will take like 6-10m to do so... so, i'll just wait.
18:01:33 <lamt`> o/
18:01:39 <gagehugo> o/
18:01:43 <lbragstad> we'll give folks a minute to join
18:02:13 <samueldmq> hi o/
18:02:53 <spilla> o/
18:04:22 <lbragstad> #topic announcements: PTG planning
18:04:35 <kmalloc> oh my ;)
18:04:43 <lbragstad> now that we're past the holidays - i've started prepping for the PTG
18:04:45 <lbragstad> #link https://etherpad.openstack.org/p/keystone-rocky-ptg
18:04:53 <samueldmq> PTG? When and where?
18:05:02 <lbragstad> last week of february
18:05:03 <lbragstad> in dublin
18:05:11 <samueldmq> Nice
18:05:18 <lbragstad> #link https://www.openstack.org/ptg
18:05:24 <cmurphy> o/
18:05:25 <lbragstad> so - per our usual process
18:05:36 <lbragstad> please don't hesitate to throw topics on the etherpad
18:05:56 <lbragstad> i bootstrapped it with some content, but it certainly isn't full
18:06:11 <jdennis> dublin, sounds like a good venue for someone named Colleen Murphy :-)
18:06:26 <cmurphy> :)
18:06:45 <lbragstad> once we get closer to the PTG - we'll finalize a schedule
18:06:45 <cmurphy> they get confused by my accent there
18:07:17 <lbragstad> all in favor of cmurphy adopting an irish accent for the week?
18:07:19 <lbragstad> o/
18:07:25 <cmurphy> >.<
18:07:56 <gagehugo> o/
18:08:17 <lbragstad> i also have a list of attendance at the top
18:08:30 <lbragstad> if you're planning on being in dublin, please add your name
18:08:43 <lbragstad> I'd like to organize a team dinner of some kind prior to the PTG
18:09:07 <cmurphy> ++
18:09:10 <lbragstad> no big rush there if you're still waiting on approval
18:09:31 <lbragstad> (also, if there is anything i can do to help you get approval, just DM me!)
18:10:04 <lbragstad> #topic announcement: reviews
18:10:33 <lbragstad> just a friendly reminder that feature freeze is in 16 days (not factoring in feature freeze exceptions)
18:11:00 <lbragstad> but given the rc window is only a couple week, i expect very little, if any time, for feature freeze exceptions
18:11:13 <lbragstad> we're going to have to be on the ball with feature work before that deadline
18:11:29 <lbragstad> #link https://releases.openstack.org/queens/schedule.html
18:11:46 <lbragstad> we have four big efforts underway
18:11:50 <lbragstad> unified limits
18:12:01 <lbragstad> #link https://review.openstack.org/#/q/topic:bp/unified-limits+status:open
18:12:09 <lbragstad> application credentials #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/application-credentials
18:12:22 <lbragstad> tons of work to reorganize our documentation
18:12:23 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:api-ref-reorganization
18:12:25 <lbragstad> and system scope work
18:12:30 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope
18:12:47 <cmurphy> does the docs reorg have the same feature freeze deadline?
18:13:00 <lbragstad> it doesn't, we can land that into the RC period
18:13:07 <lbragstad> good point cmurphy
18:13:16 <cmurphy> i guess it's mostly all done/easy reviews anyway
18:13:19 <lbragstad> i did add it to the list because of the volume of patches it generates
18:14:01 <lbragstad> the reorganization is the first box in this epic https://trello.com/c/5WCMxrLg/12-docs-goals-organization
18:14:22 <lbragstad> Suramya has been doing a good job tending to review feedback
18:15:05 <lbragstad> and thanks to samueldmq for the reorganization template
18:15:24 <samueldmq> glad it helped!
18:15:42 <lbragstad> #topic announcement: office hours bugs
18:16:01 <lbragstad> i went through a bunch of bugs and reworked the office-hours list
18:16:06 <lbragstad> #link https://goo.gl/PTd8bp
18:16:25 <lbragstad> feel free to check ^ out if you're interested in picking something up for office hours
18:16:44 <lbragstad> #topic questions about scope_types
18:17:27 <lbragstad> alright - if you haven't noticed, i've been spamming our review queue with a slew of patches that add scope_types to each keystone resource
18:17:38 <lbragstad> this is essentially the other half of the equation for system-scope
18:18:02 <lbragstad> but as i worked through them, i started coming up with more questions and fixmes
18:18:09 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:add-scope-types
18:18:11 <lbragstad> ^ reviews
18:18:18 <lbragstad> #link https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py@32
18:18:28 <lbragstad> ^ that is an example of a question i have concerning both scopes
18:18:33 * lbragstad gives folks a minute to read
18:20:11 <cmurphy> oof hard questions
18:20:17 <lbragstad> yes...
18:20:33 <lbragstad> which is why i'd like to discuss/get advice from you smart people :)
18:20:50 <lbragstad> ideally - keystone is going to have to start doing "scope" checks of its own
18:20:58 <lbragstad> most likely in code
18:21:07 <cmurphy> what does "relevant to that project's position in the hierarchy" mean?
18:21:34 <lbragstad> cmurphy: for example; if A is a project and has a child B which has a child C
18:21:52 <lbragstad> A -> B -> C
18:22:00 <lbragstad> and you're an administrator on project B
18:22:24 <lbragstad> what should happen when you call identity:list_projects with a token scoped to project B?
18:22:55 <gagehugo> would you just see B and C?
18:22:59 <cmurphy> I don't think you can assume the user has a role assignment on C
18:23:31 <lbragstad> ^ that begs another question, but you'll have to check for role inheritance
18:24:56 <lbragstad> if we don't assume a user who is admin on project B has a role on project C, then does that make identity:list_projects a system-only policy?
18:25:45 <cmurphy> I think it is
18:26:18 <cmurphy> if you want just your own projects you use /v3/auth/projects
18:26:24 <lbragstad> if you're a member of a project though, should you be able to get a project?
18:26:36 <lbragstad> that's true
18:26:41 <gagehugo> ah
18:26:51 <lbragstad> so - we have a similar relationship elsewhere
18:26:54 <lbragstad> and that is the service catalog
18:27:22 <lbragstad> (the /v3/endpoint API is system-only but users can still get service catalog information via their token or GET /auth/catalog)
18:28:20 <cmurphy> you can get /v3/projects/{project_id} on your own project
18:28:38 <cmurphy> you just can't get /v3/projects?project_id={project_id}
18:29:07 <lbragstad> so scope_types for GET /v3/projects/{project_id} is going to have to ['system', 'project']
18:29:35 <gagehugo> that makes sense
18:30:21 <lbragstad> if we want to refactor scope checks out of the policy definition (or check_str) and into code, then we'll have to encode that check into keystone
18:32:02 <gagehugo> so keystone would be responsible for that check then?
18:32:22 <kmalloc> fwiw, back to the would you see b+c bit, we never claimed heirarchy is private info
18:32:26 <kmalloc> don't try and make it so.
18:32:35 <kmalloc> it is a big big big headache to do so
18:33:29 <kmalloc> in the a->b->c, you'd see a,b,c
18:33:40 <kmalloc> it just has to be the way it works the current implementation and behaviors
18:33:41 <lbragstad> if you're an admin on A?
18:33:50 <kmalloc> if you're an admin on b, you still see it
18:33:58 <kmalloc> if you're and admin on a you see everything below you
18:34:09 <kmalloc> you can't obscure that without breaking api behavior
18:34:41 <gagehugo> so if you're admin on B you'll see A? or am I misreading this
18:34:42 <kmalloc> we at one point planned to implement it, but that was set aside due to the volume of headaches and issues with name being  unique within a tree, etc
18:34:55 <kmalloc> gagehugo: the hierarchy above/below you is not priviledged info
18:35:02 <kmalloc> so you would see A.
18:35:02 <gagehugo> ah ok
18:35:13 <kmalloc> and C
18:36:08 <lbragstad> hmm
18:36:16 <lbragstad> so - what about identity:get_project
18:36:25 <lbragstad> the policy just above that one
18:36:34 <kmalloc> i think we have a mis-match in behaviors between list and get
18:36:36 <kmalloc> but...
18:36:42 <kmalloc> list has historically been admin
18:36:43 <kmalloc> so....
18:37:01 <lbragstad> if you call it with a system-scoped token and you're an admin, you can get any project
18:37:03 <lbragstad> which makes sense
18:37:16 <kmalloc> that being said, i'd be ok with anyone in the hierarchy being avble to get any project within it (as a project/domain admin)
18:37:19 <lbragstad> but if you're a member of a project and call it with a project-scoped token, what happens?
18:37:24 <kmalloc> system scope is *anything*
18:37:28 <kmalloc> and everything
18:38:06 <kmalloc> if its in your hierarchy, it should work, there is no reason to treat the project structure as priv data if it's above or directly below you.
18:38:23 <kmalloc> mostly likely if you're a project admin anything below you is game for you to see anyway
18:38:38 <kmalloc> and the way the heierarchy works for auth etc, it is important for folks to know where in the tree they are
18:38:46 <kmalloc> i'd let get_project fly in those casesd.
18:39:20 <lbragstad> should a user be able to get /v3/projects/{project_id} if they aren't a member of that project?
18:39:27 <lbragstad> or don't have a role assignment on it?
18:39:38 <kmalloc> if it is above/below the project they're in.
18:39:57 <lbragstad> what if we're talking about flat structures
18:40:06 <kmalloc> peers are not covered
18:40:09 <kmalloc> so, flat is no.
18:40:15 <kmalloc> basically a->b a->q
18:40:19 <kmalloc> b can't see q
18:40:26 <kmalloc> q cant get b
18:40:29 <lbragstad> (all of this is going to have to be coded into keystone somewhere)
18:40:32 <kmalloc> but a can get ba and q
18:40:33 <kmalloc> yes.
18:40:51 <lbragstad> so getting back to my original question, where do we want this type of stuff to live
18:40:52 <lbragstad> ?
18:41:06 <kmalloc> so.
18:41:20 <kmalloc> you're going to have to add the logic into the resource manager
18:41:25 <kmalloc> or we'd break behavior(s)
18:41:39 <kmalloc> because mving to systemscope, you still have to support the current mode of operations
18:41:41 <lbragstad> because it's business logic?
18:41:42 <kmalloc> yeah
18:41:52 <kmalloc> and because it's business logic
18:41:53 <lbragstad> ok - that makes sense
18:42:07 <kmalloc> it's not driver and it's not REQ<->SerializedOutput
18:42:34 <lbragstad> so - that means we're going to need some level of request information in the manager
18:42:44 <lbragstad> and the policy operation, too
18:42:47 <kmalloc> which is doable via the threadlocal request data
18:42:54 <lbragstad> so the managers can reason about it, right?
18:42:56 <kmalloc> or should be if we're using oslo.context correctly
18:42:58 <kmalloc> yeah.
18:43:21 <lbragstad> ok
18:43:25 <kmalloc> this is why it's important to break apart the @protected decorator
18:43:46 <lbragstad> and do policy enforcement inline
18:43:57 <kmalloc> because there are more Policy Enforcement Points because of the system scope and added business logic
18:44:11 <kmalloc> yeah, you need to do some of this in-line. the callback system, etc wont cover it
18:44:23 <kmalloc> but managers can/should be able to look at thread local data
18:44:32 <lbragstad> right - which either bloats the @protected decorator or creates more business logic in the manager
18:44:48 <kmalloc> noooow. we also need to make sure to handle cases where thread local data isn't populated
18:44:53 <kmalloc> aka, keystone-manage bootstrap
18:45:09 <kmalloc> but in 99% of the cases context should be populated from a request
18:45:16 <kmalloc> 99.9
18:45:51 <lbragstad> hmm
18:46:30 <kmalloc> it's a simple edge cased, and the thread local could be populated by keystone-manage bootstrap with something like is_bootstrap=True
18:46:43 <lbragstad> yeah
18:46:49 <kmalloc> so we can dodge it w/o breaking the security model by just passing if context isn't populated sanely
18:47:21 <lbragstad> so - i imagine most reviews in the scope_types topic to generate some discussion like this
18:47:37 <lbragstad> (i've highlighted the bits i see with FIXMEs)
18:47:56 <lbragstad> but this is going to be a pretty significant amount of work
18:48:04 <lbragstad> thoughts on how we should track it?
18:48:19 <lbragstad> bug per FIXME? bug per a resource's FIXMEs?
18:48:34 <kmalloc> either works
18:48:37 <kmalloc> as long as we're tracking it
18:48:49 <kmalloc> i like fewer bugs, but wouldn't argue for per fixme
18:48:58 <lbragstad> ++
18:49:10 <kmalloc> argue against*
18:49:35 <lbragstad> so something like "correct system scope and project scope for the project resource":
18:49:55 <lbragstad> and the fix for it will correct all FIXMEs in https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py
18:52:47 <kmalloc> i like that
18:53:15 <lbragstad> ok - so it sounds like we can discuss the intended behavior of the each resource in review
18:53:20 <lbragstad> document the outcome in FIXMEs
18:53:41 <lbragstad> and then i'll open bugs when they merge pointing to the FIXMEs so that we can track the work
18:54:46 <lbragstad> i think this gives me enough to get started
18:54:57 <lbragstad> #topic open discussion
18:55:18 <lbragstad> floor is open if anyone has anything
18:56:14 <kmalloc> yeah i have a question
18:56:22 <kmalloc> what if you get scared half to death twice?
18:56:33 <kmalloc> *shiftyeyes*
18:56:48 <gagehugo> would you be scared to 3/4th death then total?
18:56:50 <lbragstad> kmalloc: you're not factoring in health regen
18:57:09 <kmalloc> ok ok...
18:57:15 <lbragstad> because gagehugo's factors that in
18:57:16 <lbragstad> :)
18:57:23 <kmalloc> if one syncronised swimmer drowns... do they all follow in suit?
18:57:52 <kmalloc> ok ok i'm done
18:58:16 <lbragstad> alright - time to refill your beverage before office hours!
18:58:22 <lbragstad> thanks for the time folks
18:58:26 <lbragstad> #endmeeting