Bug 1042965 - [RFE][oslo]: Distributing Service Configuration Framework
Summary: [RFE][oslo]: Distributing Service Configuration Framework
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/oslo...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-13 16:48 UTC by RHOS Integration
Modified: 2015-03-19 16:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 16:48:56 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-13 16:48:44 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/oslo/+spec/distributed-config.

Description:

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

Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.