On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote: > Andrew Laski wrote: > > However, I have asked twice now on the review what the benefit of doing > > this is and haven't received a response so I'll ask here. The proposal > > would add additional latency to nearly every API operation in a service > > and in return what do they get? Now that it's possible to register sane > > policy defaults within a project most operators do not even need to > > think about policy for projects that do that. And any policy changes > > that are necessary are easily handled by a config management system. > > > > I would expect to see a pretty significant benefit in exchange for > > moving policy control out of Nova, and so far it's not clear to me what > > that would be. > > One way to do this is to setup something like etc.d or zookeeper and > have policy files be placed into certain 'keys' in there by keystone, > then consuming projects would 'watch' those keys for being changed (and > get notified when they are changed); the project would then reload its > policy when the other service (keystone) write a new key/policy. > > https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change > > or > https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches > > or (pretty sure consul has something similar), > > This is pretty standard stuff folks :-/ and it's how afaik things like > https://github.com/skynetservices/skydns work (and more), and it would > avoid that 'additional latency' (unless the other service is adjusting > the policy key every millisecond, which seems sorta unreasonable).
Sure. Or have Keystone be a frontend for ansible/puppet/chef/.... What's not clear to me in any of this is what's the benefit to having Keystone as a fronted to policy configuration/changes, or be involved in any real way with authorization decisions? What issue is being solved by getting Keystone involved? > > -Josh > > __________________________________________________________________________ > 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
