We plan to have keystone support CRUD operations for those policy files with the next API, but that API hasn't yet been nailed down. Regardless of where the policy.json file comes from, I'd recommend creating one for quantum under etc/policy.json (like nova does) that defines a set of actions, rules, and roles for quantum.
Additionally, the services are all expected to be doing enforcement of the policies locally - the idea being that quantum (or glance, nova, etc) should not need to make a (relatively heavy) HTTP API call back to Keystone to check each time to determine if a user is allowed to do "X" action. Given that the routes in quantum call directly to plugins in Quantum, wrapping the controllers methods sounds like a good plan. -joe On May 20, 2012, at 5:25 AM, Yong Sheng Gong wrote: > Hi Joseph, > I have got the quantum client ready. So Next step is to get the server > support for keystone. > For policy, Is there still a need for local server to define a policy.json > file? I think we have a plan to move all the policies into keystone server. > right? > > After comparing all other policy check way, I like the nova's one which uses > decorator. > > For now, Quantum server has no a API layer just like nova. In quantum > server, the routes's controllers will call quantum plugin to do job. I think > we have to apply the policy check on(decorator) or in(method call) > controllers' methods. This is the way glance is adopting.
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
