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.
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.
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:
http://adam.younglogic.com/2015/06/dyn-policy-microversions/
So long as the unified policy file is turned back into a Nova managed
policy file, I think we meet your concerns.
-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
