5.7 KiB
Check the strategy requirements
https://blueprints.launchpad.net/watcher/+spec/check-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 | Mandatory | State | Comment |
|---|---|---|---|
| Metering Service |
|
Gnocchi: available | |
| Metrics |
|
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}_client.py
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.
Alternatives
None.
Data model impact
None.
REST API impact
GET /v1/strategies/(strategy)/state
Parameters:
- strategy (unicode) - UUID or name of the strategy.
Return: List of strategy's requirements and their states.
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:
-
alexchadin <a.chadin@servionica.ru>
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.
Dependencies
None.
Testing
New unit tests should be added along with updating old ones.
Documentation Impact
Related documentation should be added.