16:01:04 <lbragstad> #startmeeting policy
16:01:05 <openstack> Meeting started Wed Dec 21 16:01:04 2016 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:08 <openstack> The meeting name has been set to 'policy'
16:01:21 <lbragstad> ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan_11 , ayoung
16:01:23 <lbragstad> stevemar
16:01:30 <lbragstad> #link agenda https://etherpad.openstack.org/p/keystone-policy-meeting
16:01:35 <dolphm> o/
16:01:41 <lbragstad> o/
16:01:44 <ruan_11> o/
16:02:20 <lbragstad> i imagine there are a few folks on vacation already - but we'll give it a minute or two
16:02:48 <stevemar> o/
16:02:53 <gagehugo> o/
16:03:39 <lamt> o/
16:04:20 <jaugustine> :)
16:05:03 <lbragstad> alrighty - let's get started
16:05:04 <lbragstad> #topic other project work around capability APIs
16:05:40 <lbragstad> I'm curious if anyone else has see or looked at what other projects are doing with policy?
16:05:41 <lbragstad> Barcelona session #link https://etherpad.openstack.org/p/ocata-xp-unified-capabilities-api
16:05:47 <lbragstad> Cinder spec #link https://review.openstack.org/#/c/306930/
16:06:15 <lbragstad> nova and cinder have a need for a capabilities API, which they seem to have specs in place for
16:06:44 <lbragstad> and the capability relates to not only policy, but also the abilities of the hardware incorporated into the deployment
16:08:11 <dolphm> so, i did not attend the capabilities session in barcelona, but i thought it wasn't authorization-related at all?
16:08:19 <dolphm> * nova's capabilities session
16:08:55 <lbragstad> true
16:09:27 <lbragstad> it sounds like the capabilities work is mostly focused on letting people know what a deployment supports from an infrastructure perspective
16:10:00 <lbragstad> i did read the cinder spec and they mention using policy.json https://review.openstack.org/#/c/306930/12/specs/newton/discovering-system-capabilities.rst
16:10:02 <lbragstad> #link https://review.openstack.org/#/c/306930/12/specs/newton/discovering-system-capabilities.rst
16:10:33 <lbragstad> specifically around line 136
16:10:42 <ayoung> Some day OpenStack is actually going to discover Rest
16:10:58 <dolphm> not that they should rename it, but i think you could call it a "features" API
16:11:23 <lbragstad> yeah
16:11:26 <dolphm> ayoung: yeah...
16:11:39 <samueldmq> hi I am late
16:11:56 <lbragstad> either way - i noticed the bits specific to the policy.json file while I was reading their spec
16:12:16 <lbragstad> and i wanted to added it so that others could get up to speed on it if they wanted to
16:13:00 <lbragstad> also - i followed up with johnthetubaguy on some of the work they have left in nova for the pulling policy into oslo.policy - https://etherpad.openstack.org/p/ocata-xp-unified-capabilities-api
16:13:04 <ayoung> the key piece that is missing between policy.json and the APIs is the mapping.  THE API-refs, while a great start, are outside knowledge, and not part of the workflow.  This effort seems to be targetting that
16:13:44 <ayoung> And, to be fair, there seems to be no standard way of doing RBAC via REST
16:14:25 <ayoung> ideally, it would be discoverable, say by making a call that does not have the role data on it, that fails, and comes back with a 401 + Here are the roles you need
16:14:43 <ayoung> from a capabilities standapoint, the way we do version discovery is the right approach:
16:15:04 <ayoung> for a keystone server, from /v3/  we should have links to the underlying APIs
16:15:12 <lbragstad> sure - that makes sense
16:15:20 <ayoung> perhaps we would only show those to an authenticated user
16:16:09 <ayoung> it also seems like the AUTH_URL should point to a separate microservice than the rest of Keystone, and that micro service should be end user specific.  Pretty much just the stuff we have under OS_FEDERATION.
16:16:16 <ayoung> I;'m working backwards here, of course
16:16:51 <ayoung> but...this is why, all those years ago, I wrote the HTML rendering code for Keystone.  All this stuff is super clear when you try to do it from a web browser:
16:17:05 <ayoung> *everything* should be discoverable
16:17:31 <ayoung> to include "what role do I need to give to dolphm so he can do work in this new project"
16:17:46 <ayoung> and that is what this cinder propsal is attacking
16:17:54 * ayoung surrenders the conch
16:17:54 <lbragstad> right
16:18:31 <lbragstad> that's the main reason i wanted to bring that up here - because both cinder and nova are trying to solve that problem and it kinda relates to some discussions we've had around policy
16:19:47 <lbragstad> i was thinking it would be a good point of view to consider as we hold this meeting, and keep their perspective in mind (hopefully we can get them in here for discussions that require both teams - but I thought it was a little early for that step right now)
16:20:22 <lbragstad> does anyone have questions on this?
16:20:39 <ayoung> sooo lets say I get my RBAC work done
16:20:43 <ayoung> how would we use it?
16:20:57 <lbragstad> ayoung you mean how would *they* use it?
16:21:02 <ayoung> lbragstad, yes
16:21:24 <ayoung> ideally, the policy names they have right now would be *like* roles
16:21:28 <lbragstad> well - in my eyes, the thing they need from keystone is "what role is required to do this operation"
16:22:01 <lbragstad> or - specifically, the information in order to make that decision
16:22:08 <ayoung> I think the current query interface would let them answer that question
16:22:21 <lbragstad> once they know that, it is up to them how they want to determine capabilities specific to their project
16:22:22 <ayoung> but it is at the URL level
16:22:38 <ayoung> and there is still no mapping between URL and policy except in the code
16:22:52 <lbragstad> that's another reason why I think having their input on your spec would be useful
16:22:53 <ayoung> even the Nova mechanism does not really provide a way to go from URL to policy rule
16:23:16 <lbragstad> well - that's because it was derived off the policy.json file
16:23:17 <ayoung> is there anyone from cinder around?  Can we pull them into this meeting?
16:23:42 <lbragstad> ayoung not that I know of - but I didn't explicitly ask for them to be here
16:23:50 <lbragstad> or nova for that matter
16:23:58 <smcginnis> Cinder meeting is going on right now.
16:23:59 <lbragstad> i think it would be good due diligence for us to review each of the their specs
16:24:14 <lbragstad> smcginnis o/
16:24:25 <smcginnis> o/
16:25:23 <lbragstad> how about we, as a group, review #link https://review.openstack.org/#/c/377756/ and #link https://review.openstack.org/#/c/306930/
16:26:09 <lbragstad> to get a feel for how the different projects plan on interacting with keystone for the bits they need, and if there is a way we can smooth that out if possible?
16:26:09 <smcginnis> lbragstad: That would be great to get your input on those.
16:26:39 <lbragstad> as a follow up - I'd like the next part of that discussion to be involving  ayoung's RBAC in middleware spec
16:27:23 <ayoung> Let me find the readable link
16:27:35 <lbragstad> at that point - i think it would make sense to come together as a larger group and start discussing the overall direction
16:27:43 <ayoung> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html
16:28:19 <lbragstad> so, since we won't be having a policy meeting next week
16:28:28 <ayoung> THanks to all who reviewed it.  I'd like to remind people that specs, just like code, can and should be amended as we learn more
16:28:37 <ayoung> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html
16:28:49 <ayoung> a couple points worth pulling out:
16:28:59 <ayoung> Defaults are going to be super important
16:29:39 <ayoung> if we can make it so the default role for normal operations is "Member" and we can get that enforced everywhere, it makes it safe to then have a read-only role explicitly identified for certain operations
16:29:57 <ayoung> this has been requested for a long, long time
16:30:51 <lbragstad> I'll take an action item to follow up with the nova folks about their work with policy (specifically oslo.policy) and #link https://review.openstack.org/#/c/377756/
16:31:10 <lbragstad> is anyone interested in doing the same with the cinder team?
16:31:42 <lbragstad> FYI - our next policy meeting will be Tuesday, January 3rd
16:32:47 <dolphm> ayoung: ++
16:32:54 <lbragstad> #action lbragstad to follow up with the nova team on #link https://review.openstack.org/#/c/377756/
16:34:28 <lbragstad> #action lbragstad to follow up with the cinder team on #link https://review.openstack.org/#/c/306930/
16:35:07 <lbragstad> does anyone have questions on this so far?
16:35:22 <ayoung> As a reference to my earlier HTML statements
16:35:34 <ayoung> this is the code here that needs to be primarily changed to make it wo0rk
16:35:36 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/middleware/core.py#n76
16:36:04 <ayoung> The JSON middleware assumes only JSON comes in or out, and that middleware, or a comparable one would have to look at the accepts headers.
16:36:18 <ayoung> I have an abandonded review from back in the XML-also days...
16:36:44 <ayoung> https://review.openstack.org/#/c/24443/
16:36:52 <lbragstad> ayoung ready to move on to the next topic?
16:36:57 <ayoung> yep
16:37:01 <lbragstad> cool
16:37:02 <lbragstad> #topic review policy use cases
16:37:20 <lbragstad> #link https://etherpad.openstack.org/p/keystone-policy-usecases
16:37:23 <lbragstad> dstanek has been collapsing a bunch of usecases and documenting them ^
16:37:39 <lbragstad> we've been spending the last few weeks going through them
16:38:02 <lbragstad> I wanted to double check with folks to give them another look - and see if we're missing anything
16:38:21 <ayoung> Nicely cleaned up
16:38:59 <ayoung> I wonder if this should now be posted as something like a cross-project spec?
16:39:13 <lbragstad> ayoung i would agree with that - as the next logical step
16:39:44 <lbragstad> maybe not so much as a cross project spec - but some formal document
16:40:10 <lbragstad> something saying "these are things we need in a policy engine"
16:40:34 <lbragstad> which actually is a nice transition to our next topic
16:40:40 <lbragstad> #topic project tag for RBAC capabilities
16:40:41 <ayoung> Heres a thought
16:40:50 <ayoung> why don't we move the standard roles to the top of that doc
16:40:55 <ayoung> ahhhh...too slow
16:41:01 <ayoung> before we transition...
16:41:02 <lbragstad> ayoung go ahead
16:41:17 <ayoung> lets move the standard roles to the top of the etherpad, and break the use cases up under them
16:41:42 <ayoung> for example, we don't wamt a use case with any other actores
16:41:44 <ayoung> liek the one
16:41:52 <ayoung> s a protected resource I want to enforce some level of admin before you can operate on me??  (is this 6.2 above?)
16:42:15 <ayoung> THe protected resource is not the actor,  that one should be moved to either the user or the admin
16:42:20 <lbragstad> sure - that's one way we could organize it
16:42:40 <ayoung> Let me do that now, and we can drive on.
16:42:51 <lbragstad> ayoung want to do that at the bottom so we can keep the original?
16:43:14 <lbragstad> ayoung just so we don't lose information
16:43:57 <ayoung> Should not lose info... see?
16:44:03 <lbragstad> ayoung yeah - that works
16:44:54 <lbragstad> the reason for this topic was that there were discussion in Barcelona about proposing a tag for RBAC
16:45:01 <lbragstad> s/tag/project tag/
16:45:19 <lbragstad> I think dolphm was the one who told me about that(?)
16:46:11 <lbragstad> and I'm pretty sure this ties back to the cross project dolphm and jamielennox had for standarizing roles across projects
16:46:40 <lbragstad> cross project spec*
16:47:17 <lbragstad> I personally think its a good idea - and it would be really cool to be able to take a proposal to the PTG in Atlanta
16:47:48 <lbragstad> does anyone else have thoughts?
16:48:55 <samueldmq> lbragstad: I agree with you
16:49:08 <samueldmq> lbragstad: we keystone bootstrap should have a command to setup the default roles
16:49:13 <samueldmq> for an openstack deployment
16:49:29 <lbragstad> it would be similar to our rolling upgrade tags
16:49:31 <ayoung> It would be great to get the Nova and Cinder teams to agree to have their capabilites meetings jointly, and then make sure we attend
16:49:34 <samueldmq> default roles/base roles
16:49:57 <lbragstad> https://governance.openstack.org/tc/reference/tags/index.html#project-assertion-tags
16:49:59 <lbragstad> #Link https://governance.openstack.org/tc/reference/tags/index.html#project-assertion-tags
16:50:15 <lbragstad> it would be similar to those  - but geared towards RBAC
16:50:52 <lbragstad> It would require some work from us before the PTG to come up with some documentation
16:51:18 <lbragstad> a document for new projects to go to for understand how policy works today and what they need to do to get it to work
16:51:44 <lbragstad> and a document for existing projects to be able to use as a roadmap for getting RBAC support
16:52:20 <ayoung> One thing that might be good to flesh out is the service specific roles they would want
16:52:32 <ayoung> I've alluded to that in the past in Neutron
16:52:33 <lbragstad> ++
16:52:51 <lbragstad> right now that kind of documentation doesn't exist
16:53:11 <ayoung> "I can create a network"  "I can only attach to existing networks" seem to be the most common stratification.  I wonder if the same exists for Cinder
16:53:26 <lbragstad> ayoung that's a good question
16:53:44 <lbragstad> and something we'll need to ask them in order to flesh these things out
16:54:27 <lbragstad> but it would be awesome to get a start on this right away in the new year so that we can bring it to the PTG in the event we want to propose a project assertion tag for RBAC
16:55:32 <ayoung> any other actions you think we need to do?
16:55:53 <lbragstad> ayoung for an RBAC project assertion tag?
16:56:08 <ayoung> or to prep for PTG in general?
16:56:48 <lbragstad> well - by the time the PTG is here I want to have detailed discussion with other projects about their approach to RBAC and policy in general
16:57:23 <lbragstad> as well as have a document documenting policy in openstack for new and existing projects
16:57:38 <lbragstad> (something they can use to achieve sensible RBAC)
16:57:51 <lbragstad> and start using keystone as an example
16:58:02 <ayoung> So, based on who submitted the specs, we know who to talk to in Nova and CInder.  SHould we id people in the other core projects?
16:58:07 <lbragstad> (it's going to be hard to get other projects to follow our lead when we haven't followed it)
16:58:12 <ayoung> And, how wide a net do we need to cast?
16:58:55 <lbragstad> I'd love to cast a wider net
16:59:19 <lbragstad> but I think we have plenty to work on with the nova and cinder folks to get some work rolling - in the event other projects aren't ready
16:59:50 <lbragstad> going to have to wrap up here - if anyone has left over questions, let's head to #openstack-keystone
17:00:00 <lbragstad> thanks folks!
17:00:03 <lbragstad> #endmeeting