弃用 Glance Registry¶
Launchpad蓝图
https://blueprints.launchpad.net/glance/+spec/deprecate-registry
Glance registry 历史上一直通过允许集中数据库访问（glance-registry）同时分发数据访问（glance-api）来帮助扩展 Glance。此外，它还有助于保护数据库访问凭据，因为它不应作为公共端点部署。
随着 Glance V2 的发布和支持，Glance Registry 服务变得冗余，因此提出此弃用提案。
问题描述¶
Glance Registry 服务一个非常具体的用例，即作为 Glance 部署中数据库操作的代理。此用例是较旧的 Glance API 版本和更旧架构的一部分。
不幸的是，维护它（开发、运维和文档方面）变得越来越麻烦，对项目本身的益处越来越小。
从开发角度来看，团队必须为数据库 API 的每次更改更新 API。从运维角度来看，需要部署、监控和升级另一组 API 节点。从文档角度来看，团队需要确保服务文档是最新的，最佳实践已明确说明，并且配置文件已更新。
该服务的优点在最近的讨论中得到了讨论 [0]，涉及开发者和运维人员以及邮件列表。本次讨论的结果并不明确，但表明该服务不再有实际用例，并且运维人员如果没有它会更好。
滚动升级被认为是此弃用的一个潜在障碍。如线程中所解释的 [1]，升级 Glance（甚至计划中的滚动升级工作）不应依赖于此服务。从 Glance Registry 所需的任何内容都应该可以直接从 Glance API 获取。
Glance Glare 将不会使用 Glance registry，这也会导致部署不一致和糟糕的用户体验。
提议的变更¶
本规范建议弃用 glance-registry 服务。在 Q 版本中将该服务标记为已弃用并准备删除。
备选方案¶
继续维护 Glance Registry 服务。
数据模型影响¶
无
REST API 影响¶
公共 API 不会更改。registry API 将被弃用且不再需要。
安全影响¶
部署者必须将数据库凭据放入 glance-api 配置文件中。对于某些部署而言，这可能被视为安全问题，因为这意味着获得 glance-api 服务器访问权限的攻击者可能会潜在地访问 Glance 的数据库。但是，这与其它服务没有区别。
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
此更改实际上应该提高整体性能，因为它消除了 glance-api 访问图像元数据需要经过的额外步骤。
其他部署者影响¶
Glance 部署最终必须停止使用 registry。这不能用于使用 v1 的 glance-api 节点，但肯定可以用于仅使用 v2 的节点。
开发人员影响¶
更少的代码需要维护，开发者更开心。
实现¶
负责人¶
- 主要负责人
flaper87
- 其他贡献者
<launchpad-id 或 None>
评审人员¶
- 核心评审人
rosmaita jokke nikhil
- 其他审核员
<launchpad-id 或 None> <launchpad-id 或 None>
工作项¶
添加一个仅限 glance-api 的任务
将 registry 服务标记为已弃用
依赖项¶
测试¶
在 OpenStack CI 中测试无 registry 的部署。
文档影响¶
记录弃用的动机以及从 Mitaka 到 Newton 及之后的推荐升级路径。
