18:01:54 <lbragstad> #startmeeting keystone 18:01:55 <openstack> Meeting started Tue May 16 18:01:54 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:56 <lbragstad> o/ 18:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:59 <openstack> The meeting name has been set to 'keystone' 18:02:02 <henrynash> hi 18:02:02 <knikolla> o/ 18:02:04 <lamt> o/ 18:02:04 <rderose> o/ 18:02:13 <lbragstad> ping antwash, ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, notmorgan, ravelar, rderose, rodrigods, samueldmq, spilla 18:02:24 <hrybacki> o/ 18:02:25 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:02:29 <edmondsw> o/ 18:02:59 <lbragstad> hopefully everyone had an uneventful trip home from the summit 18:03:35 <ayoung> I did 18:03:48 <lbragstad> ayoung: i would hope so! 18:04:06 <lbragstad> i bet knikolla's 20 minute walk was brutal 18:04:12 <ayoung> hrybacki, edmondsw want to be added to the ping list? 18:04:21 <knikolla> lbragstad: you bet, haha. 18:04:29 <hrybacki> ayoung: I'm on it already :) 18:04:37 <edmondsw> ayoung I thought I already was... yes 18:04:47 * ayoung can 18:04:49 <ayoung> 't read 18:05:04 <knikolla> edmondsw: we cleaned it up a few meetings ago 18:05:16 <lbragstad> #topic announcements 18:05:25 <lbragstad> #info pike-2 is three weeks away 18:05:39 <lbragstad> which means we'll be in spec freeze for pike 18:06:00 <lbragstad> I'll be prioritizing spec reviews the next couple weeks 18:07:44 <lbragstad> We also need a documentation liaison 18:08:08 <lbragstad> i understand a lot of folks are strapped for resources, but it anyone interested in picking this up? 18:08:22 <lbragstad> s/it/is/ 18:08:31 <hrybacki> what exactly would that entail? 18:08:41 <lbragstad> good question 18:09:14 <lbragstad> the documentation liaison is responsible for keystone related documentation changes to the openstack-manuals and other projects under the docs team 18:09:39 <cmurphy> I'm interested but their meeting time is a little inconvenient for my time zone 18:09:39 <lbragstad> they also serve as a point of contact for the the docs team if they have any keystone questions 18:09:39 <ayoung> rodrigods, I wonder if we could enlist martin for that role? 18:09:51 <hrybacki> lbragstad: I'm interested but would like to talk more about 18:10:05 <lbragstad> cmurphy: understood 18:10:25 <lbragstad> #link http://eavesdrop.openstack.org/#Documentation_Team_Meeting 18:10:32 <lbragstad> ^ that's the actual meeting information 18:10:45 * lbragstad wonders if asettle is around 18:11:51 <lbragstad> there is some more information about the role in the wiki 18:11:54 <lbragstad> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation 18:12:14 <lbragstad> ayoung: rodrigods is martin an openstack contributor? 18:12:15 <samueldmq> lbragstad: fyi there is a current effort for migrating some docs into our tree 18:12:16 <gagehugo> o/ sorry I'm late 18:12:20 <samueldmq> such as the admin-guide 18:12:33 <lbragstad> samueldmq: yep - that was another big discussion at the forum 18:12:34 <hrybacki> lbragstad: I can attend the meeting this week as a stop-gap. Don't want to commit just yet to taking it over completely 18:12:41 <lbragstad> #link https://etherpad.openstack.org/p/doc-future 18:12:45 <samueldmq> talked to asettle at the summit about that, I took a few working items for our Outreach internship 18:13:10 <samueldmq> lbragstad: nice, thanks for the linked, I haven't looked into that yet 18:13:10 <lbragstad> hrybacki: that makes sense 18:13:25 <lbragstad> the tl;dr was that the docs team got hit hard recently 18:13:43 <spilla> o/ 18:13:47 <lbragstad> the discussion was focused on how we can maintain all the documentation work 18:13:48 * hrybacki nods 18:13:58 <lbragstad> now that we have less people working on docs 18:14:33 <lbragstad> one of the proposals was to move more of the documentation into the project specific repositories and then have the guides rendered by pulling all the guides together 18:15:13 <lbragstad> asettle: drove that session, so she's probably be able to clear up the direction there 18:15:47 <lbragstad> regardless of what happens, we'll have some documentation work coming down the pipe and I wanted to get an idea of who, if anyone, would be interested in that kind of work 18:16:13 * cmurphy happy to help 18:16:18 <hrybacki> I enjoy docs so I'm a candidate 18:16:52 <knikolla> happy to help but not able to guarantee a constant commitment to docs work. 18:16:59 <lbragstad> ++ 18:17:02 <lbragstad> and that's fine 18:17:15 <lbragstad> i know a lot of folks here are stretched thin, too 18:17:34 <lbragstad> if that means sharing the responsibility then i think that's ok 18:17:48 <lbragstad> we'll just have to make sure communication is on point with the docs team, too 18:18:14 <ayoung> Got it. We'll start browbeating people. 18:18:22 <lbragstad> I can take an action item to follow up with asettle 18:18:27 <knikolla> lol 18:18:42 <lbragstad> #action lbragstad to follow up with asettle about docs liaison 18:18:44 <samueldmq> lbragstad: sjain will be glad to help too, since that is what her internship is about :) 18:18:53 <lbragstad> samueldmq: sweet! 18:19:15 <samueldmq> but sure if we have lots of folks we can move much faster, which is great 18:19:21 <lbragstad> #topic spec proposal freeze exception 18:19:35 <lbragstad> #link https://review.openstack.org/#/c/463547/ - Retrieving policy via the API 18:19:41 <knikolla> we should probably have an etherpad with pain points of our docs. and just let people sign up for individual items 18:19:51 <ayoung> -2 18:20:04 <ayoung> lbragstad, so many no. 18:20:21 <lbragstad> there are two specification proposed to keystone that enable patrole to test keystone's policy 18:20:45 <lbragstad> which is great, but I think we need to work with them on generating the policy using oslo.policy bits instead of fetching it via that API 18:20:48 <lbragstad> for $REASONS 18:21:27 <samueldmq> lbragstad: what is patrole ? 18:21:34 <ayoung> RBAC testing 18:21:43 <samueldmq> I've seen that review but haven't looked into it yet, so I guess now is a good time to learn :) 18:21:45 <ayoung> samueldmq, it is, in essence, a tool for checking RBAC. 18:21:49 <edmondsw> lbragstad invite the author to our policy discussions? 18:21:51 <knikolla> #link https://docs.openstack.org/developer/patrole/ 18:21:57 <ayoung> invite the whole team 18:22:14 <lbragstad> samueldmq: patrole is a framework for testing policy 18:22:30 * ayoung sobs. Not so quietly. 18:22:45 <lbragstad> samueldmq: it will plug into tempest and exercise various policy scenarios in a functional manner 18:22:51 <lbragstad> (at least from what I can tell) 18:22:51 <samueldmq> hmm that's an interesting idea 18:22:59 <edmondsw> sounds like they're proposing similar specs to other project, or plan to 18:23:05 <ayoung> Yeah, interesting. In a "Chinese Fortune" meaning of the term 18:23:06 <edmondsw> and we don't want that... 18:23:16 <knikolla> ++ 18:23:35 <lbragstad> from what i can tell - it would be only used for patrole to fetch the policy 18:23:43 <lbragstad> so it would be an API for testing 18:23:51 <ayoung> If only we had some dynamic way of distributing policy.... 18:23:51 <lbragstad> and we've already taken a stance on policy API s 18:24:00 <samueldmq> lbragstad: cool, that's an interesting idea 18:24:07 <edmondsw> I'd say give them some time in our next policy meeting (or the next one they can make), have them explain patrole, and us explain what we're doing, and try to get on the same page 18:24:16 <samueldmq> I wonder if that could evolve to something operators could use in the future to check their policies 18:24:41 <lbragstad> edmondsw: ++ 18:24:46 <samueldmq> if they're really expressing what they wanted to 18:24:52 <lbragstad> i invited them to this meeting but the timing might not have been the best 18:24:54 <ayoung> knikolla, and I would be willing to give the authors our talk from the summit via video conf 18:25:14 <edmondsw> ayoung wasn't it recorded? 18:25:23 <ayoung> edmondsw, it was, but I would give it again just for them 18:25:23 <lbragstad> imho it sounds like what they want is a capabilities API 18:25:23 <gagehugo> could just post the link? 18:25:37 <edmondsw> ayoung oh, so you have time to burn after all... ;) 18:25:39 <lbragstad> implemented in each of the services 18:25:39 <samueldmq> putting the link along with the negative review would be enough 18:25:49 <samueldmq> s/enough/great 18:25:59 <knikolla> #link https://www.youtube.com/watch?v=EYYzl0rFCVU 18:26:01 <samueldmq> so that they can learn more about the history/context/plans 18:26:04 <ayoung> https://www.openstack.org/videos/boston-2017/per-api-role-based-access-control 18:26:11 <ayoung> Will do 18:26:13 <edmondsw> ayoung doesn't sound like the middleware thing is really what they're after anyway 18:26:20 <lbragstad> #link https://www.openstack.org/videos/boston-2017/per-api-role-based-access-control 18:26:35 <lbragstad> i think they want a list of things they can do 18:26:46 <edmondsw> yeah, that's a bit different... as you said, capabilities 18:26:50 <lbragstad> (at least that's what I got from reading the spec) 18:27:15 <knikolla> lfrom the spec i got the feeling they just want a way to 'wget policy.json' 18:27:26 <lbragstad> knikolla: right 18:27:38 <lbragstad> that's how i understood it 18:27:53 <cmurphy> that's different from 'what can i do' 18:28:10 <ayoung> So.... 18:28:26 <ayoung> Are we going to go with the RBAC in middleware approach? 18:28:30 <lbragstad> i'd also classify another question which is "what is possible" 18:28:36 <edmondsw> they talk about 2 things... one being policy.json and another being "when policy is being handled within the code (oslo.policy case)"... not sure what exactly they mean by the latter 18:29:08 <ayoung> before we discuss the patrole thing further, lets talk about the proposal that will actually answer their question if we go with it 18:29:11 <edmondsw> sounds to me like cases where checks are hardcoded 18:29:17 <ayoung> they wrote based on policy because that is all there was. 18:29:47 <knikolla> ayoung: ++, we need to get spec approval for pike before spec freeze 18:29:51 <ayoung> they wrote "patrole" based on policy. 18:30:16 <ayoung> Is any core prepared to -2 the RBAC in middleware approach? 18:30:41 <lbragstad> I have concerns with upgrades 18:30:46 <lbragstad> and maintenance 18:30:47 <lbragstad> and the url 18:30:58 <ayoung> lbragstad, enough to -2? 18:31:20 <samueldmq> I am concerned about how this fits with the ongoing efforts 18:31:25 <samueldmq> I think we can eventually get there 18:31:30 <edmondsw> samueldmq +1 18:31:41 <samueldmq> but not now, let's keep moving and keep that in the wishlist 18:31:43 <ayoung> enough to -2 it for Pike? 18:31:47 <lbragstad> based on the url - possibly, because i found a lot of value in what dstanek had to say about it 18:31:54 <samueldmq> and we will eventually get back to it as we move 18:32:08 <samueldmq> ayoung: for me I think so 18:32:29 <samueldmq> for Pike would be -2, for backlog/wishlist/future repo I'd +2 18:32:37 <ayoung> samueldmq, it will, then, never happen 18:32:51 <samueldmq> we are making progress. 18:32:55 <ayoung> samueldmq, no we are not 18:33:09 <ayoung> you are just realizing all the mess I realized years ago 18:33:12 <samueldmq> I think the right time will be when we get to split the role checks from the scope checks 18:33:19 <samueldmq> once we have only role checks somewhere 18:33:19 <knikolla> samueldmq: it's already been approved for backlog. and the code is almost done. 18:33:30 <samueldmq> we can decide where we put those checks (middleware or whatever) 18:33:32 <knikolla> samueldmq: it can be turned off and nothing changes. 18:33:45 <knikolla> i got some very positive feedback from operators who want to see this after seeing the talk. 18:33:52 <ayoung> <yoda>Hear you nothing that I say?</yoda> 18:34:07 <lbragstad> like i said - my concern is with the url 18:34:31 <ayoung> lbragstad, please state that concern completely. 18:34:36 <samueldmq> what if when we get to the point (in cross project) that we split role/scope check and then look at the middleware approach 18:34:46 <samueldmq> and no, we wanted to do it differently now that we got to this point 18:34:57 <lbragstad> I don't think it make sense for keystone to have to require knowing about the url and maintain that mapping when other parts of OpenStack already have to do that 18:35:18 <samueldmq> I am not opposed to it at all, just wanted enough input that this is going to go along very well with the cp efforts 18:35:23 <lbragstad> if that breaks - i can't imagine what kind of operator pain that is going to cause 18:35:32 <ayoung> if what breaks? 18:35:34 <knikolla> lbragstad: middleware only knows the url. if you want to use compute:list_servers. it still needs the mapping. 18:36:03 <samueldmq> kbyrne: so what's the point of performing role checks in 2 places? 18:36:04 <ayoung> They can't do it today. There is no way to gether up the list of URLs for a project except manually. 18:36:14 <lbragstad> the current proposal requires the keystone server to know that POST /v2/servers -> compute:boot_instance 18:36:19 <ayoung> lbragstad, nope 18:36:37 <samueldmq> for me it would make sense if we were going to only check roles in the middleware, checking in 2 places is going to be painful imo 18:37:05 <ayoung> the current proposal has a catch all that means it needs to know nothing about a remote service to be drop in compatible. It only has to know about POST /v2/servers if you want a specific role for that 18:37:25 <ayoung> and none of the other projects know about any of the keystone roles with the exception of admin 18:37:36 <ayoung> the service role is in the config file, managed by us 18:37:43 <lbragstad> ok - true or false, keystonemiddleware has to query keystone to determine if a user can do a specific operation 18:37:48 <ayoung> neutron has some non-created roles in their policy file 18:37:50 <edmondsw> knikolla when you say the code is almost done, does that include things like caching so performance isn't awful? 18:38:07 <ayoung> lbragstad, true (query and cache the rbac data) 18:38:20 <ayoung> lbragstad, it has to do that now, when it validates a token 18:38:23 <ayoung> query and cache 18:38:54 <ayoung> edmondsw, caching is not yet done. It will be cached in memcache along side the token data 18:39:05 <lbragstad> sure - but it's asking keystone because we're allowing the ability to store all operations in openstack in keystone based on the url, because that's what middleware requires in order to map to the operation, right? 18:39:18 <ayoung> lbragstad, not just 18:39:36 <ayoung> lbragstad, we need to map an operation to a role. Roles are data in Keystone. The RBAC data is the maintainance of this mapping 18:39:47 <ayoung> it has to be maintained somehow, and this is an operator task 18:40:14 <knikolla> edmondsw: i haven't played around with caching yet, but i can devote enough time to having this work well for Pike if it gets approved for it. 18:40:14 <ayoung> there are workflows that are impossible without the RBAC mechanism] 18:40:21 <ayoung> knikolla, ++ 18:40:59 <ayoung> lets get it in, disabled by default, and let people start working with it 18:41:20 <ayoung> there is no other way to do this 18:41:26 <lbragstad> i think there is 18:41:29 <samueldmq> is there the concept of experimental yet ? 18:41:32 <edmondsw> ayoung define "this" 18:41:51 <ayoung> edmondsw, the 3 use cases from my presentation,. and the workflow I layed out at the end 18:41:53 <lbragstad> edmondsw: finding out "which role I need to do X" 18:41:59 <ayoung> yep 18:42:10 <edmondsw> this doesn't accomplish that 18:42:27 <ayoung> edmondsw, yes it does. Not 100%, because of policy, obviously, but it is a start 18:42:33 <ayoung> if it is used, it does answer that question 18:42:39 <ayoung> if it is not used, there is no way to answer it 18:42:54 <edmondsw> ayoung so you say yes, and then contradict yourself and agree that it doesn't :) 18:42:55 <lbragstad> well - the rbac in middleware approarch requires us add an API to keystone that let's keystone answer that question 18:43:03 <ayoung> edmondsw, unless we make every single service give up an API to report their policy, we cannot work with tp-olicty,.json to do this 18:43:26 <edmondsw> lbragstad no, it allows keystone to give you an answer with <100% certainty 18:43:30 <edmondsw> policy will always still be there 18:43:33 <ayoung> edmondsw, so we make progress. And then we get rid of RBAC in policy 18:43:40 <edmondsw> ayoung you can never do that 18:43:49 <edmondsw> never ever ever 18:43:54 <edmondsw> nor should you want to 18:44:35 <edmondsw> I don't disagree with the middleware idea... I just don't want it taking attention away from more important things, or being touted as more than it is 18:45:02 <ayoung> edmondsw, just becuase you guys are doing some propriatey back system lookup does not mean I want to keep supporting the existing mechanism. Just because someone could throw a custom middleware, or even proxy in front of a Keystone server does not mean I should care about that use case 18:45:21 <edmondsw> ayoung you're confusing me with someone else... I'm not doing any proprietary back system lookup 18:45:40 <edmondsw> I don't work with Henry 18:45:55 <edmondsw> nothing I'm saying has anything to do with that 18:45:57 <ayoung> edmondsw, heh 18:46:20 <ayoung> edmondsw, why on earth would you want to continue to enforce RBAC in policy? Aside from momentum? 18:46:42 <edmondsw> because there are some things you have to check that you can't check in middleware because it doesn't known enough 18:47:01 <lbragstad> like what owns a given resource, for example? 18:47:07 <edmondsw> sure 18:47:09 <knikolla> but that's the scope check 18:47:12 <edmondsw> no 18:47:27 <edmondsw> there are so many very different examples 18:47:52 <edmondsw> e.g. changing one attribute needing a different check than changing another attribute on the same resource 18:47:53 <ayoung> edmondsw, none of that is RBAC 18:48:00 <ayoung> ownership is scope check 18:48:26 <edmondsw> ayoung if we had a real ownership concept 18:48:37 <edmondsw> I don't want to get sidetracked on that... consider my example 18:48:45 <ayoung> please... 18:48:48 <edmondsw> see above 18:48:58 <ayoung> edmondsw, what example? 18:49:04 <edmondsw> the line that starts with e.g. 18:49:38 <ayoung> currently done via actions API for example in Nova 18:49:48 <ayoung> we have the follow on spec for bodykey 18:49:53 <edmondsw> ayoung, no, that's a separate but another good example 18:49:54 <ayoung> that can be done in middleware 18:50:12 <ayoung> won't be done this release due to caution, but not a reason to keep using policy 18:50:29 <edmondsw> ayoung I don't believe you'll be able to solve that in middleware. Maybe some subcases, but not all of them 18:51:00 <knikolla> edmondsw: if updating both attributes is done via the same url, a follow up proposal checks the keys in the body of the json. if both keys are there, it checks for both roles required by each key. 18:51:04 <edmondsw> ayoung what is the link for that spec anyway? 18:51:53 <edmondsw> I don't see how you can handle all possible cases, where the key could be buried layers down in the json hierarchy, same key could mean different things in different places, etc. 18:52:11 <ayoung> https://review.openstack.org/#/c/452198/ 18:52:11 <knikolla> #link https://review.openstack.org/#/c/456974/ 18:52:56 <ayoung> edmondsw, can be vs is. We have an openstack that is out there now. Based on the today restrictions, we have something that can work. If we deploy it, it will become tomorrows guidleine for new API construction 18:53:09 <ayoung> #link https://review.openstack.org/#/c/452198/ 18:53:46 <ayoung> Mine is the spec for this release. Kristi's is for the follow on 18:55:32 <edmondsw> we've just jumped 8 steps ahead of where we should be starting... we even agreed the other day that this middleware stuff only helps with what we defined as "future goals" and not our urgent priorities 18:55:58 <lbragstad> edmondsw: what are the urgent priorities in your opinion? 18:56:09 <edmondsw> as listed in your spec on policy goals 18:56:15 <edmondsw> that's what I'm referring to 18:56:22 <lbragstad> ah 18:58:33 <lbragstad> so admin-ness 18:58:41 <edmondsw> I'm not against the middleware... I just don't see why we're spending time on it right now 18:58:52 <ayoung> and that work was submitted and an approach was approved and the fixes are being reviewed and updated 18:59:38 <ayoung> beacuse it is broken and because I have people asking for things from Openstack that can only happen if we have that mechanism 18:59:50 <edmondsw> such as? 18:59:52 <lbragstad> i personally think that in order to provide the answer to "who can do what" question, we need more service involvement 18:59:55 <ayoung> the Read only role can be done with just that patch and policy as is today 19:00:20 <ayoung> fine grained roles 19:00:22 <edmondsw> ayoung you have to know that's not true 19:00:43 <ayoung> edmondsw, I know that it is absolutely true based on the state of OpenStack today. 19:00:52 <ayoung> You need a catch all, and you need explicit rules. 19:01:04 <lbragstad> we're out of time 19:01:10 <lbragstad> we can carry on in #openstack-keystone 19:01:12 <lbragstad> #endmeeting