On 03/16/2015 01:45 PM, Doug Hellmann wrote:
All of these are reasons we have so far resisted building a service to
deploy updates to oslo.config's input files, and rely on provisioning
tools to update them.
Have we consider using normal provisioning tools for pushing out
changes to policy files, and having the policy library look at the
timestamp of the file(s) to decide if it needs to re-read them
before evaluating a rule? Maybe we wouldn't always scan the file
system, but wait for some sort of signal that the scan needs to be
done.
I like this last idea. Thew trigger needs to be app specific, I think.
Doug
I think policy files are not config files. We've treated them as such
in the past as they are not dynamic, but I don't think I want to *have*
to do this:
1. Change policy in keystone (somehow)
2. Tell Puppet that there is a new file
3. Have puppet pick up the3 new file and sync it to the servers.
Although I would say that we should make it easy to support this workflow.
For one thing, it assumes that all of the comsuers are talking to the
same config management system, which is only true for a subset of the
services.
I see a case for doing this same kind of management for Many of the
files Keystone produces. Service catalog is the most obvious candidate.
If we could have a workflow for managing : PKI certs, Federatiomn
mappings and (Group only?) Role Assignments we could decentralize token
validation.
When doing the PKI tokens, we discussed this, and ended up with a t
"fetch first" policy toward the certs.
Puppet does not know how to get a token, so it can't call the keystone
token-protected APIs to fetch new data. What forms of authentication do
the config managment systems support? Is this an argument for tokenless
operations against Keystone?
__________________________________________________________________________
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
