On 06/03/2015 08:46 PM, Hu, David J (Converged Cloud) wrote:
I am not a big fan of putting admins through a multi-step process. It looks
like admins will need to learn unified policy file first, then 1 or 2 or more
releases later, learn about policy in the db. I understand we are doing things
incrementally. I would prefer that we come up with something or some process
that voids the hassle of dealing with unified policy file for admins. In other
words, admins go straight from policy file as is today to policy in the db.
We need to get there our selves, and we need to go through these steps.
I would love it if we got everything proposed for dynamic policy out so
that, come Liberty release, we can train everyone equally but I don't
expect things to move that fast in OpenStack.
The unified policy file can be fed in to the DB policy management tool
to prime the setup, and we should expect that to be people's starting
point. But unless we get to where we all have a common understanding of
what policy should look like, we are going to be deconflicting the
different assumptions between projects anyway. We can and should
parallelize the efforts. The unified policy file will be the place where
we have the initial coordination for how policy will work across the
core OpenStack services.
David
-----Original Message-----
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Wednesday, June 3, 2015 4:39 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic
Policy
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
__________________________________________________________________________
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
__________________________________________________________________________
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
