| *** lamt has quit IRC | 00:02 | |
| *** itisha has quit IRC | 00:12 | |
| *** ativelkov has quit IRC | 00:15 | |
| *** ativelkov has joined #openstack-meeting-cp | 00:17 | |
| *** ducttape_ has joined #openstack-meeting-cp | 00:17 | |
| *** harlowja has joined #openstack-meeting-cp | 00:30 | |
| *** ducttape_ has quit IRC | 00:53 | |
| *** markvoelker has quit IRC | 01:29 | |
| *** piet has joined #openstack-meeting-cp | 01:29 | |
| *** ativelkov has quit IRC | 01:40 | |
| *** ativelkov has joined #openstack-meeting-cp | 01:40 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:53 | |
| *** ducttape_ has quit IRC | 01:55 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:55 | |
| *** ducttape_ has quit IRC | 02:09 | |
| *** ducttape_ has joined #openstack-meeting-cp | 02:21 | |
| *** ducttape_ has quit IRC | 02:56 | |
| *** EmilienM has quit IRC | 03:19 | |
| *** EmilienM has joined #openstack-meeting-cp | 03:20 | |
| *** coolsvap has joined #openstack-meeting-cp | 03:27 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:30 | |
| *** markvoelker has quit IRC | 03:35 | |
| *** piet has quit IRC | 03:35 | |
| *** prateek has joined #openstack-meeting-cp | 03:49 | |
| *** ducttape_ has joined #openstack-meeting-cp | 03:57 | |
| *** ducttape_ has quit IRC | 04:01 | |
| *** prateek has quit IRC | 04:31 | |
| *** ducttape_ has joined #openstack-meeting-cp | 04:33 | |
| *** ducttape_ has quit IRC | 04:44 | |
| *** prateek has joined #openstack-meeting-cp | 05:09 | |
| *** prateek has quit IRC | 05:09 | |
| *** prateek has joined #openstack-meeting-cp | 05:14 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:31 | |
| *** markvoelker has quit IRC | 05:37 | |
| *** ducttape_ has joined #openstack-meeting-cp | 05:44 | |
| *** ducttape_ has quit IRC | 05:49 | |
| *** markvoelker has joined #openstack-meeting-cp | 07:00 | |
| *** ducttape_ has joined #openstack-meeting-cp | 07:04 | |
| *** markvoelker has quit IRC | 07:06 | |
| *** ducttape_ has quit IRC | 07:24 | |
| *** MarkBaker has quit IRC | 08:07 | |
| *** ducttape_ has joined #openstack-meeting-cp | 08:25 | |
| *** ducttape_ has quit IRC | 08:30 | |
| *** markvoelker has joined #openstack-meeting-cp | 09:02 | |
| *** markvoelker has quit IRC | 09:07 | |
| *** itisha has joined #openstack-meeting-cp | 09:39 | |
| *** ducttape_ has joined #openstack-meeting-cp | 09:56 | |
| *** ducttape_ has quit IRC | 10:00 | |
| *** MarkBaker has joined #openstack-meeting-cp | 10:02 | |
| *** paquito12323 has joined #openstack-meeting-cp | 10:31 | |
| paquito12323 | hello | 10:32 |
|---|---|---|
| *** paquito12323 has quit IRC | 10:33 | |
| *** MarkBaker has quit IRC | 10:56 | |
| *** markvoelker has joined #openstack-meeting-cp | 11:02 | |
| *** markvoelker has quit IRC | 11:07 | |
| *** sdague has joined #openstack-meeting-cp | 11:08 | |
| *** prateek_ has joined #openstack-meeting-cp | 11:21 | |
| *** prateek has quit IRC | 11:21 | |
| *** ducttape_ has joined #openstack-meeting-cp | 11:26 | |
| *** ducttape_ has quit IRC | 11:31 | |
| *** MarkBaker has joined #openstack-meeting-cp | 11:52 | |
| *** prateek_ has quit IRC | 12:14 | |
| *** ducttape_ has joined #openstack-meeting-cp | 12:57 | |
| *** ducttape_ has quit IRC | 13:01 | |
| *** markvoelker has joined #openstack-meeting-cp | 13:03 | |
| *** markvoelker has quit IRC | 13:08 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:09 | |
| *** bastafidli has joined #openstack-meeting-cp | 13:17 | |
| *** markvoelker has joined #openstack-meeting-cp | 13:24 | |
| *** bastafidli has quit IRC | 13:33 | |
| *** lamt has joined #openstack-meeting-cp | 13:35 | |
| *** lamt has quit IRC | 13:39 | |
| *** ducttape_ has quit IRC | 13:45 | |
| *** tongli has joined #openstack-meeting-cp | 13:56 | |
| topol | reminder: InteropChallenge meeting is now held in #openstack-meeting-5 and due to DST starts at 9am EST (NOW!) | 14:04 |
| *** bastafidli has joined #openstack-meeting-cp | 14:05 | |
| *** ducttape_ has joined #openstack-meeting-cp | 14:15 | |
| *** ducttape_ has quit IRC | 14:34 | |
| *** MarkBaker has quit IRC | 14:38 | |
| *** gouthamr has joined #openstack-meeting-cp | 14:43 | |
| *** tongli has left #openstack-meeting-cp | 14:48 | |
| *** MarkBaker has joined #openstack-meeting-cp | 14:49 | |
| *** jaugustine has joined #openstack-meeting-cp | 15:00 | |
| *** Rockyg has joined #openstack-meeting-cp | 15:08 | |
| *** gouthamr has quit IRC | 15:13 | |
| *** gouthamr has joined #openstack-meeting-cp | 15:15 | |
| *** ducttape_ has joined #openstack-meeting-cp | 15:16 | |
| *** jaugustine has quit IRC | 15:18 | |
| *** cebreidian_ has quit IRC | 15:30 | |
| *** spilla has joined #openstack-meeting-cp | 15:55 | |
| *** jaugustine has joined #openstack-meeting-cp | 15:57 | |
| *** _ducttape_ has joined #openstack-meeting-cp | 15:57 | |
| *** ayoung has joined #openstack-meeting-cp | 15:58 | |
| *** ruan_05 has joined #openstack-meeting-cp | 15:59 | |
| lbragstad | #startmeeting policy | 16:00 |
| openstack | Meeting started Wed Dec 14 16:00:07 2016 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:00 | |
| openstack | The meeting name has been set to 'policy' | 16:00 |
| ayoung | Oyez oyez | 16:00 |
| lbragstad | ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ayoung, ruan_05 | 16:00 |
| *** ducttape_ has quit IRC | 16:00 | |
| rderose | o/ | 16:00 |
| *** edmondsw has joined #openstack-meeting-cp | 16:01 | |
| *** MarkBaker has quit IRC | 16:01 | |
| *** gouthamr has quit IRC | 16:01 | |
| *** gagehugo has joined #openstack-meeting-cp | 16:02 | |
| lbragstad | we'll give it a minute or two | 16:02 |
| ayoung | Agenda link? | 16:02 |
| edmondsw | gonna try to be in 2 meetings at once, so we'll see how that goes | 16:02 |
| lbragstad | #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:02 |
| ruan_05 | you have a question for me during the last meeting? | 16:02 |
| *** dolphm has joined #openstack-meeting-cp | 16:03 | |
| ruan_05 | External PDP and PEP hooks in oslo.policy [ruan] | 16:03 |
| lbragstad | ruan_05 you had a topic on the agenda last meeting | 16:03 |
| *** diablo_rojo_phon has joined #openstack-meeting-cp | 16:03 | |
| lbragstad | ruan_05 do you want to go through that today? | 16:03 |
| ruan_05 | yes | 16:03 |
| lbragstad | ruan_05 alright - i'll add it | 16:03 |
| ayoung | So...how would we write the following as a use case? | 16:04 |
| *** gouthamr has joined #openstack-meeting-cp | 16:04 | |
| lbragstad | let's wait for dstanek to show up | 16:04 |
| lbragstad | he's been trying to collect a bunch of them | 16:04 |
| ayoung | Two users need to collaborate. They need a shared Network for their servers to talk on, but they each want to maintain controll of their own resources | 16:04 |
| ayoung | And, related | 16:05 |
| ayoung | Two users want to collaborate. One owns the quota for the servers, the other the storage | 16:05 |
| ayoung | are those embedded in the existing use cases, or are they new ones? | 16:05 |
| *** gouthamr has quit IRC | 16:06 | |
| lbragstad | #topic Review policy use cases | 16:06 |
| *** openstack changes topic to "Review policy use cases (Meeting topic: policy)" | 16:06 | |
| lbragstad | #link https://etherpad.openstack.org/p/keystone-policy-usecases | 16:06 |
| lbragstad | ayoung those sound like new usecases | 16:06 |
| rderose | lbragstad:++ | 16:07 |
| lbragstad | ayoung so - as a user I want to be able to share resources with other users within my domain/project? | 16:08 |
| ayoung | the second one is actually the MOC Hardware federation one, but scaled back a bit | 16:08 |
| ayoung | lbragstad, I was trying to avoid talking about projects in the definition | 16:08 |
| lbragstad | ayoung are we talking about collaboration across all users regardless of the domain they are in? | 16:09 |
| lbragstad | domain/project/whatever? | 16:09 |
| ayoung | I had been thinking about these in terms of HMT, but yes, the idea is that, the way that Nova is defineid, all of the resources in play need to be in the same project , at least for the second use case | 16:09 |
| ayoung | for the first one, it might be possible to link two servers together in different projects, making all the trickiness happen at the Neutron level | 16:10 |
| lbragstad | ayoung what exactly do you mean by owning the quota and owning the storage? | 16:10 |
| edmondsw | ayoung I just assumed that first usecase would have the network shared across 2 projects... which you can already do | 16:10 |
| ayoung | edmondsw, yes, but don't you need an admin to set up that network for you now? | 16:11 |
| ayoung | as a non-admin user, there is no way to share a resource across projects | 16:11 |
| lbragstad | but don't users really only care about things *in* their project? | 16:11 |
| edmondsw | ayoung oh, you want the non-admin to actually be the one to initiate sharing? I didn't get that from the first read | 16:11 |
| edmondsw | ayoung I don't know if you could do that today or not | 16:12 |
| ayoung | edmondsw, lbragstad so, lets think alongthe lines of "how can we push capabilities down to the lowest level without breaking security" | 16:12 |
| ayoung | right now, everything is in a project, and a user has the same power on all resources of the same class | 16:13 |
| *** MarkBaker has joined #openstack-meeting-cp | 16:13 | |
| edmondsw | https://github.com/openstack/neutron/blob/master/etc/policy.json#L50 looks like allowing non-admin would require a policy change | 16:13 |
| ayoung | if we want people to have different levels of access in a single compute setup, how do we enforce that? | 16:13 |
| ayoung | Is i a question of mixing things from two different projects, or do we need to provide some gradiation of capability for the same type of resource withing a single project? | 16:14 |
| ayoung | edmondsw, is a shared network a global resource, or is it explicitly shared between two projects? | 16:15 |
| lbragstad | it sounds like the gradient comes from service attributes about the resource | 16:15 |
| edmondsw | ayoung a shared network belongs to one project, but can also be seen/used in others | 16:15 |
| ayoung | edmondsw, see, that is the abstraction I would like to see across the board | 16:16 |
| ayoung | inode vs dentry in Filesystem speak | 16:16 |
| edmondsw | neutron has done some good things with policy as far as allowing flexibility | 16:16 |
| edmondsw | I assume the solution to your second usecase about quotas would follow some examples from neutron, actually | 16:16 |
| lbragstad | i agree that it should be possible to do that - but I'd still like to maintain the ability to keep my project a black box, too | 16:17 |
| ayoung | edmondsw, yeah, the volume created in cinder is kindof like the shared network | 16:17 |
| edmondsw | neutron doesn't just have a check for create_network... they also have multiple other checks that they'll test if you try to create networks with certain parameters. | 16:17 |
| ayoung | I want it owned by Proj1, but used in Proj2 | 16:17 |
| *** bastafidli has quit IRC | 16:18 | |
| edmondsw | you could do the same kind of thing for different types of quotas | 16:18 |
| edmondsw | have one check to determine whether you're allowed to change quotas at all, and another to determine if you're allowed to change a specific quota | 16:18 |
| ayoung | edmondsw, I think of quoats in terms of HMT. They are resources managed by the containing project | 16:19 |
| lbragstad | ayoung I added your first use case to the etherpad | 16:19 |
| ayoung | lbragstad, Thanks | 16:19 |
| ayoung | lbragstad, that is one of the questions that lead to this group being forms | 16:20 |
| ayoung | fomred | 16:20 |
| edmondsw | ayoung I don't think I said anything conflicting with that | 16:20 |
| ayoung | formed | 16:20 |
| ayoung | edmondsw, right, I think that they go hand in hand | 16:20 |
| edmondsw | ayoung maybe I didn't understand your use case | 16:20 |
| lbragstad | ayoung edmondsw are we talking about the second one from above or a different one? | 16:20 |
| ayoung | If I have a "quota" role on the parent, I can adjust the quota levels on the child projects | 16:21 |
| edmondsw | ayoung I thought you wanted project-level quota A to be changeable by user A and another project-level quota B (for the same project) changeable by another user | 16:21 |
| ayoung | but I don't know if that is relvant here | 16:21 |
| ayoung | I think quota even in my use cases would be applied only on the project where the resource is created | 16:21 |
| ayoung | edmondsw, Ah, no. I didn't specify that. | 16:22 |
| *** thinrichs has joined #openstack-meeting-cp | 16:22 | |
| ayoung | It kind of implies a level between user and project, though | 16:23 |
| ayoung | which is one way we coud go: resource groups inside a project. | 16:23 |
| edmondsw | I'm confused :) | 16:23 |
| ayoung | It would be a more granular label than just the project ID, but more course grained than userid | 16:23 |
| ayoung | edmondsw, all of this resolves to scope check | 16:23 |
| lbragstad | I am, too... I'm not sure what use case we're talking abou t | 16:24 |
| ayoung | right now, the only scope check we have is the project one | 16:24 |
| ayoung | and openstack (with small exceptions) assumes all resources for something are in the same project | 16:24 |
| ayoung | and all resources of the same type have the same access control | 16:24 |
| ayoung | we've had several requests for "you can't power off my VMs" type access control | 16:25 |
| lbragstad | an example being all instances created within a project | 16:25 |
| ayoung | lbragstad, right | 16:25 |
| ayoung | lbragstad, say we havea project which is the development area for a project team | 16:25 |
| lbragstad | so - as a user, you want to tie operations to specific resources in a project | 16:25 |
| ayoung | lbragstad, that is one way to define it | 16:26 |
| ayoung | I'm trying to make the use case more general | 16:26 |
| ayoung | such that we don't necessariuly need to redefinie the project scoping everywhere | 16:26 |
| lbragstad | it sounds like project scoping would be the loosened version of this type of checking | 16:27 |
| ayoung | but we don't currentl have any operationes which check your roles on two different projects | 16:27 |
| ayoung | one possibility is that you use two tokens, one for each project in an operation | 16:27 |
| ayoung | say we have a "mount" operation that exposes a volume created in one project to be mountable in a second project | 16:28 |
| ayoung | would that be better or worse than trying to change the scope/permissions inside a single project? | 16:28 |
| lbragstad | from a usability perspective - that only really makes sense for operations across projects, which i think is a different use case from being able to tighten operations other people can do on resources I've created | 16:28 |
| ayoung | Would it be more useful, more powerful? | 16:28 |
| ayoung | lbragstad, ah, but with HMT, we can solve the "what can yo udo on my resources" | 16:29 |
| ayoung | create a parent project for dev, give each developer their own sub projects | 16:29 |
| ayoung | So if You do this, and the developers themselves want to be able to set up networking accross their individual projects to collaborate, we should be able to do that without making any of them admin | 16:30 |
| lbragstad | well - that kind of solves the problem because you're creating more isolation which leads to using role assignments for access across the projects | 16:30 |
| ayoung | or if they want to share volumes, etc | 16:31 |
| ayoung | lbragstad, right, that is how I've been thinking of the problem thus far | 16:31 |
| lbragstad | but what happens if I don't have HMT | 16:31 |
| lbragstad | and I want to be able to give my users the same type of flexibility | 16:31 |
| ayoung | lbragstad, why would you not have HMT? | 16:31 |
| ayoung | It is par of Keystone | 16:31 |
| lbragstad | sure - just thinking about cases | 16:31 |
| ayoung | you mean, what if you don't want to use it in a specific case? | 16:31 |
| lbragstad | sure | 16:32 |
| ayoung | right, so that is why I was trying to phrase the use case moregenerally | 16:32 |
| ayoung | I think you all get the point I was trying to make. | 16:32 |
| lbragstad | let's say I have a set of users and they all live within the same project, is it useful to have the same flexibility | 16:32 |
| lbragstad | right | 16:32 |
| *** _ducttape_ has quit IRC | 16:32 | |
| lbragstad | so the use case sounds like 'as a user, i want to be able to restrict or open up specific operations on resources I create' | 16:33 |
| lbragstad | s/create/own/ | 16:33 |
| ayoung | So, if they are in the same project, we need a way to distinguish access rights on two different resources of the same type | 16:33 |
| *** ducttape_ has joined #openstack-meeting-cp | 16:33 | |
| ayoung | lbragstad, but what if *you* leave the project | 16:33 |
| lbragstad | which could span the same project or multiple | 16:33 |
| ayoung | I need to be able to transition your resources to, say ruan_05 | 16:33 |
| lbragstad | right | 16:33 |
| ayoung | without tearing them down? | 16:33 |
| lbragstad | or delete them, or whatever | 16:33 |
| lbragstad | that would seem to fall on the admin's shoulders either way | 16:34 |
| ruan_05 | fine granularity of access control inside a project | 16:34 |
| lbragstad | right? | 16:34 |
| ayoung | admin scoped to the project should probably be OK with tearing them down, but that implies that we solve 968696 | 16:34 |
| ayoung | 4we need the power of something like admin scoped to a project without that admin being able to go all over the cloud and break things | 16:35 |
| ayoung | So RBAC can handle that piece | 16:35 |
| lbragstad | say i rage quit the project and my manager has to come in an dedicate my resources to ruan_05, or delete them, or both | 16:35 |
| ayoung | lbragstad, purely theoretical | 16:35 |
| ayoung | :) | 16:36 |
| lbragstad | right | 16:36 |
| lbragstad | ;) | 16:36 |
| ayoung | so manager delete can be done with RBAC | 16:36 |
| ayoung | transition...I guess is just a new API on the resource | 16:36 |
| lbragstad | but they would have to transition something | 16:36 |
| ayoung | a PATCH with user_id.... | 16:36 |
| ayoung | IFF we do user level ownership | 16:36 |
| lbragstad | that way ruan_05 would get all the abilities i had when i was on the project | 16:37 |
| ayoung | and, how do we distinguish that a resource should have user level policy versus project level | 16:37 |
| ayoung | mix and match that in the same cloud? | 16:37 |
| lbragstad | well - i can only think of cases where user level is more strict that project level | 16:37 |
| ruan_05 | why can't we have both? | 16:37 |
| lbragstad | which sounds like keeping project level the default and opting into user level | 16:38 |
| lbragstad | ruan_05 that's a good point, too | 16:38 |
| lbragstad | say I don't care about exposing my instances to the rest of the people in my project, but I *do* care about my cinder volumes because that's where my data is | 16:38 |
| ayoung | so, this gets into what ruan_05 did with Moon. They extracted that information, what policy, who owns etc, into an external database | 16:38 |
| ayoung | The unix model is 3 tiered: user, group, world | 16:39 |
| ruan_05 | our approach is one access control policy per project | 16:39 |
| ayoung | ruan_05, so how many distinct projects are we talking about? | 16:40 |
| ayoung | and...is that for all apis, or just a subset? | 16:40 |
| ruan_05 | as many as you want | 16:40 |
| thinrichs | ruan_05: and can you share resources between projects? | 16:40 |
| thinrichs | (which policy would govern shared resources?) | 16:41 |
| ayoung | ruan_05, its not what *I* want, it is what is the intention of the deployment. If there are millions of projects, its going to be essnetially a new policy for each operations, | 16:41 |
| ruan_05 | currently, we cannot share them between projects due to the openstack project isolation, theorically that's possible | 16:41 |
| thinrichs | ayoung: people have *millions* of projects? | 16:42 |
| thinrichs | even thousands? | 16:42 |
| ayoung | thinrichs, is that really inconceivable? | 16:42 |
| ruan_05 | ayoung: i consider this mechanism as an option, they can deactivate it | 16:42 |
| ayoung | thinrichs, thousands certainly | 16:42 |
| lbragstad | yeah | 16:42 |
| ayoung | ruan_05, so...lets back off the solutions for a bit...I was trying to use them to illuminate the use cases | 16:43 |
| ruan_05 | if user doesn't want finer control, they use default policy | 16:43 |
| thinrichs | How do they get to thousands of projects? One per user? | 16:43 |
| lbragstad | i attempted to add the user cases to the etherpad | 16:43 |
| ayoung | thinrichs, multiple per user | 16:43 |
| lbragstad | thinrichs that's a possibility, too | 16:43 |
| ayoung | one per user per task | 16:43 |
| lbragstad | thinrichs as a sign up service, i could create a new project for every customer that signs up for my service | 16:44 |
| thinrichs | Then sharing resources across projects seems like a clear use case. | 16:44 |
| ruan_05 | ayoung: if you only have one user in a project, you don't need access control | 16:44 |
| ayoung | ruan_05, only one user creating the project, but then they provide access to other users | 16:44 |
| ayoung | like directories | 16:44 |
| ayoung | I'm admin on my projects, you get _memer_ | 16:44 |
| thinrichs | lbragstad, ayoung: thanks for the background! | 16:44 |
| ayoung | member | 16:44 |
| ruan_05 | in this case, the owner decides who can access which resource | 16:45 |
| lbragstad | but we're implying owner because there is only one admin per project | 16:45 |
| ayoung | right, but who decides what policy approach they can take? | 16:45 |
| ruan_05 | if the owner doesn't want to do that, he uses default policy | 16:45 |
| lbragstad | owner isn't being implied by the actual resource itself | 16:45 |
| ayoung | Is the default policy always the baseline, and then they can "tighten it up" from there? | 16:46 |
| ruan_05 | ayoung: you can leave this choice to users | 16:46 |
| lbragstad | 14 minute mark | 16:46 |
| lbragstad | we've got some additional use cases and i'll continue to clarify them with dstanek (and anyone else who is interested) | 16:46 |
| ayoung | ruan_05, no you can't, because if a user can change policy on any API, it is an elevation of privs attack | 16:46 |
| ayoung | one other possiblity is to do something like "project specific roles" | 16:47 |
| ruan_05 | when a user creates a project, he can decide whether to use default policy or create his own | 16:47 |
| ayoung | ie...a set of roles, or groups, that only apply within a specific project | 16:47 |
| ayoung | and you could label resources, and have matching rules between roles and labels | 16:48 |
| ayoung | more complex than I really want to get in to | 16:48 |
| ruan_05 | ayoung: there jobs should be done by project owner | 16:48 |
| ayoung | Do we need to run through any of the other use cases explicitly? | 16:49 |
| lbragstad | i think that's it | 16:49 |
| lbragstad | i encourage everyone to keep thinking about them though | 16:49 |
| lbragstad | and revisiting the ones we came up with last wekk | 16:49 |
| lbragstad | week* | 16:49 |
| lbragstad | sound good? | 16:50 |
| lbragstad | i want to give ruan_05 some time to go through the topic he had last week | 16:50 |
| lbragstad | i'll push the capabilities topic to next week | 16:51 |
| lbragstad | #topic External PDP and PEP hooks in oslo.policy | 16:51 |
| *** openstack changes topic to "External PDP and PEP hooks in oslo.policy (Meeting topic: policy)" | 16:51 | |
| lbragstad | ruan_05 | 16:51 |
| lbragstad | you're up | 16:51 |
| ruan_05 | we've tried to modify oslo.policy to redirect requests to an external PDP | 16:52 |
| ruan_05 | it seems work well | 16:52 |
| lbragstad | ruan_05 did you base that work on what ktychkova was doing? | 16:52 |
| lbragstad | ruan_05 or was this a separate effort? | 16:52 |
| ruan_05 | yes, the AP review | 16:53 |
| lbragstad | so #link https://review.openstack.org/#/c/237521/ specifically | 16:53 |
| lbragstad | ruan_05 did you end up getting around the global role problem? | 16:53 |
| ruan_05 | i think we can provide a general policy "hook" to support external PDP | 16:54 |
| ruan_05 | in our test, we bypasse the global role | 16:54 |
| lbragstad | how so? | 16:55 |
| lbragstad | apache fortress treats roles globally across the deployment, right? | 16:55 |
| ruan_05 | we don't use AF, but another PDP | 16:55 |
| lbragstad | oh | 16:55 |
| lbragstad | what did you use? | 16:55 |
| ruan_05 | Moon | 16:56 |
| ruan_05 | Moon is an attribute-based access control policy engine | 16:56 |
| lbragstad | ruan_05 right - did you have to make any additional modifications to the oslo.policy review? | 16:56 |
| ruan_05 | some slight one | 16:56 |
| lbragstad | ruan_05 are they documented anywhere? | 16:57 |
| lbragstad | or is there a review? | 16:57 |
| ruan_05 | no, not yet, we just want to test if https://review.openstack.org/#/c/237521/ can support other PDP | 16:57 |
| ruan_05 | and we are convinced that https://review.openstack.org/#/c/237521/ is a good approch | 16:58 |
| ruan_05 | for you information, before, we added the policy hook in Keystonemiddleware | 16:58 |
| lbragstad | ruan_05 i'd be curious to see what the changes were and how it worked | 16:58 |
| ruan_05 | I can send you some code, but not the final version | 16:59 |
| lbragstad | ruan_05 posting a review publicly would be nice, that way others can see it and try it out, too | 16:59 |
| thinrichs | I'd be interested too | 16:59 |
| ruan_05 | ok, I'll do it | 16:59 |
| *** piet has joined #openstack-meeting-cp | 17:00 | |
| lbragstad | ruan_05 cool - i'll document that in the agenda | 17:00 |
| lbragstad | that about wraps up our meeting | 17:00 |
| lbragstad | thanks for coming! | 17:00 |
| lbragstad | if there are additional things to discuss - head over to #openstack-keystone | 17:00 |
| lbragstad | #endmeeting | 17:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 17:00 | |
| openstack | Meeting ended Wed Dec 14 17:00:36 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-14-16.00.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-14-16.00.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-14-16.00.log.html | 17:00 |
| *** thinrichs has left #openstack-meeting-cp | 17:00 | |
| *** gagehugo has left #openstack-meeting-cp | 17:01 | |
| *** spilla has left #openstack-meeting-cp | 17:01 | |
| *** piet has quit IRC | 17:05 | |
| *** edmondsw has left #openstack-meeting-cp | 17:06 | |
| *** ruan_05 has quit IRC | 17:07 | |
| *** edtubill has joined #openstack-meeting-cp | 17:14 | |
| *** MarkBaker has quit IRC | 17:17 | |
| *** piet has joined #openstack-meeting-cp | 17:45 | |
| *** Rockyg has quit IRC | 18:07 | |
| *** david-lyle has quit IRC | 18:21 | |
| *** markvoelker has quit IRC | 18:29 | |
| *** david-lyle has joined #openstack-meeting-cp | 18:30 | |
| *** piet has quit IRC | 18:31 | |
| *** markvoelker has joined #openstack-meeting-cp | 18:35 | |
| *** ducttape_ has quit IRC | 18:39 | |
| *** diablo_rojo_phon has quit IRC | 18:50 | |
| *** ducttape_ has joined #openstack-meeting-cp | 18:50 | |
| *** lamt has joined #openstack-meeting-cp | 19:03 | |
| *** jgriffith is now known as jgriffith_AutoAw | 19:10 | |
| *** coolsvap has quit IRC | 19:19 | |
| *** bastafidli has joined #openstack-meeting-cp | 19:25 | |
| *** sdague has quit IRC | 19:43 | |
| *** sdague has joined #openstack-meeting-cp | 19:46 | |
| *** ayoung has quit IRC | 19:59 | |
| *** jgriffith_AutoAw is now known as jgriffith | 20:02 | |
| *** stvnoyes has quit IRC | 20:24 | |
| *** stvnoyes has joined #openstack-meeting-cp | 20:24 | |
| *** gouthamr has joined #openstack-meeting-cp | 20:33 | |
| *** ayoung has joined #openstack-meeting-cp | 20:46 | |
| *** ayoung has quit IRC | 20:49 | |
| *** jgriffith is now known as jgriffith_AutoAw | 20:53 | |
| *** _ducttape_ has joined #openstack-meeting-cp | 20:58 | |
| *** ducttape_ has quit IRC | 21:02 | |
| *** lamt has quit IRC | 21:02 | |
| *** _ducttape_ has quit IRC | 21:09 | |
| *** ducttape_ has joined #openstack-meeting-cp | 21:10 | |
| *** jgriffith_AutoAw is now known as jgriffith | 21:18 | |
| *** jgriffith is now known as jgriffith_AutoAw | 21:40 | |
| *** itisha has quit IRC | 21:42 | |
| *** jgriffith_AutoAw is now known as jgriffith | 21:45 | |
| *** bastafidli has quit IRC | 22:01 | |
| *** beekhof has quit IRC | 22:05 | |
| *** lamt has joined #openstack-meeting-cp | 22:17 | |
| *** edtubill has quit IRC | 22:26 | |
| *** jgriffith is now known as jgriffith_AutoAw | 22:39 | |
| *** gouthamr has quit IRC | 22:45 | |
| *** jgriffith_AutoAw is now known as jgriffith | 22:51 | |
| *** ducttape_ has quit IRC | 22:51 | |
| *** gouthamr has joined #openstack-meeting-cp | 22:57 | |
| *** jaugustine has quit IRC | 23:12 | |
| *** ducttape_ has joined #openstack-meeting-cp | 23:24 | |
| *** sdague has quit IRC | 23:31 | |
| *** bastafidli has joined #openstack-meeting-cp | 23:52 | |
| *** bastafidli has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!