Pike 项目优先级¶
Watcher 驱动程序团队在 Pike 中优先处理的优先级列表。
优先级 |
负责人 |
|---|---|
Cinder 模型集成¶
使用 Cinder 相关数据扩展 Watcher 集群数据模型。应该能够实现以下功能：在模型构建阶段集成存储信息
为了维护存储相关部分模型的一致性，需要消费所有必要的 Cinder 通知
通过一组清晰的方法，能够轻松地从策略中查询/检索存储信息
VM 元数据中的审计标签¶
当 Watcher 运行 审计 以实现 目标 时，应该有一种方法让应用程序/VM 所有者知道他们的 VM 正在接受审计，并被标记为 行动计划 执行。这些信息可以在 VM 元数据中以时间戳的形式存储，之后将执行行动计划。
在 Watcher 中支持 Gnocchi¶
目前，Watcher 使用 Telemetry 和 Monasca 从 集群 中收集指标。由于 Ceilometer v2 API 已弃用，因此需要支持 Gnocchi。
吵闹邻居策略¶
L3 缓存至关重要，并且限制了所有应用程序或 VM 在一个节点上共享的系统级资源。如果一个 VM 占用大部分 L3 缓存，则该节点上的其他 VM 可能会因 L3 缓存不足而饿死，从而导致性能下降。
此 BP 添加了一个新的 策略，用于检测然后迁移基于一些新的缓存/内存指标的此类缓存贪婪 VM。
工作负载特征语法¶
由于我们在云中运行多个工作负载，因此我们应该能够将这些工作负载作为输入提供给 Watcher，以确保应用程序 QoS、放置和整合。
工作负载特征的一个例子是 CPU、内存或任何其他资源属性（如高 IOPS、网络延迟等）的加权组合。
此蓝图的范围是提出一个用于定义工作负载特征的语法结构。
使行动计划失效¶
当创建并成功启动审计时，会生成一个状态为 RECOMMENDED 的新行动计划。如果集群数据模型逐渐发生变化，行动计划仍然保持 RECOMMENDED 状态。到目前为止，没有到期日期或事件可以使行动计划失效。
工作负载特征和 QoS¶
基于定义的 workload 特征，我们应该能够为应用程序应用服务质量。一个例子将是利用 Intel RDT 等技术。
这为几种应用程序优化可能性（例如 NFV 等用例）打开了大门，并确保了云资源的高效利用。此蓝图的范围是使用 Intel RDT 和 workload 语法构建 QoS 策略。
行动版本化通知¶
目前，没有任何服务（包括 Watcher）能够知道何时创建、修改或删除了一个行动。这阻止了任何形式的基于事件的反应，这对于第三方服务或插件可能很有用。
此蓝图应定义要实现的行动通知列表以及各自的有效载荷结构。
取消行动计划¶
目前管理员可以将行动计划状态更新为 CANCELLED，但 Watcher 没有采取任何行动来取消行动计划。它只是将行动计划状态更新为 CANCELLED。
应该能够通过 Watcher 取消 行动计划的执行。
动态行动描述¶
通过引入一种新的方式，让开发人员通过配置文件实现具有新的自定义行动的策略（blueprint watcher-add-actions-via-conf），我们不再能够获得计划的 行动 的字面描述，直到执行它（在 Watcher Applier 中）。当云管理员想要查看推荐行动计划的详细信息时，此字面描述非常重要。
Watcher 中的电源开启和关闭¶
Watcher 需要一个可以降低功耗的策略。
交通系统可以在许多虚拟机上运行。白天交通繁忙，因此交通系统会增加虚拟机的数量以满足其工作负载。但在夜间，交通工作负载明显减少，因此该交通系统会删除冗余虚拟机。我们称此功能为“弹性伸缩”。
电信运营商拥有自己的硬件设备，有时硬件的尺寸很大。因此，电信运营商希望使用云中心管理器软件根据“弹性伸缩”自动降低硬件的能耗。
挂起审计状态¶
目前 Watcher 必须删除审计并重新创建审计，如果管理员想要停止创建具有连续模式的审计的行动计划。
此蓝图添加了挂起审计状态，用于停止与具有连续模式的审计相关的行动计划的创建。
JSONschema 验证¶
目前在 Watcher 中，jsonschema 和 voluptuous 都用于验证 JSON 有效载荷。但是，voluptuous 的问题是它的结构不如 jsonschema 标准化，这意味着我们无法轻松地通过我们的 API 暴露验证模式。
服务版本化通知¶
目前，没有任何服务（包括 Watcher）能够知道何时创建、修改或删除了一个行动。这阻止了任何形式的基于事件的反应，这对于第三方服务或插件可能很有用。
此蓝图应定义要实现的 Service 通知列表以及各自的有效载荷结构。
行动计划取消通知¶
需要为新的 actionplan 取消操作添加 action 和 actionplan 的通知。
为 CONTINUOUS 审计使用 cron 语法¶
目前，我们使用秒为单位的周期来安排连续审计。这效果很好，但并没有真正提供操作员可能真正想要的灵活性。因此，我们还应该提供一种通过 cron 语法表达我们的调度需求的方式，这将为操作员提供细粒度的控制。
此更改意味着 API 的重构，因此应保证向后兼容性。在 Watcher 仪表板侧，我们还应该提供一个易于使用的表单来填写此 cron 字段。
我们还应该将 cron 语法和创建时间戳保存在 DB 中
基于事件驱动的优化¶
我们提出了一种基于事件驱动的优化审计控制。我们希望从可能触发审计的事件列表中进行选择
对预测的情况做出反应。
对关键情况和系统变化做出反应（例如：阈值）
已向集群添加新的计算节点
已从集群中删除计算节点
已创建新的虚拟机
