Public glance_store’s API refactor¶

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/glance_store/+spec/public-api-refactor

glance_store 库在几个周期前从 Glance 中分离出来。在此过程中，代码没有进行任何更改，并且对代码的重构被推迟到后续周期，因为主要目标是尽快拥有一个可用的库。

上述情况迫使 Glance 团队发布了一个从未打算公开的 API 的库，因此不建议在其他项目中使用该库。

问题描述¶

glance_store 公共 API 基于具有不一致签名的函数，这些函数根据传递的参数可能行为相同也可能不同。

当库是 Glance 的一部分时，这些函数运行良好，但现在不再如此。仅举几个例子

有多种方法可以存储数据：add_to_backend 和 store_add_to_backend
每个存储都需要实现一个 StoreLocation 类
可以从 scheme (get_store_from_scheme)、URI (get_store_from_uri) 或嗯，从位置 (耸肩) (get_store_from_location) 获取存储类

上述问题可能看起来并不严重，但它们确实会给使用该库的开发者带来不好的体验。

提议的变更¶

该提案是对此 API 进行重构，并提供更一致、向后兼容和干净的 API。提议的更改是创建一个能够执行当前函数集操作的单一类，并遵循当前 API 中的一些原则

它必须是无状态的
它必须能够存储、读取和删除存储中的数据。

作为此更改的一部分，一些函数将被完全弃用

verify_default_store 用户不需要此函数，并且从一开始就不应该将其公开。
get_store_from_(scheme|uri|location) 用户不应该需要访问存储驱动程序。这些函数从一开始就不应该公开。

现有函数将被标记为已弃用，并将重构为使用新的类。这将有助于我们测试新实现的行为，并验证我们不会破坏向后兼容性。例如，像 get_from_backend 这样的函数将使用新的类，但在此版本的测试期间，此函数的测试不会更改。

重要的是要注意，此规范不建议更改任何驱动程序的代码。它将专注于公共 API。glance_store 未来的增强将负责内部 API，例如驱动程序。

备选方案¶

一次性重写整个库。我们已经尝试过这样做，但从未通过规范阶段。
什么都不做。这将使我们拥有一个库，该库暴露了不必要的功能，并为用户提供了糟糕的体验。

安全影响¶

N/A…我的意思是，除了通常的情况（“别搞砸了”）之外，我不知道还有什么。

其他部署者影响¶

N/A

开发人员影响¶

这将使开发者更快乐/更满意。

实现¶

负责人¶

主要负责人: Flavio Percoco (flaper87)
其他贡献者: 有人吗？拜托？

评审人员¶

核心评审人: 有人吗？拜托？

其他审核员

工作项¶

编写新的类和测试
重写现有的函数
将 Q 版本中要删除的函数标记为已弃用

依赖项¶

N/A

测试¶

现有测试不会更改。将编写新的测试，我们将依赖 Glance 的 gate 来确保向后兼容性，直到我们在 glance_store 中改进我们的 gate 机制。

文档影响¶

将为这个新类编写文档

参考资料¶

N/A

Public glance_store’s API refactor