On 06/03/2015 02:55 PM, Sean Dague wrote:
On 06/03/2015 02:44 PM, David Chadwick wrote:
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
That part makes total sense. What concerned me is there was an
intermediary step that seemed like it was literally *one file*
(https://review.openstack.org/134656). That particular step I think is
unworkable.
How is this for an approach:
1. Unified policy file that is just the union of what is in the
current projects. Each project will have a clearly marked section.
2. Split up the main file into sections, one per each project, and put
those in separate files. Build system will concatenate them into a
single file.
3. Allow each of the projects to replace their section of the file with
file containing just an URL to the upstream git repo that contains their
project specific section. When building the overall unified policy
file, those projects that have their own section will get it merged in
from their own repos.
4. Eventually, the unified policy file will be expected to be built out
of each of the projects git repos.
I agree with you that we want the projects to manage their own, I just
think we need a scrub step where we all look at the individual sections
together with a critical eye first.
By "common role hierachy" do you mean namespaced roles for services?
Because if yes, definitely. And I think that's probably the first
concrete step moving the whole thing forward, which should be doable on
the existing static json definitions.
-Sean
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
