<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 10:10 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
1.  How long should a service hold on to the cached version of the policy file?<br>
2.  How can we avoid the stampeding herd if Keystone pushes out a notification change event?<br></blockquote><div><br></div><div>Why do you think this will present a problem?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3.  How do we securely cache the file and still make it possible to debug.<br></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
<br>
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. </blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'm guessing that access to policy rules are typically controlled by auth token validated services.  Is this correct?<br></blockquote><div><br></div><div>Can you clarify this question/concern?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
<br>
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?<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>