RFC Feature Planning: Permissions Denormalization

Scott Seago sseago at redhat.com
Wed Apr 4 17:46:13 UTC 2012


On 04/04/2012 01:31 PM, Jason Guiditta wrote:
> On 30/03/12 09:37 -0400, Scott Seago wrote:
>> Rather than paste in the entire text, I'm just linking to the wiki 
>> writeup. Please read the whole thing first and if you want to comment 
>> on anything specific, quote it and comment on this thread.
>>
>> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Permission_record_denormalization 
>>
>>
>> Scott
>>
>
> you say in that page:
> 'As for UI, we won't need any get/set UI, although it might be useful
> to make the permissions UI "swappable" -- i.e. a toggle to switch
> between direct grants (that you can add/remove) and derived grants (so
> you can see in one place everyone that has access to the resource).'
>
> What about api? Is there any expectation of needing to allow a user
> to manipulate any of this, or would it all be exposed in some other
> way? I suspect no, as this looks to be all done behind the scenes,
> just curious.
>
API a separate question entirely. The whole point of the permissions 
denormalization is that it does _not_ affect the get/set API -- the 
records that are manipulated by the UI are unchanged by denormalization 
-- the new objects are maintained via hooks.

Now if you ask "what about a permissions get/set API?" -- why, yes, we 
need that -- whether or not we denormalize the permissions, so I'd 
consider that out of scope for the 'denormalizaiton' effort but it 
should definitely be included among the "build out API for $foo" tasks 
(along with launching instances, creating providers, etc.)
> I don't see mention of any of the *_image family of objects, but they
> would be included in this, as they will reside in conductor db now,
> yes?
>
Sure, but that's not part of this work. This task is to take the current 
models that are permissioned and denormalize them. Part of the "pull 
images into Conductor" work will include making sure the new Image model 
includes PermissionedObject, works with list_for_user, etc.

If the new image work is done _after_ denormalization impl, then the new 
image models will simply implement permissions using the new model from 
day one.
> Aside from those minor clarification points, this looks like a good
> improvement to the perms structure.
>
> -j
Scott




More information about the aeolus-devel mailing list