允许获取/重置 scope 的状态¶
https://storyboard.openstack.org/#!/story/2005395
问题描述¶
目前 CloudKitty 的状态是，如果管理员出于任何原因想要重置给定 scope 的计算（例如，cloudkitty 的收集配置发生变化，或者更新了一些评级规则），他必须停止所有处理器，更新数据库中该 scope 的状态，然后重新启动所有处理器。此外，管理员无法获取 scope 的当前状态，除非直接查询 SQL 数据库。
提议的变更¶
警告
本规范仅涵盖全局模式。如果被接受，将会提出三个相关的规范，详细说明解决方案的每个部分。
为了解决这个问题，提出了以下三个变更
在 v2 存储接口中添加一个
delete方法，允许删除特定时间戳之后一个或多个 scope 的所有数据帧。这将是另一份规范的主题。添加一个 v2 API 端点，允许重置一个或多个 scope 的状态。这将是另一份规范的主题。
添加一个 v2 API 端点，允许检索一个或多个 scope 的状态。该端点将取代 v1 的
/report/tenants。这将是另一份规范的主题。
建议的逻辑如下
管理员通过 API 设置 scope 的状态。他可以定期检查先前更新的 scope 的状态是否已通过 scope 状态端点更新。
API 端点发送一个 AMQP 通知，指示应该将一个或多个 scope 重置为给定的状态。一旦 API 收到 AMQP 响应，将返回 202 Accepted 或 400 Bad Request 状态码（假定在到达此阶段之前已经处理了导致 401 或 403 错误的身份验证相关问题）。
收到通知后，相关的 AMQP 监听器将执行以下步骤
解析并验证通知。将指示其是否有效的 AMQP 响应返回给 API。如果通知无效，监听器在此停止。
对于每个 scope，将应用以下步骤
为了防止在重置其状态和删除其数据时处理 scope，监听器会获取一个 tooz 锁。此操作是阻塞的。
一旦获取锁，存储后端中给定状态之后的所有数据将被删除。
数据删除后，scope 的状态将被设置为给定的状态。
完成此操作后，将释放锁。
备选方案¶
这可以在没有 AMQP 通知的情况下完成。但是，这将意味着从 API 执行锁定和数据更新/删除，这会导致请求超时。
数据模型影响¶
无。
REST API 影响¶
REST API 的影响将在与上述 API 端点相关的规范中详细说明。
安全影响¶
这将允许管理员通过 API 删除用户数据。必须谨慎使用此功能。
通知影响¶
这将为处理器添加一个通知和一个新的 AMQP 监听器。确切的更改将在相关的规范中描述。
其他最终用户影响¶
无。
性能影响¶
根据与 scope 关联的数据量，删除可能需要相当长的时间并影响数据库的性能。
此外，在数据删除期间将锁定要重置的 scope，因此处理器将无法处理它。
其他部署者影响¶
这将帮助管理员，因为重置 scope 不再需要直接操作数据库。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
peschk_l
- 其他贡献者
jferrieu
工作项¶
编写一份规范，以添加一个
delete方法到 v2 存储接口，允许删除特定时间戳之后一个或多个 scope 的所有数据帧。编写一份规范，以添加一个 v2 API 端点，允许重置一个或多个 scope 的状态。
编写一份规范，以添加一个 v2 API 端点，允许检索一个或多个 scope 的状态。该端点将取代 v1 的
/report/tenants。
依赖项¶
无。
测试¶
测试将在每个相关规范中详细说明。
文档影响¶
将更新 API 参考。
将添加一些文档和示例，说明如何重置 scope 的状态。
参考资料¶
无
