[openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy
ayoung at redhat.com
Fri Jun 5 15:43:44 UTC 2015
On 06/03/2015 01:43 PM, 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.
>> My slides are here:
>> My original blog post attempted to lay out the direction:
>> And the Overview spec is here:
>> This references multiple smaller specs:
>> A unified policy file:
> 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.
Right. What we really need is a set of common rules that the projects
all agree on as the start of project specific policy.
A unified policy file is not maintainable long term if there are going
to be a huge number of microversion changes.
We'll have strange dependencies where we need to get a change into the
unified file first, but then the code that goes
in to Nova gets modified enough so that the policy is no longer valid.
I still think the unified policy file process is essential to working
out the differences between the projects.
Perhaps a better starting point is a common policy header file, assumed
to be applied prior to the default policy from each of the projects?
> 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).
So...I think Microversions are the heart of what we need to address. It
took me a while, and too much for an email, to think through it, so I
wrote it up here:
So long as the unified policy file is turned back into a Nova managed
policy file, I think we meet your concerns.
More information about the OpenStack-dev