Open Stack

On Mon, Mar 16, 2015 at 10:10 AM, Adam Young <ayoung at redhat.com> wrote:

> Oslo policy has been released as a stand alone library.  This is great, in
> that the rules engine is relatively non-applicaition specific, and I assume
> that all of the policy based project are planning to migrate over to using
> the policy library instead of the incubated version.
>
> Part of the push toward a more dynamic policy mechanism is figuring out
> how to fetch and cache the policy files from Keystone.  I suspect that the
> other services have the same issue.
>
> 1.  How long should a service hold on to the cached version of the policy
> file?
> 2.  How can we avoid the stampeding herd if Keystone pushes out a
> notification change event?
>

Why do you think this will present a problem?


> 3.  How do we securely cache the file and still make it possible to debug.
>

Why would security for policy blobs need to differ from today's
implementation? (specifically referring to the side of the fence where
policy blobs are consumed -- which is the only side of the fence today)


>
> The PKI tokens have a lot of these same issues, and have a one-off
> mechanism for handling it.  We should probably look in to commonizing this
> function.
>
> There general mechanism should be "fetch and cache" but I think it should
> not be tied to keystone token validation so much as capable of using it if
> necessary.


I'm guessing that access to policy rules are typically controlled by auth
> token validated services.  Is this correct?
>

Can you clarify this question/concern?


>
> Maybe the right level of abstraction is a callback function for fetching
> the file to be cached, with the default being something that uses
> python-requests, and then an  auth plugin based alternative for those that
> require Keystone tokens.
>
> Before I go off and write a spec, I'd like to know what the prior art is
> here.  I'd also like to know if there oslo policy library is part of the
> plans for the other groups that are doing policy based work?
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150316/80e71e5c/attachment.html>