diff --git a/specs/train/approved/global-datasource-preference.rst b/specs/train/approved/global-datasource-preference.rst new file mode 100644 index 0000000..99841bb --- /dev/null +++ b/specs/train/approved/global-datasource-preference.rst @@ -0,0 +1,150 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +=================================== +Config global datasource preference +=================================== + +https://blueprints.launchpad.net/watcher/+spec/global-datasource-preference + + +Currently, datasources need to be configured on a per strategy basis. +Configuring the datasources per strategy is error prone and time consuming. By +being able to configure a global datasource preference the time to configure +Watcher is reduced and there is a single point for configuring the datasources +used by Watcher. + + +Problem description +=================== + +The datasources available to Watcher differs per OpenStack deployment so there +can not be a standard preference that will work for all deployments. Configuring +which datasources are preferred is essential to correctly deploying Watcher, +however, the datasource preference needs to be defined per strategy. As a result +the datasource preference will have to be configured many times which can lead +to errors and costs more time. + +Use Cases +---------- + +As a user of Watcher, I want to configure the datasources only once. + +As a user of Watcher, I want to configure the datasources only once but have +specific exceptions for some strategies. + + +Proposed change +=============== + +Allow specifying of global datasource order by exposing new configuration +parameter. This parameter will be part of a new group labeled watcher_datasource +. The datasource parameter for strategies remains available and overrides +the globally configured datasources. + +:: + + [watcher_datasource] + datasources = ceilometer, gnocchi, monasca + +Alternatives +------------ + +Try datasources but ensure that if they are not properly configured an error is +raised and an alternative datasource is tried. Major downside of this approach +is that it will create a lot of errors in some scenarios. + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +None + +Developer impact +---------------- + +None + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + + +Work Items +---------- + +* Add configuration parameter to specify an order of preferred datasources. + +* Read global datasource preference from config on selecting backend. + +* Allow specific strategy datasource configurations to preference. + +* On error attempt the next datasource. + + +Dependencies +============ + +None + +Testing +======= + +* Determine if global preference is used correctly. + +* Determine if strategies can override the global preference. + +Documentation Impact +==================== + +Documentation on configuration parameters will need to be updated to reflect +the new parameter. + + +References +========== + +https://review.openstack.org/#/c/645294/ + + +History +======= + +None