Open Stack

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).

-Josh