Check the strategy requirements

Problem description

Running of strategy requires different type of data resources to compute a solution. First launch of specified strategy causes an error in most cases. Admin has to take a look at logs to get more information about error. It takes a lot of time and is not informative way.

Use Cases

As an OpenStack administrator, I want to be able to check strategy requirements before strategy’s launching.

As an OpenStack administrator, I want to be able to see list of strategy’s requirements along with thier states. This list should get me a conclusion if I can execute selected strategy.

Proposed change

There are some requirements which are to be accomplished:

  • Metering service should be reachable. (mandatory)

  • One or more metrics associated with strategy should be presented in metering service. (optional)

  • Cluster Data Model used by the strategy should be loaded. (mandatory)

Checking of strategy can be called by using command ‘watcher strategy state {name_of_strategy}’. It will show the following table:

Requirement type




Metering Service


Gnocchi: available



cpu_util: available
memory.used: not available

cpu_util is out of bounds (144.2 > 100)

Cluster Data Model


Compute: available

Metering service can be verified by calling one of API resources (response should return HTTP status code 200):

  • GET /v1/status for Gnocchi

  • GET /v2/resources for Ceilometer API

  • GET /v2.0/metrics for Monasca API

API versions are set via conf/{metering_serice}

Metering service for each strategy is defined in watcher.conf file. If chosen metering service isn’t available, state of metering service should be tagged as ‘not available’. Otherwise, state would be ‘available’.

Watcher should know which metrics are used by requested strategy. This can be reached by using METRIC_NAMES dictionary. This dict contains datasources as keys and their subdicts of strategy_metric_name:datasource_metric_name pairs. This form of used strategy metrics is already used by basic_consolidation, outlet_temp_control, uniform airflow, vm_workload_consolidation strategies. Other strategies should be adapted to use METRIC_NAMES. I would also propose to set min and max bounds for metrics to be sure that requested metric will come in the form of expected unit (i.e. 0.00-100.00 for cpu_util).

Availability of metrics can be verified by sending appropriate requests to the metering service. For example, gnocchi will return list of metrics in response to GET /v1/metric request. It isn’t required to have all strategy metrics in metering service cause some strategies allows to work with some metrics, not all.

Cluster Data Model will be loaded in _collectors struct of CollectorManager class if appropriate collector is defined in collector_plugins option. By default, there is only compute CDM.



Data model impact


REST API impact

GET /v1/strategies/(strategy)/state


  • strategy (unicode) - UUID or name of the strategy.

Return: List of strategy’s requirements and their states.

Security impact


Notifications impact


Other end user impact


Performance Impact


Other deployer impact


Developer impact




Primary assignee:

alexchadin <>

Work Items

There are the following steps to be done:

  • Add new command to strategy API that will check out requirements.

  • Adapt existing strategies to use METRIC_NAMES dictionary.

  • Update python-watcherclient to support new command.




New unit tests should be added along with updating old ones.

Documentation Impact

Related documentation should be added.