Hi Adam prior art is the publish-subscribe mechanism. I dont know if Keystone already has this implemented or not, or if Python implementation exists or not, without doing some research
regards David On 16/03/2015 18:08, Sumit Naiksatam wrote: > On Mon, Mar 16, 2015 at 8:10 AM, Adam Young <ayo...@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? >> 3. How do we securely cache the file and still make it possible to debug. >> >> 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? >> >> 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? >> > > Thanks Adam for bringing this up. As regards the group-based-policy > (GBP) project, we leverage the access control policy just like other > projects do, so the questions you raise above are definitely relevant > to GBP. We do not manage the lifecycle of this aspect of policy, so we > hope to use whatever comes out of this discussion. > >> __________________________________________________________________________ >> 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 > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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