为存储范围添加“active”列，并添加用于管理它的 API¶
本文档提出对“范围状态”端点进行扩展。提案的目标是在存储范围表（cloudkitty_storage_states）中添加一个新的选项，名为“active”，并提供一个 API，使操作员能够管理它。
问题描述¶
在使用 Gnocchi 作为数据获取器时（因此，我们可以处理不仅仅是 OpenStack 资源），我们注意到 CloudKitty 仍然会处理在它们创建的系统中已经删除的资源。因此，它们在 Gnocchi 中不再有度量数据。这导致 CloudKitty 的处理速度变慢。
为了说明一些数据，在生产环境中，只有大约 330 个我们需要处理的资源，但在 CloudKitty 存储状态表中，我们可以看到大约 990 个（这个数字会随着时间的推移而增长），并且 CloudKitty 正在处理所有这些资源。
在 1 月 11 日的会议上（http://eavesdrop.openstack.org/meetings/cloudkitty/2021/cloudkitty.2021-01-11-14.00.html），我们讨论了也许我们可以自动完成这个操作。但是，当我审查我需要的代码更改时，这并不简单。例如，OpenStack 中的一个项目可能只有一个 VM，然后这个 VM 被删除，并且该项目将不再有度量数据。因此，我们会将其标记为非活动状态。然后，如果该项目将来收到 VM，它们将不会被计费。因此，我们需要引入一种方法来将资源从非活动状态更改为活动状态，这并不简单，并且因此，其他机制需要在某个时间点处理非活动资源，以检查它们是否仍然在 Gnocchi 中没有度量数据。
因此，我们想到了一个更简单的解决方案。
提议的变更¶
提案是在存储状态表（cloudkitty_storage_states）中添加两个新字段。一个名为“active”的布尔列，指示 CloudKitty 范围是否处于计费活动状态，另一个名为“scope_activation_toggle_date”（时间戳字段）将存储范围在活动/非活动状态之间移动的最新时间戳。
然后，在 CloudKitty 处理期间，我们将检查“active”列。如果资源未处于活动状态，我们可以忽略它在处理期间。
此外，我们建议提供一个 API，允许操作员设置“active”字段。“scope_activation_toggle_date”不会暴露给操作员进行更改。它将根据“active”字段的更改自动更新。
该提案将在“/v2/scope”端点添加一个新的 HTTP 方法。然后我们将使用“patch” HTTP 方法来允许操作员修补存储范围。API 需要 scope_id，然后，它会考虑操作员允许更改的一些字段，“active”字段是其中之一。
负责人¶
- 主要负责人
Rafael Weingärtner <rafael@apache.org>
工作项¶
实现建议的更改
更新文档和示例
在 CloudKitty 和 OpenStack python 客户端中实现更改
依赖项¶
无
