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
__________________________________________________________________________
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
