Ceilometer/blueprints/Configuration-via-data-store

Synopsis

Ceilometer uses a number of static configuration settings to define run-time parameters such as collection targets, exchange names, and pipeline intervals, among other settings. Currently, these configurations are stored in flat files and accessed by the Oslo configuration functions. While convenient for standalone deployments and development scenarios, the use of flat configuration files in a large-scale deployment can limit the flexibility of the system and prevents dynamic (i.e. on-the-fly) configuration updates that may be critical in large-scale implementations. Such environments typically have restrictive limits on code deployment (in terms of timing and user permissions) which often prevent or significantly delay changes to production. In addition, for Ceilometer to recognize changes in these settings it must be restarted; a difficult and unwanted task in production environments. By updating Ceilometer to monitor values recorded in a persistent data store such as MySQL, the application could be made to dynamically activate/deactivate collection targets or similar functions, have distinctly different configurations for multiple nodes in different environments (i.e. dev/test/prod or HA scenarios) and could ultimately be updated with new collection targets “on-the-fly”.

Example Use Cases

Collection Target Toggling & Tweaking

The configuration of Ceilometer pollster plugins occurs at start time [PHIL: Not sure if this is the only time, but I suspect it is]. The use of a data store allows us to update the settings for the collectors (interval settings, etc), as well as activate/deactivate collection of specific services, without having to do code releases.

HA Deployment

In a highly-available production environment, the failover of a server can be managed gracefully and without code changes by pre-designating configurations in the data store. By specifying both primary and backup system settings we can support an automated switch and, if needed, manually toggle between nodes.

Automated Configuration of New Collection targets

If Ceilometer is configured to periodically poll the database for collection targets, the addition of new ones can be accomplished with new data store records, rather than updates to configuration files. This permits a wider range of mechanisms for triggering changes and opens up the possibility of user-driven additions.

Approach

The initial approach to leveraging a data store for configuration involves wrapping or replacing the current configuration calls with code an optional call to a data store. It’s important to preserve the option for flat-file configuration so the more “lightweight” deployments may forego the additional overhead of creating another data store. In follow-on work, the frequency of configuration checks needs to be altered to ensure that changes are propagated into the collection-related threads that are spawned. This will require updates to the timing of configuration checks to be more frequent.