| *** ducttape_ has quit IRC | 00:01 | |
| *** ducttape_ has joined #openstack-meeting-cp | 00:32 | |
| *** harlowja has joined #openstack-meeting-cp | 01:06 | |
| *** ducttape_ has quit IRC | 01:10 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:11 | |
| *** ducttape_ has quit IRC | 01:15 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:37 | |
| *** harlowja has quit IRC | 01:44 | |
| *** ducttape_ has quit IRC | 01:56 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:57 | |
| *** ducttape_ has quit IRC | 02:17 | |
| *** gouthamr has quit IRC | 02:58 | |
| *** coolsvap has joined #openstack-meeting-cp | 03:13 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 03:13 | |
| *** ducttape_ has joined #openstack-meeting-cp | 03:18 | |
| *** ducttape_ has quit IRC | 03:23 | |
| *** diablo_rojo has quit IRC | 03:40 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 03:54 | |
| *** jaugustine has quit IRC | 04:33 | |
| *** ducttape_ has joined #openstack-meeting-cp | 04:49 | |
| *** ducttape_ has quit IRC | 04:53 | |
| *** prateek has joined #openstack-meeting-cp | 05:18 | |
| *** ducttape_ has joined #openstack-meeting-cp | 06:19 | |
| *** ducttape_ has quit IRC | 06:24 | |
| *** diablo_rojo has quit IRC | 06:43 | |
| *** ducttape_ has joined #openstack-meeting-cp | 07:50 | |
| *** ducttape_ has quit IRC | 07:54 | |
| *** ducttape_ has joined #openstack-meeting-cp | 08:50 | |
| *** ducttape_ has quit IRC | 08:55 | |
| *** ducttape_ has joined #openstack-meeting-cp | 09:00 | |
| *** ducttape_ has quit IRC | 09:05 | |
| *** ducttape_ has joined #openstack-meeting-cp | 10:02 | |
| *** ducttape_ has quit IRC | 10:07 | |
| *** ttx has quit IRC | 10:45 | |
| *** ttx has joined #openstack-meeting-cp | 10:46 | |
| *** ducttape_ has joined #openstack-meeting-cp | 11:02 | |
| *** persia has quit IRC | 11:07 | |
| *** ducttape_ has quit IRC | 11:07 | |
| *** persia has joined #openstack-meeting-cp | 11:09 | |
| *** ducttape_ has joined #openstack-meeting-cp | 12:03 | |
| *** ducttape_ has quit IRC | 12:08 | |
| *** sdague has joined #openstack-meeting-cp | 12:17 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:04 | |
| *** ducttape_ has quit IRC | 13:06 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:06 | |
| *** ducttape_ has quit IRC | 13:07 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:18 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:23 | |
| *** ducttape_ has quit IRC | 13:51 | |
| *** xyang1 has joined #openstack-meeting-cp | 13:52 | |
| *** lamt has joined #openstack-meeting-cp | 14:10 | |
| *** jaugustine has joined #openstack-meeting-cp | 14:52 | |
| *** diablo_rojo_phon has joined #openstack-meeting-cp | 15:07 | |
| *** markvoelker has quit IRC | 15:29 | |
| *** markvoelker has joined #openstack-meeting-cp | 15:31 | |
| *** prateek has quit IRC | 15:51 | |
| *** gagehugo has joined #openstack-meeting-cp | 15:56 | |
| *** ruan_ has joined #openstack-meeting-cp | 15:56 | |
| *** ruan_ is now known as Guest88255 | 15:57 | |
| *** Guest88255 has quit IRC | 15:57 | |
| *** ruan_11 has joined #openstack-meeting-cp | 15:57 | |
| lbragstad | #startmeeting policy | 16:01 |
|---|---|---|
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:01 | |
| openstack | The meeting name has been set to 'policy' | 16:01 |
| lbragstad | ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan_11 , ayoung | 16:01 |
| lbragstad | stevemar | 16:01 |
| lbragstad | #link agenda https://etherpad.openstack.org/p/keystone-policy-meeting | 16:01 |
| dolphm | o/ | 16:01 |
| lbragstad | o/ | 16:01 |
| ruan_11 | o/ | 16:01 |
| lbragstad | i imagine there are a few folks on vacation already - but we'll give it a minute or two | 16:02 |
| stevemar | o/ | 16:02 |
| gagehugo | o/ | 16:02 |
| lamt | o/ | 16:03 |
| jaugustine | :) | 16:04 |
| lbragstad | alrighty - let's get started | 16:05 |
| lbragstad | #topic other project work around capability APIs | 16:05 |
| *** openstack changes topic to "other project work around capability APIs (Meeting topic: policy)" | 16:05 | |
| lbragstad | I'm curious if anyone else has see or looked at what other projects are doing with policy? | 16:05 |
| lbragstad | Barcelona session #link https://etherpad.openstack.org/p/ocata-xp-unified-capabilities-api | 16:05 |
| lbragstad | Cinder spec #link https://review.openstack.org/#/c/306930/ | 16:05 |
| lbragstad | nova and cinder have a need for a capabilities API, which they seem to have specs in place for | 16:06 |
| lbragstad | and the capability relates to not only policy, but also the abilities of the hardware incorporated into the deployment | 16:06 |
| dolphm | so, i did not attend the capabilities session in barcelona, but i thought it wasn't authorization-related at all? | 16:08 |
| dolphm | * nova's capabilities session | 16:08 |
| lbragstad | true | 16:08 |
| lbragstad | it sounds like the capabilities work is mostly focused on letting people know what a deployment supports from an infrastructure perspective | 16:09 |
| *** ayoung has joined #openstack-meeting-cp | 16:09 | |
| 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 |
| lbragstad | #link https://review.openstack.org/#/c/306930/12/specs/newton/discovering-system-capabilities.rst | 16:10 |
| lbragstad | specifically around line 136 | 16:10 |
| ayoung | Some day OpenStack is actually going to discover Rest | 16:10 |
| dolphm | not that they should rename it, but i think you could call it a "features" API | 16:10 |
| lbragstad | yeah | 16:11 |
| dolphm | ayoung: yeah... | 16:11 |
| samueldmq | hi I am late | 16:11 |
| lbragstad | either way - i noticed the bits specific to the policy.json file while I was reading their spec | 16:11 |
| lbragstad | and i wanted to added it so that others could get up to speed on it if they wanted to | 16:12 |
| 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 |
| 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 |
| ayoung | And, to be fair, there seems to be no standard way of doing RBAC via REST | 16:13 |
| 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 |
| ayoung | from a capabilities standapoint, the way we do version discovery is the right approach: | 16:14 |
| ayoung | for a keystone server, from /v3/ we should have links to the underlying APIs | 16:15 |
| lbragstad | sure - that makes sense | 16:15 |
| ayoung | perhaps we would only show those to an authenticated user | 16:15 |
| 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 |
| ayoung | I;'m working backwards here, of course | 16:16 |
| 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:16 |
| ayoung | *everything* should be discoverable | 16:17 |
| ayoung | to include "what role do I need to give to dolphm so he can do work in this new project" | 16:17 |
| ayoung | and that is what this cinder propsal is attacking | 16:17 |
| * ayoung surrenders the conch | 16:17 | |
| lbragstad | right | 16:17 |
| 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:18 |
| 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:19 |
| lbragstad | does anyone have questions on this? | 16:20 |
| ayoung | sooo lets say I get my RBAC work done | 16:20 |
| ayoung | how would we use it? | 16:20 |
| lbragstad | ayoung you mean how would *they* use it? | 16:20 |
| ayoung | lbragstad, yes | 16:21 |
| ayoung | ideally, the policy names they have right now would be *like* roles | 16:21 |
| lbragstad | well - in my eyes, the thing they need from keystone is "what role is required to do this operation" | 16:21 |
| lbragstad | or - specifically, the information in order to make that decision | 16:22 |
| ayoung | I think the current query interface would let them answer that question | 16:22 |
| lbragstad | once they know that, it is up to them how they want to determine capabilities specific to their project | 16:22 |
| ayoung | but it is at the URL level | 16:22 |
| ayoung | and there is still no mapping between URL and policy except in the code | 16:22 |
| lbragstad | that's another reason why I think having their input on your spec would be useful | 16:22 |
| ayoung | even the Nova mechanism does not really provide a way to go from URL to policy rule | 16:22 |
| *** ducttape_ has joined #openstack-meeting-cp | 16:23 | |
| lbragstad | well - that's because it was derived off the policy.json file | 16:23 |
| ayoung | is there anyone from cinder around? Can we pull them into this meeting? | 16:23 |
| lbragstad | ayoung not that I know of - but I didn't explicitly ask for them to be here | 16:23 |
| lbragstad | or nova for that matter | 16:23 |
| smcginnis | Cinder meeting is going on right now. | 16:23 |
| lbragstad | i think it would be good due diligence for us to review each of the their specs | 16:23 |
| lbragstad | smcginnis o/ | 16:24 |
| smcginnis | o/ | 16:24 |
| lbragstad | how about we, as a group, review #link https://review.openstack.org/#/c/377756/ and #link https://review.openstack.org/#/c/306930/ | 16:25 |
| 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 |
| smcginnis | lbragstad: That would be great to get your input on those. | 16:26 |
| lbragstad | as a follow up - I'd like the next part of that discussion to be involving ayoung's RBAC in middleware spec | 16:26 |
| ayoung | Let me find the readable link | 16:27 |
| 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 |
| ayoung | http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html | 16:27 |
| *** ducttape_ has quit IRC | 16:27 | |
| lbragstad | so, since we won't be having a policy meeting next week | 16: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 |
| ayoung | #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html | 16:28 |
| ayoung | a couple points worth pulling out: | 16:28 |
| ayoung | Defaults are going to be super important | 16:28 |
| 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 |
| ayoung | this has been requested for a long, long time | 16:29 |
| 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:30 |
| lbragstad | is anyone interested in doing the same with the cinder team? | 16:31 |
| lbragstad | FYI - our next policy meeting will be Tuesday, January 3rd | 16:31 |
| dolphm | ayoung: ++ | 16:32 |
| lbragstad | #action lbragstad to follow up with the nova team on #link https://review.openstack.org/#/c/377756/ | 16:32 |
| lbragstad | #action lbragstad to follow up with the cinder team on #link https://review.openstack.org/#/c/306930/ | 16:34 |
| lbragstad | does anyone have questions on this so far? | 16:35 |
| ayoung | As a reference to my earlier HTML statements | 16:35 |
| ayoung | this is the code here that needs to be primarily changed to make it wo0rk | 16:35 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/middleware/core.py#n76 | 16:35 |
| 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 |
| ayoung | I have an abandonded review from back in the XML-also days... | 16:36 |
| ayoung | https://review.openstack.org/#/c/24443/ | 16:36 |
| lbragstad | ayoung ready to move on to the next topic? | 16:36 |
| ayoung | yep | 16:36 |
| lbragstad | cool | 16:37 |
| lbragstad | #topic review policy use cases | 16:37 |
| *** openstack changes topic to "review policy use cases (Meeting topic: policy)" | 16:37 | |
| lbragstad | #link https://etherpad.openstack.org/p/keystone-policy-usecases | 16:37 |
| lbragstad | dstanek has been collapsing a bunch of usecases and documenting them ^ | 16:37 |
| lbragstad | we've been spending the last few weeks going through them | 16:37 |
| lbragstad | I wanted to double check with folks to give them another look - and see if we're missing anything | 16:38 |
| ayoung | Nicely cleaned up | 16:38 |
| ayoung | I wonder if this should now be posted as something like a cross-project spec? | 16:38 |
| lbragstad | ayoung i would agree with that - as the next logical step | 16:39 |
| lbragstad | maybe not so much as a cross project spec - but some formal document | 16:39 |
| lbragstad | something saying "these are things we need in a policy engine" | 16:40 |
| lbragstad | which actually is a nice transition to our next topic | 16:40 |
| lbragstad | #topic project tag for RBAC capabilities | 16:40 |
| ayoung | Heres a thought | 16:40 |
| *** openstack changes topic to "project tag for RBAC capabilities (Meeting topic: policy)" | 16:40 | |
| ayoung | why don't we move the standard roles to the top of that doc | 16:40 |
| ayoung | ahhhh...too slow | 16:40 |
| ayoung | before we transition... | 16:41 |
| lbragstad | ayoung go ahead | 16:41 |
| ayoung | lets move the standard roles to the top of the etherpad, and break the use cases up under them | 16:41 |
| ayoung | for example, we don't wamt a use case with any other actores | 16:41 |
| ayoung | liek the one | 16:41 |
| 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:41 |
| ayoung | THe protected resource is not the actor, that one should be moved to either the user or the admin | 16:42 |
| lbragstad | sure - that's one way we could organize it | 16:42 |
| ayoung | Let me do that now, and we can drive on. | 16:42 |
| lbragstad | ayoung want to do that at the bottom so we can keep the original? | 16:42 |
| lbragstad | ayoung just so we don't lose information | 16:43 |
| ayoung | Should not lose info... see? | 16:43 |
| lbragstad | ayoung yeah - that works | 16:44 |
| lbragstad | the reason for this topic was that there were discussion in Barcelona about proposing a tag for RBAC | 16:44 |
| lbragstad | s/tag/project tag/ | 16:45 |
| lbragstad | I think dolphm was the one who told me about that(?) | 16:45 |
| lbragstad | and I'm pretty sure this ties back to the cross project dolphm and jamielennox had for standarizing roles across projects | 16:46 |
| lbragstad | cross project spec* | 16:46 |
| 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 |
| lbragstad | does anyone else have thoughts? | 16:47 |
| samueldmq | lbragstad: I agree with you | 16:48 |
| samueldmq | lbragstad: we keystone bootstrap should have a command to setup the default roles | 16:49 |
| samueldmq | for an openstack deployment | 16:49 |
| lbragstad | it would be similar to our rolling upgrade tags | 16:49 |
| 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 |
| samueldmq | default roles/base roles | 16:49 |
| lbragstad | https://governance.openstack.org/tc/reference/tags/index.html#project-assertion-tags | 16:49 |
| lbragstad | #Link https://governance.openstack.org/tc/reference/tags/index.html#project-assertion-tags | 16:49 |
| lbragstad | it would be similar to those - but geared towards RBAC | 16:50 |
| lbragstad | It would require some work from us before the PTG to come up with some documentation | 16:50 |
| 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 |
| lbragstad | and a document for existing projects to be able to use as a roadmap for getting RBAC support | 16:51 |
| ayoung | One thing that might be good to flesh out is the service specific roles they would want | 16:52 |
| ayoung | I've alluded to that in the past in Neutron | 16:52 |
| lbragstad | ++ | 16:52 |
| lbragstad | right now that kind of documentation doesn't exist | 16:52 |
| 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 |
| *** Kiall has quit IRC | 16:53 | |
| lbragstad | ayoung that's a good question | 16:53 |
| lbragstad | and something we'll need to ask them in order to flesh these things out | 16:53 |
| 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:54 |
| ayoung | any other actions you think we need to do? | 16:55 |
| lbragstad | ayoung for an RBAC project assertion tag? | 16:55 |
| ayoung | or to prep for PTG in general? | 16:56 |
| 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:56 |
| lbragstad | as well as have a document documenting policy in openstack for new and existing projects | 16:57 |
| lbragstad | (something they can use to achieve sensible RBAC) | 16:57 |
| lbragstad | and start using keystone as an example | 16:57 |
| 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 |
| lbragstad | (it's going to be hard to get other projects to follow our lead when we haven't followed it) | 16:58 |
| ayoung | And, how wide a net do we need to cast? | 16:58 |
| lbragstad | I'd love to cast a wider net | 16:58 |
| 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 |
| lbragstad | going to have to wrap up here - if anyone has left over questions, let's head to #openstack-keystone | 16:59 |
| lbragstad | thanks folks! | 17:00 |
| lbragstad | #endmeeting | 17:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 17:00 | |
| openstack | Meeting ended Wed Dec 21 17:00:03 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-21-16.01.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-21-16.01.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-21-16.01.log.html | 17:00 |
| *** gagehugo has left #openstack-meeting-cp | 17:00 | |
| *** ruan_11 has quit IRC | 17:01 | |
| *** openstack has quit IRC | 17:02 | |
| *** openstack has joined #openstack-meeting-cp | 17:04 | |
| *** ChanServ sets mode: +o openstack | 17:04 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 17:18 | |
| *** ducttape_ has joined #openstack-meeting-cp | 17:23 | |
| *** ducttape_ has quit IRC | 17:36 | |
| *** ducttape_ has joined #openstack-meeting-cp | 17:44 | |
| *** ducttape_ has quit IRC | 17:57 | |
| *** brault is now known as brault|away | 17:58 | |
| *** ducttape_ has joined #openstack-meeting-cp | 18:00 | |
| *** ducttape_ has quit IRC | 18:18 | |
| *** ducttape_ has joined #openstack-meeting-cp | 18:30 | |
| *** hogepodge has quit IRC | 18:46 | |
| *** ducttape_ has quit IRC | 19:00 | |
| *** stvnoyes1 has joined #openstack-meeting-cp | 19:08 | |
| *** stvnoyes has quit IRC | 19:11 | |
| *** hogepodge has joined #openstack-meeting-cp | 19:12 | |
| *** stvnoyes1 has quit IRC | 19:22 | |
| *** stvnoyes has joined #openstack-meeting-cp | 19:23 | |
| *** ducttape_ has joined #openstack-meeting-cp | 19:35 | |
| *** gouthamr has quit IRC | 19:39 | |
| *** ducttape_ has quit IRC | 19:48 | |
| *** ducttape_ has joined #openstack-meeting-cp | 19:52 | |
| *** gouthamr has joined #openstack-meeting-cp | 20:03 | |
| *** robcresswell has left #openstack-meeting-cp | 20:10 | |
| *** ducttape_ has quit IRC | 20:12 | |
| *** diablo_rojo_phon has quit IRC | 20:30 | |
| *** diablo_rojo has quit IRC | 21:02 | |
| *** ducttape_ has joined #openstack-meeting-cp | 21:12 | |
| *** ducttape_ has quit IRC | 21:17 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 21:36 | |
| *** gouthamr has quit IRC | 21:58 | |
| *** sdague has quit IRC | 22:35 | |
| *** ducttape_ has joined #openstack-meeting-cp | 22:43 | |
| *** ducttape_ has quit IRC | 22:48 | |
| *** gouthamr has joined #openstack-meeting-cp | 22:53 | |
| *** xyang1 has quit IRC | 22:58 | |
| *** lamt has quit IRC | 23:32 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!