为状态管理添加一些细节

CloudKitty 正在变得越来越通用，在所有层面上都是如此。 随着项目的当前状态，范围可以是任何内容，甚至在多个收集器使用不同配置运行时也可能不同。 因此，应该向存储状态管理添加更多细节。

关联的故事板故事：https://storyboard.openstack.org/#!/story/2004957

问题描述

目前，CloudKitty 仅在其 SQL 数据库中存储检查/更新范围状态时的范围 ID。 鉴于范围 ID 在大多数情况下都是 UUID（例如项目 ID），这在理论上是防碰撞的。 然而，由于 CloudKitty 现在支持来自多个来源的数据收集，因此碰撞更有可能发生，尤其是在从不同来源收集关于相同资源的数据时。 此外，范围 ID 不需要是 UUID，即使将其视为最佳实践。

一个有问题的配置示例

  • 收集器 A 从 monasca 使用 keystone fetcher 收集数据，范围为 project_id。

  • 收集器 B 从 gnocchi 使用 keystone fetcher 收集数据，范围为 project_id。

目前，这具有不可预测的行为，因为两个收集器都会更新相同的范围。

提议的变更

为了改进对多个来源的支持并避免碰撞或意外行为，应该将检索范围 ID 的 fetcher 以及用于检索数据的收集器名称也存储在状态表中。 为了避免所有假设的碰撞，还应添加用于此特定范围 ID 的 scope_key。

因此，每个收集单元将由以下元组定义：(scope_id, scope_key, collector_name, fetcher_name)。

这将允许从不同来源或使用不同范围收集数据的收集器以一致的方式同步。

为了保持向后兼容性，状态管理器将具有以下行为：在检查范围 (A, B, C, D) 时，它将尝试检索范围 (A, B, C, D) 的状态。 如果未找到这样的范围，它将尝试检索范围 (A, None, None, None)。 如果找到该范围，其空列将使用值 B、C 和 D 进行更新。

备选方案

另一种选择是记录不推荐的配置。 然而，这将添加一些约束和边缘情况，这些情况可以使用当前的提议来支持。

数据模型影响

将向 cloudkitty_storage_states 数据库添加三个可为空的列，以及 identifier 列

  • scope_key

  • collector

  • fetcher

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无，迁移将由 cloudkitty-dbsync upgrade 命令处理。

开发人员影响

无

实现

负责人

主要负责人

lukapeschke/peschk_l

工作项

  • 向状态管理表添加额外信息，并更新状态检查逻辑。

依赖项

无

测试

鉴于这只是一个算法上的改变（没有新的功能/API 改变/行为影响），单元测试就足够了。 不需要 tempest 集成测试。

文档影响

关于如何存储范围的状态的一些细节将被添加到文档中。

参考资料

这在 2019 年 2 月 1 日的 CloudKitty IRC 会议上讨论过。 该会议的日志可在 http://eavesdrop.openstack.org/meetings/cloudkitty/2019/cloudkitty.2019-02-01-15.00.log.html 上找到（“将收集器 + fetcher 添加到状态数据库”和“问答”主题，从 15:42:26 开始）。