Open Stack

In the design that we have been building for a policy administration
database, we dont require a single policy in order to unify common
concepts such as hierarchical attributes and roles between the different
policies of Openstack services. This is because policies and hierarchies
are held separately and are linked via a many to many relationship. My
understanding of Adam's primary requirement was that a role hierarchy
say, should be common across all OpenStack service policies, without
this necessarily meaning you have to have one huge policy. And there is
no requirement for Keystone to own all the policies. So each service
could still own and manage its own policy, whilst having attribute
hierarchies in common.

Does this help?

regards

David

On 03/06/2015 18:43, Sean Dague wrote:
> On 06/03/2015 10:10 AM, Adam Young wrote:
>> I gave a presentation on Dynamic Policy for Access Control at the Summit.
>>
>> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dynamic-policy-for-access-control
>>
>>
>> My slides are here:
>> http://adam.younglogic.com/presentations/dynamic_policy.pp.pdf
>>
>>
>> My original blog post attempted to lay out the direction:
>>
>> http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
>>
>> And the Overview spec is here:
>> https://review.openstack.org/#/c/147651/
>>
>>
>> This references multiple smaller specs:
>>
>> A unified policy file:
>> https://review.openstack.org/134656
> 
> The unified policy file, as an actual single file is part of this
> process which I'm concerned isn't workable unless all OpenStack
> components are upgraded lock step, which is actually a situation we want
> to do less of, not more of.
> 
> Assume that Keystone git tree owns that file. Nova adds an API via
> microversions for an intermediate milestone that adds new policy in.
> Deployers CD this version out, leaving Keystone at the previous release
> version. Now Nova has code out there that requires policy which doesn't
> exist. The policy at some level is really linked to the code.
> 
> In a world of microversions this is now a lot more like database schema,
> because big bang API changes are a thing of the past (at least on the
> Nova side). (Note: I'm working up some more general explanation of that
> whole model shortly, part of our comms plan out of summit).
> 
> 	-Sean
>