I haven't done a full review but I like what you did and this should be the proper way to handle ACL for keystoneauth. I am not sure tho that forking oslo.common.policy is any better than copy/pasting it with its dependences. I would suggest we move `swift-keystoneauth` to its own project part of the swift umbrella projects to handle such things and be able to include those policy module directly. I think we have enough swift core now that uses keystone everyday to sponsors the core review for that project. That mething i'd like to talk about with the folks at altanta even tho there is no session for it. Chmouel On Fri, Apr 25, 2014 at 11:25 AM, Nassim Babaci <nassim.babaci at cloudwatt.com > wrote: > Hi everyone > > I would like to point out the bp > https://blueprints.launchpad.net/swift/+spec/authorization-policy to may > be have some early feedback from the community. > I have submitted a first patch which I hope will serves as an example/base > for discussion. > > Specially I was wondering what would be the best way to integrate the > policy engine (or not) within swift. > For now I have roughly adapted the policy engine found here ( > https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py) > and I removed all the unnecessary dependencies to modules like oslo.config, > log, etc, and finally kept only the parts that deal with parsing and rule > checking, but any advice in this (or more globally) would be highly > appreciated. > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > 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/20140425/758a301b/attachment.html>