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