16:00:05 <lbragstad> #startmeeting policy
16:00:06 <openstack> Meeting started Wed Jan  4 16:00:05 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'policy'
16:00:13 <lbragstad> ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, stevemar
16:00:21 <gagehugo> pong
16:00:26 <lamt> o/
16:00:57 <rderose> o/
16:01:34 <lbragstad> we'll give it a few minutes
16:01:44 <lbragstad> every have a good break if they took one?
16:01:48 <lbragstad> everyone*
16:02:12 <lamt> The break was not long enough :(
16:03:10 <lbragstad> lamt lol it never is ;)
16:05:25 <lbragstad> #topic Recap action items from last meeting
16:05:39 <lbragstad> last time we met I had a couple action items to take care of
16:06:12 <lbragstad> I wanted to follow up with both the cinder and nova teams to see what work they have done around their capabilities APIs (since that effort it closely related to policy)
16:06:37 <lbragstad> for those interested in following along here is the discussion i had with smcginnis #link http://eavesdrop.openstack.org/irclogs/%23openstack-cinder/%23openstack-cinder.2016-12-22.log.html#t2016-12-22T21:41:10
16:07:18 <lbragstad> unfortunately, they are having the cinder meeting at the same time as this meeting - so getting them here might be tough (but I offered that we can always followup in -keystone if needed)
16:07:49 <lbragstad> so ^ that should take care of the cinder action item - but I haven't had the change to sit down with the Nova folks yet
16:08:41 <lbragstad> I briefly touched base with johnthetubaguy before the holidays, and haven't had the chance to finish up that discussion (it sounded like he had a bunch of information regarding nova's work on policy)
16:09:12 <lbragstad> but - i'm going to carry that action item forward this week
16:09:56 <lbragstad> on the other hand - we did have a comment from one of the nova developers on ayoung's spec #link https://review.openstack.org/#/c/391624/
16:10:10 <lbragstad> ^ which is interesting - and something I think we'll need to sit down and visit with nova about
16:11:09 <lbragstad> in other news - ayoung is making progress on his RBAC in middleware approach, so I figured we could move along to discussing a different approach for policy
16:11:10 <lbragstad> #topic Project tag for supporting RBAC out-of-the-box
16:11:41 <lbragstad> for those who remember dolphm and jamielennox's work on standardizing policy across projects, this is essentially and extension of that
16:11:55 <lbragstad> #link https://review.openstack.org/#/c/245629/
16:12:06 <lbragstad> ^ that is the cross-project spec for it
16:13:09 <lbragstad> I asked dolphm and jamie why that effort petered out and it sounded like it was tough to get that moving across a bunch of projects
16:13:29 <lbragstad> we don't really provide any documentation for projects to use to move towards the goals outlined in that spec
16:13:29 <dolphm> yeah, so... in one of the ops track session in barcelona, the idea came up to take a new approach to addressing this same use case
16:14:32 <dolphm> instead of tackling it from a cross-project spec perspective, the idea was to create a project assert tag via governance to indicate to ops which projects support which rbac features, if any
16:15:30 <dolphm> so we can start with "does this project support the admin and member roles?" and we can add new "conventional roles", such as a read-only role, for example
16:15:42 <lbragstad> ++
16:15:53 <lbragstad> this is something we can do in parallel to existing policy work, too
16:16:02 <dolphm> (via separate tags)
16:16:21 <lbragstad> i'm curious to see what we come up with for those
16:16:48 <lbragstad> dolphm did you have a more detailed idea of what those tags would be (elaborating on the admin/member case)?
16:16:53 <edmondsw> dolphm so you're suggesting we create a member role? Because no projects spell out such a role today
16:17:21 <dstanek> dolphm: who defines those roles?
16:17:42 <lbragstad> dstanek ultimately - i think that would be up to us to define in the project tag documentation
16:17:56 <lbragstad> s/us/the writers of the project tag/
16:18:27 <dolphm> edmondsw: dstanek: the idea is that the governance tag would define the role(s)
16:18:28 <edmondsw> is the TC going to be ok with a lot of tags when we have one for each different role?
16:19:11 <dolphm> the basic use case for each role, along with what types of features the role should be capable of (without getting into project-specifics)
16:19:50 <lbragstad> I don't think there is anything stopping us from achieving ^  that, but as a group does this raise any red flags for anyone?
16:19:52 <dolphm> edmondsw: i suspect that as long as each tag is easily testable, they'll be agreeable (i've been working to define upgrade related tags recently)
16:21:49 <edmondsw> I'm not sure exactly how you'd make the tag easily testable, assuming the point of the testing to make sure it's not misused
16:22:48 <dolphm> edmondsw: right
16:22:49 <edmondsw> the tests would have to be specific to the project, so you'd have to trust that the test author understood the role's intended usage correctly
16:22:56 <dolphm> edmondsw: ++
16:22:58 <edmondsw> that's trusting, not testing :)
16:24:22 <dolphm> i don't disagree! but i think that's the position that the TC is in with tags, in general
16:24:24 <edmondsw> other than that, I kinda like the idea
16:24:41 <edmondsw> so if the TC is ok with it, ++
16:25:10 <lbragstad> it would be nice to provide some level of documentation around policy for projects to use as true north (even us!)
16:25:22 <edmondsw> ++
16:25:34 <edmondsw> especially us? ;)
16:25:44 <lbragstad> new projects shouldn't have to copy paste a policy file from another project
16:26:17 <lbragstad> existing projects should be able to use the documentation and come up with a path for providing better defaults
16:26:29 <edmondsw> advice #1 should be define all the defaults in code like nova did last release and cinder is working on, so you don't even have a policy file unless you're overriding things
16:26:53 <lbragstad> does it make sense to make ^ that a tag?
16:27:18 <edmondsw> I'm not sure what the value prop for a tag there would be
16:27:30 <lbragstad> i suppose
16:27:56 <lbragstad> maybe more of a stepping stone to achieving *a* tag?
16:28:37 <dolphm> lbragstad: probably not. tags are intended to convey the expected user experience
16:28:44 <edmondsw> maybe it's helpful to see who is following best practices?
16:29:10 <lbragstad> got it - but something we should probably document somewhere so that projects start following the convention?
16:29:12 <edmondsw> this does intersect user experience in the sense that a user can have a much shorter and easier to read policy file
16:29:45 <edmondsw> lbragstad I definitely agree that we should have some kind of document on best practices for policy
16:29:58 <lbragstad> edmondsw dolphm ok - where should that documentation live?
16:30:00 <dolphm> edmondsw: that's true. i could see a tag around auditability, perhaps?
16:30:24 <lbragstad> (i've been trying to answer that and I can't decide if it should live with the tag proposal or not - I'm thinking not)
16:30:58 <dolphm> lbragstad: there are lots of guidelines in cross-project specs
16:31:19 <dolphm> how to do CORS correctly, how to do logging correctly, how to do request IDs correctly, etc
16:31:23 <lbragstad> dolphm do you suggest that we rework https://review.openstack.org/#/c/245629/ ?
16:31:30 <lbragstad> and get that merged?
16:31:37 <edmondsw> put it somewhere here http://docs.openstack.org/developer/openstack-projects.html
16:32:25 <dolphm> lbragstad: i think we might need to start with something more fundamental than the current state of that spec
16:32:37 <edmondsw> ++
16:33:03 <edmondsw> a new spec proposing the documentation of policy best practices?
16:33:06 <dolphm> lbragstad: roughly "you need to implement basic, operator-configurable RBAC that allows you to enable or disable specific features..."
16:33:09 <lbragstad> dolphm ok - so by rework we mean basic documentation about policy and very basic guidelines?
16:33:16 <dolphm> lbragstad: right
16:33:26 <lbragstad> and I assume it's ok to propose specs that are just guidelines?
16:33:49 <lbragstad> for some reason I'm hardwired to assuming merging a spec results in code deliverables
16:33:56 <dolphm> edmondsw: ++ maybe take the WG approach, and start with a blank slate. review individual guidelines rather than a giant doc
16:34:16 <edmondsw> ++
16:34:18 <dolphm> i.e. also don't expect one person to contribute the whole thing
16:34:25 <lbragstad> agreed
16:34:28 <dolphm> or for it to be done all at once, in one go
16:34:42 <lbragstad> I'd like to not burn people out on it
16:34:50 <dstanek> lbragstad: ++
16:35:10 <lbragstad> which is why i think making bite-sized goals achieveable and discoverable would be huge it making that work
16:36:02 <lbragstad> so - is the best way to do that through cross project guidelines merged as cross-project specs, or through a WG approach (do we graduate this group to a WG format?)
16:36:17 <lbragstad> or is there another approach we can take to achieve that?
16:37:33 <dstanek> i think we should start first and graduate/grow when needed
16:38:25 <dolphm> i think the important part is to define where the guidelines should be contributed
16:38:30 <lbragstad> ok - with that being said, do we review individual guidelines proposed as cross-project specs?
16:38:31 <dolphm> initialize the blank slate, so to speak
16:39:22 <lbragstad> I'm fine with our initial blank slate being a cross project spec - if we need to move it later, we can
16:39:57 <lbragstad> and we often say that specs can be amended
16:40:07 <dolphm> can we land a blank cross-project spec?
16:40:15 <lbragstad> dolphm that's a good question
16:40:29 <dolphm> or, one with a high level outline of what should be included, with no actual guidelines?
16:42:20 <dolphm> i believe the TC has +2 on os-specs
16:42:28 <lbragstad> looking to see who the approvers are
16:42:34 <dolphm> stevemar: ?
16:42:54 <stevemar> hmm..
16:43:21 <stevemar> dolphm: i can verify that TC doesn't not have +2 on os-specs
16:43:38 <stevemar> or I was secretly removed from the TC
16:44:00 <dolphm> there's no openstack-specs-core group
16:44:18 <stevemar> is there a reason it's not a "community wide goal" ?
16:44:23 <lbragstad> looking at the reviewer list on https://review.openstack.org/#/c/245629/ and it's quite long
16:44:32 <dolphm> stevemar: ooh, ++
16:44:37 <dolphm> stevemar: but goals are short term, no?
16:44:43 <dolphm> stevemar: as in, scoped to a release
16:44:57 <dolphm> not permanent guidelines
16:45:01 <stevemar> somewhat yes -- https://etherpad.openstack.org/p/community-goals
16:45:24 <stevemar> but py35 was a "goal" and certainly was not bound to a single release
16:45:47 <lbragstad> 15 minutes left
16:46:13 <lbragstad> stevemar is there a process for applying existing goals to new projects?
16:46:15 <stevemar> i guess you can think about it as "will this goal result in TODO for a lot of openstack projects"
16:46:26 <stevemar> lbragstad: yes
16:46:41 <stevemar> lbragstad: https://review.openstack.org/#/c/349069/ and https://review.openstack.org/#/c/369749/
16:46:49 <stevemar> those are goals for Pike
16:47:14 <stevemar> I am hoping to create a backlog like we have in keystone-specs, where goals are backlogged and teams can chip away at them at their own rate
16:48:25 <lbragstad> hmm - so for this we would have a super general policy goal that can be amended?
16:49:35 <stevemar> lbragstad: not sure, i'd have to look back at 245629
16:50:47 <lbragstad> stevemar i think we'd try to split 245629 up into bits and propose them in pieces
16:51:19 <ayoung> Are we still talking policy?
16:51:29 <ayoung> seems to have gone a bit afield
16:51:30 <lbragstad> stevemar does the community typically have goals that change over time? Or is the process to firm things up then commit to them?
16:51:44 <stevemar> the latter
16:51:56 <lbragstad> ayoung we're trying to determine which process to take for documenting policy information
16:52:49 <ayoung> its Keystone.  Look who is participating.  Look who is actually talking to other projects
16:52:56 <ayoung> there is no cross-project communication
16:53:07 <ayoung> there is the Keystone team trying to make it work, and then a bunch of cargo culting
16:53:19 <ayoung> policy is 2 things
16:53:21 <ayoung> scope check
16:53:22 <ayoung> rbac
16:53:29 <ayoung> anything beyond that is project specific
16:53:34 <ayoung> rbac is Keystone
16:53:43 <ayoung> scope check is 1/2 keystone, 1/2 the project
16:53:53 <ayoung> keystone provides the scope on the token
16:53:58 <ayoung> project makes sure that matches
16:54:16 <ayoung> we take RBAC out of the control of the projects
16:54:17 <lbragstad> ayoung sure - i don't think anyone disagrees with you there... but providing documentation for projects to follow should be cross project
16:54:28 <ayoung> because they are not doing it, and you cannot do it in a vacuum
16:54:44 <ayoung> the documentation is exactly that:  "do the scope check."
16:55:01 <ayoung> people don't even understand that much, but they seem to have made it work via cargo culting
16:55:10 <ayoung> the role check is problematic
16:55:30 <ayoung> we are going to have projects hard-coding the role checks, and we don't even have roles defined, aside from admin
16:56:02 <ayoung> Until this meeting starts having people from projects other than keystone involved, nothing real is going to change
16:56:37 <lbragstad> ayoung we could start by publishing documentation somewhere to entice discussion
16:57:26 <stevemar> big changes do happen, look at py35 and v3 by default (finally)
16:57:40 <stevemar> a lot of it is communication and setting expectations for projects
16:57:45 <stevemar> its possible, not easy though
16:57:49 <lbragstad> the big question we need to answer is where should that documentation live
16:58:11 <ayoung> lbragstad, that is what the RBAC in middleware spec is
16:58:17 <ayoung> that is the starting point
16:58:30 <lbragstad> ayoung it barely has any feedback from other projects
16:58:36 <ayoung> THat is the delineation between what Keystone is going to manage and what the projects get to change
16:58:43 <ayoung> lbragstad, myh point exactly.
16:59:19 <ayoung> lbragstad, everytime we have a cross project meeting, it is all keystone
16:59:36 <ayoung> and then we go an try and fix things in their projects and we get pushback
16:59:46 <lbragstad> fwiw - if we actually go talk to folks from other projects about policy, they do have a lot to say
16:59:54 <ayoung> the 968696 bug gets changed from High priority to wishlist
17:00:02 <ayoung> lbragstad, I know
17:00:14 <edmondsw> we're talking about how to fix that... cross-project enforcement will force folks from other projects to get more involved
17:00:24 <lbragstad> edmondsw ++
17:00:29 <lbragstad> we're out of itme
17:00:39 <lbragstad> spill over into -keystone if needed
17:00:42 <lbragstad> #endmeeting