Queens 项目优先级¶
Watcher 驱动程序团队在 Queens 中优先处理的优先级列表。
优先级 |
负责人 |
|---|---|
Watcher 中的裸机数据模型¶
对于拥有大量虚拟机和物理主机的数据中心，总功耗巨大。当工作负载不重时，Watcher 可以通过触发关闭一些空闲主机的请求来减少功耗，而当工作负载增加时，Watcher 将触发“开启”请求以满足服务需求。
检查策略需求¶
操作计划取消的通知¶
Watcher Planner 选择器¶
该组件负责根据几个因素（例如策略使用的操作列表或用户请求）为给定的策略选择合适的 规划器。
Watcher Strategy 选择器¶
对于给定的优化 目标，可能有多个策略适用。目前，如果管理员没有指定策略，Watcher 会选择列表中第一个可用的策略。如果打算在实际基础设施中使用 Watcher，它需要一种更强大的方法来为给定的目标选择策略。策略选择器组件将使 Watcher 能够自动决定使用哪个策略。
工作负载特征和 QoS¶
基于定义的 workload 特性，我们应该能够为应用程序应用服务质量 (QoS)。例如，可以利用 Intel RDT 等技术。
这为几种应用程序优化可能性（例如 NFV 等用例）打开了机会，并确保了云资源的有效利用。此蓝图的范围是使用 Intel RDT 和 workload 语法构建 QoS 策略。
扩展节点状态¶
我们可以通过 Watcher 中的 CDM（集群数据模型）获取节点状态。大多数策略依赖于节点的状态。但现有的状态仅满足现有策略。我们需要扩展节点状态描述以支持新的策略。
通过审计范围排除项目¶
目前，Watcher 可以通过审计范围排除实例、compute_nodes、host_aggregates 和 instance_metadata。作为管理员，我希望从 Watcher 优化中排除特定项目的实例。此 bp 建议将排除项目功能添加到审计范围。
存储数据模型的审计范围¶
由于存储数据模型是在 Pike 周期中添加的，我们需要存储数据模型的审计范围，就像 compute 数据模型一样。
为每个 CDM 定义定制的范围¶
存储集群数据模型是在 Pike 周期中引入的。由于该模型与 compute 数据模型不同，当前的单个 CDM 范围不适用于该模型。
在代码中注册和记录策略¶
此蓝图跟踪将默认策略和文档移动到代码中的工作。这是 Queens 版本 OpenStack 范围内的目标。https://governance.openstack.org/tc/goals/queens/policy-in-code.html
存储 workload 平衡¶
目前，Watcher 仅优化 compute 节点。存储优化也是集中式存储（非分布式存储）的重要功能。此规范将添加存储 Workload 平衡策略以平衡存储资源。我们可以使用现有的目标（workload_balancing）和操作（volume_migrate）来进行存储 workload 平衡。
工作负载特征语法¶
当我们运行多个 workload 在云中时，我们应该能够将这些 workload 作为输入到 Watcher 中，以确保应用程序 QoS、放置和整合。
工作负载特征的一个例子是 CPU、内存或任何其他资源属性（如高 IOPS、网络延迟等）的加权组合。
此蓝图的范围是提出定义 workload 特征的语法结构。
区域迁移策略¶
云系统中运行着数千台物理服务器和存储，运行着各种 workload。管理员每季度左右需要迁移实例和块存储以进行硬件维护。这需要操作员手动观察 workload、选择要迁移的实例并为每个实例和块存储进行迁移，以实现高效且停机时间最小化。Watcher 可以自动执行此任务。
使用 JSON 验证 Watcher API¶
目前 Watcher 使用不同的方法来验证 api，这导致了许多错误，并且很少有操作是允许的，例如云管理员可以删除“正在进行中”的 actionplan 和 audit。为了对所有操作拥有更清晰和相同的方法，我们应该使用 JSON 拥有统一的 api 验证方法。
Compute CDM 包含所有实例¶
在构建 compute CDM 时，Watcher 会排除范围中排除的实例。这对 Watcher 产生负面影响。
对于某些策略，它会错误地获取 compute 节点的 workload，因为排除的实例未被计算在内。
对于服务器整合，它会禁用运行排除实例的节点。
显示策略的输入参数¶
目前在 Watcher 中，用户很难知道创建 audit 时每个策略需要哪些输入参数。此蓝图将在“watcher strategy list”的结果中添加一列以显示每个策略的输入参数。
为审计添加名称¶
为 audit 实体添加名称将对最终用户与 audit 交互更加友好。此蓝图建议向 audit 实体添加名称属性，以便用户可以通过名称轻松检索 audit。
集群维护策略¶
有时我们需要维护 compute 节点，更新硬件和软件，等等。但我们不希望用户的应用程序受到干扰。此问题导入了一个目标和一个策略，用于手动维护，而不会中断用户的应用程序。
策略的多数据源¶
我们需要一个抽象层，其中包含现有策略所需的最少指标子集（它将处理 gnocchi & monasca）。如果我们部署了多个指标收集后端，策略需要指定它想要使用的后端/或者我们可以在配置中定义后端优先级。我们需要一个策略中使用的指标名称与后端中相应名称之间的映射。
多个全局功效指标¶
目前全局 功效指标 是一个单一的实体。它对仅优化单个资源的策略很有用，例如服务器整合仅适用于实例。对于某些未来的优化多个资源（volume、instance、network）的策略，我们需要为每个资源计算全局功效。
用 JSON Schema 替换 voplutuous¶
在此蓝图中，我们将用 JSON Schema 替换 voplutuous 以验证功效指标。因为我们希望删除 voluptuous 并使用 JSONSchema 作为唯一的 JSON 验证工具，以保持 Watcher 中的一致性。
