[openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

Sean Dague sean at dague.net
Thu Jun 4 10:56:39 UTC 2015


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.

Right, 100% agreed. On something like this it's hugely important not
just to consider the incremental internals that people want to do, but
the incremental changes to long standing practices that cloud admins
have come to know over the years. Dragging ops through a weird and
temporary intermediary step that we know is going away is *terrible*,
and makes them all hate us.

Which is another reason why I think a single policy file is just a non
starter from an actual deploy perspective. It's not a way point from an
op perspective, it's a radical change, that will be radically changed
again in a release or two.

I think an audit tool that slurps up all the policy files from projects
and figures out inconsistencies, and fixes then proposed to the existing
projects, is fine. That preps the policies for dynamic merge at later
dates. Those proposed changes will also trigger deprecation approaches
in the projects. For instance, changing the nova policy from admin ->
compute:admin is not just a switch to be flipped. That's going to
require a deprecation cycle at least so that people can upgrade to
Liberty, admin definitions still do what they expect, but they get
WARNings about it.

Every step here requires "what's going to look different to an operator,
and what change might they need to make after that." and optimize for
that path being as small as possible.

	-Sean

> 
> 
> David
> 
> 
> -----Original Message-----
> From: Adam Young [mailto:ayoung at redhat.com] 
> Sent: Wednesday, June 3, 2015 4:39 PM
> To: openstack-dev at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list