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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
