拆分分配，使角色分配部分可插拔¶
通过拆分（并使其可插拔）与实际分配相关的部分来修改分配组件，以便提供替代的分配解决方案。
问题描述¶
分配控制器和后端实际上是一种误称——它们实际上是“身份的其余部分”，在拆分实际身份部分（即用户和组）后留下的。在这个“分配”组件中，我们存储域、项目、角色……以及实际的分配关系。域、项目和角色是 OpenStack 中用于策略控制 API 的通用语言。这些实体之间的实际分配关系（存储在 Keystone 中）不会在 Keystone 之外共享——而是这些分配用于确定将哪些角色包含在给定用户在给定目标实体（即项目或域）范围内的令牌中。因此，实际上我们今天所说的 Keystone 的“分配”组件包括
定义域、项目和角色的存储和 API。
定义分配关系的存储和 API。
一组评估分配的 API，以便将正确的角色集放置在作用域令牌中。
将以上所有内容组合在一个组件中会导致许多问题。
首先，该组件过于复杂。最近发现该领域的新缺陷数量表明了这一点。此外，我们希望在此领域进行重大更改：例如，分层项目以及为了提高性能而重构 list_role_assignents() 方法。这些更改只会使情况变得更糟。
其次，对于希望提供替代类型分配（例如 ABAC、增强的关系模型等）的开发人员和云提供商来说，他们真正需要提供的只是他们自己的版本 2（以上）并遵守 3 的 API。但是，由于“分配”后端包含以上所有三项，因此提供实际的分配部分并不简单。以这种方式启用替代访问控制模型的好处是 OpenStack 的其余部分将继续工作——即，无需更改其他项目的令牌格式或策略文件。整个 OpenStack 社区将受益于我们让 Keystone 成为一个平台，通过该平台可以将新的访问控制形式引入其中，最终由市场决定哪些形式最符合客户需求。
提议的变更¶
此更改会将当前的“分配”控制器和后端拆分为两个
资源——包含域、项目和角色
分配——包含当前的分配模型
此更改将简化对 OpenStack 其余部分所依赖的核心实体的支持，同时更容易标准化各种（略有不同的）用于列出分配关系的 manager/driver 方法，例如：
list_role_assignments
list_grants
get_roles_for_groups
get_roles_for_user_and_domain
list_projects_for_user
list_domains_for_groups
当考虑继承时，这一点尤其重要——各种驱动程序调用处理分配继承的方式普遍缺乏一致性，这目前导致了许多缺陷。
此更改的另一个副作用是部署者可以选择不同的后端技术（例如，LDAP 与 SQL）来处理资源实体和分配，这些技术更适合各自实体的规模和更新配置。
进行此拆分本身不会产生任何功能上的变化，但将能够更可靠地支持当前的功能，同时为正在进行中的更改提供更好的基础，例如分层多租户和角色分配性能改进。它还提供了一个平台，可以试验新的分配模型，同时确保其分配表达式仍然可以被 OpenStack 的其余部分使用。
备选方案¶
无
数据模型影响¶
除了将数据模型拆分为两个后端之外，唯一的更改是分配将不再使用外键来跟踪角色 ID。虽然这确实会降低引用完整性，但考虑到我们已经删除了用户、组、域和项目对象的外键，因此这被认为是一个低风险的更改。
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
对于返回项目、域或角色的引用，此更改可能会对列表分配 API 调用产生轻微的性能影响，因为我们不再能够一次性执行分配 ID 的提取及其后续转换为引用的操作。通过在新的基本实体驱动程序中支持从 ID 列表批量加载引用，可以减轻此影响。有关详细信息，请参阅参考部分中显示如何执行此操作的早期 WIP 代码。
其他部署者影响¶
部署者可以单独设置资源和分配的后端，尽管默认情况下它们将相同（以保持现有的配置设置）。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
henry-nash
工作项¶
拆分控制器和后端
将测试用例拆分为相关文件
提供一个示例替代控制器和后端
记录如何提供新的分配控制器和后端
依赖项¶
无
测试¶
无
文档影响¶
对 configuration.rst 和 developing.rst 的更改
参考资料¶
可以在这里找到实现此 bp 的第一阶段的早期 WIP：https://review.openstack.org/#/c/130954/
