Open Stack

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 <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?
>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>