Open Stack

Andrew Laski wrote:
>
> 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?
>

I don't understand the puppet/chef connection, can u clarify.

If I'm interpreting it right, I would assume it's the same reason that 
something like 'skydns' exists over etcd; to provide a useful API that 
focuses on the dns particulars that etcd will of course not have any 
idea about. So I guess the keystone API could(?)/would(?) then focus on 
policy particulars as its value-add.

Maybe now I understand what u mean by puppet/chef, in that you are 
asking why isn't skydns (for example) just letting/invoking 
puppet/chef/ansible to distribute/send-out dns (dnsmasq) files? Is that 
your equivalent question?

-Josh