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