Distributing Service Configuration Framework
Currently OpenStack utilizes on-disk configuration files to control the operation of services on a node. What we are proposing is a method for removing the configuration from the physical nodes themselves and centralizing it in a service that can be queried by the nodes at service start (or while running) to make changes to the service. At service start we will require a bare minimum of configuration values (i.e. rabbit_host, rabbit_port, etc) that allows for the discovery of the configuration service and all service values can be pulled and consumed by the service.
This data can then be written to disk for long term storage or managed internally by the services themselves. The ultimate goal would be to see services consume these configuration changes on the fly requiring no restart of the services themselves.
As a first pass we would like to build two things. One is a service like conductor that would be used to query a database and generate a dict of configuration items based on a criteria (host, cluster, etc). The second component would be an agent that can derive the data and place it onto the disk as a config file.
Going forward we would like to integrate the agent into oslo so, with a minimal amount of information, the cluster can configure itself utilizing the distributed configuration system to automatically configure services at start time (and maybe even reconfigure them while running).
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
How would this be different from other similar systems built on zookeeper or other existing config synchronization tools? -- dhellmann
dhellmann - I feel that this can complement the existing configuration management solutions.
My primary goal is allow for easy query of existing run-time configurations, modification of existing configs without having to restart services, and the ability to create configurations that are inheritable based on various criteria that may include location, region, aggregate, or even the type of the underlying hardware. This can also provide a mechanism for nodes to query the configuration values of other nodes to make tasks like instance migration more reliable (i.e. right now we need to have the same nova instance dir on source and destination and without that certain image copy operations will fail on migrations)
etcd looks interesting http://