Open Stack

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