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.
> 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
> OpenStack Development Mailing List (not for usage questions)
OpenStack Development Mailing List (not for usage questions)