检查策略需求¶

https://blueprints.launchpad.net/watcher/+spec/check-strategy-requirements

问题描述¶

运行策略需要不同类型的数据资源来计算解决方案。指定策略的首次运行在大多数情况下都会导致错误。管理员必须查看日志以获取有关错误的更多信息。这需要花费大量时间，而且信息不够明确。

用例¶

作为一个 OpenStack 管理员，我希望能够在策略启动之前检查策略需求。

作为一个 OpenStack 管理员，我希望能够查看策略需求列表及其状态。此列表应该让我得出结论，我是否可以执行所选策略。

提议的变更¶

有一些需要完成的要求

计量服务应该可访问。（强制）
与策略关联的一个或多个指标应该存在于计量服务中。（可选）
策略使用的集群数据模型应该被加载。（强制）

可以使用命令 ‘watcher strategy state {name_of_strategy}’ 调用策略检查。它将显示以下表格

需求类型	强制	State	注释
计量服务	是	Gnocchi: 可用
指标	no	cpu_util: 可用 memory.used: 不可用	cpu_util 超出范围 (144.2 > 100)
集群数据模型	是	Compute: 可用

可以通过调用以下 API 资源来验证计量服务（响应应返回 HTTP 状态码 200）

GET /v1/status 用于 Gnocchi
GET /v2/resources 用于 Ceilometer API
GET /v2.0/metrics 用于 Monasca API

API 版本通过 conf/{metering_serice}_client.py 设置

每个策略的计量服务在 watcher.conf 文件中定义。如果所选计量服务不可用，计量服务状态应标记为“不可用”。否则，状态将为“可用”。

Watcher 应该知道请求的策略使用哪些指标。这可以通过使用 METRIC_NAMES 字典来实现。该字典包含数据源作为键，以及策略指标名称:数据源指标名称对的子字典。这种形式的已用策略指标已经被 basic_consolidation、outlet_temp_control、uniform airflow、vm_workload_consolidation 策略使用。其他策略应该调整为使用 METRIC_NAMES。我还建议为指标设置最小值和最大值，以确保请求的指标以预期的单位形式出现（例如，cpu_util 的 0.00-100.00）。

可以通过向计量服务发送适当的请求来验证指标的可用性。例如，gnocchi 将在响应 GET /v1/metric 请求时返回指标列表。并非需要计量服务中包含所有策略指标，因为某些策略允许使用一些指标，而不是全部。

集群数据模型将在 CollectorManager 类的 _collectors 结构中加载，如果 collector_plugins 选项中定义了适当的 collector。默认情况下，只有 compute CDM。

备选方案¶

无。

数据模型影响¶

无。

REST API 影响¶

GET /v1/strategies/(strategy)/state

参数

strategy (unicode) - 策略的 UUID 或名称。

返回：策略需求及其状态的列表。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

无。

性能影响¶

无。

其他部署者影响¶

无。

开发人员影响¶

无。

实现¶

负责人¶

主要负责人: alexchadin <a.chadin@servionica.ru>

工作项¶

需要完成以下步骤

向策略 API 添加一个新命令，该命令将检查需求。
调整现有策略以使用 METRIC_NAMES 字典。
更新 python-watcherclient 以支持新命令。

依赖项¶

无。

测试¶

应该添加新的单元测试，并更新旧的单元测试。

文档影响¶

应该添加相关的文档。

检查策略需求