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.
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).
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
