独立角色仓库¶

日期:: 2015-08-17 14:00
标签:: 角色

为了提高在不同参考用例部署中独立使用 openstack-ansible 生成的角色能力，并允许不同项目独立开发每个角色，本规范建议

将新角色注册到名为 openstack/openstack-ansible-<role> 的独立仓库中。
现有角色可以通过独立的蓝图/规范流程拆分为自己的仓库。

https://blueprints.launchpad.net/openstack-ansible/+spec/independent-role-repositories

这提供了以下好处

其他项目（例如：DevStack、Kolla、Compass、RPC 等）将能够使用他们自己的 playbook 来使用这些角色。这增加了其他项目与 openstack-ansible 协作的机会。
这些角色将更容易在不同的参考架构中使用。目前，playbook 和角色专门针对在 LXC 容器中部署。使角色成为独立的实体将允许它们用于完全不同的架构。例如：没有容器的部署、使用虚拟机代替容器的部署、使用不同容器技术的部署。
每个角色可以按照自己的节奏开发并独立进行版本控制。这将使 openstack-ansible 更像 OpenStack “大帐篷”。
可以对每个角色进行独立门控检查，检查内容具体且与角色相关。这将提供更快的开发人员反馈，并加快开发周期。
可以将角色注册到 Ansible Galaxy。这将提高角色的知名度，并可能吸引更多贡献者。这对于基础设施角色尤其有用，因为它们的应用范围可能比仅用于 OpenStack 部署更广泛。（例如：haproxy、MariaDB 等）
角色分离将简化 openstack-ansible 的 playbook 和脚本的任务，使其用于提供如何使用角色的示例，以及为社区重要的用例实施门控测试的集成部署验证。这避免了 playbook 必须适应可能抛给它们的每种可能的组合用例的情况。

问题描述¶

问题详细描述

目前，openstack-ansible 的角色与使用它们的 playbook 紧密耦合。虽然从技术上讲可以使用不同的 playbook 来使用这些角色，但这对于下游用户来说并不明显。
当消费者尝试使用不同的 playbook 为不同的架构使用这些角色时，他们被迫为紧密耦合实施许多解决方法。即使有可能做到，由于需要设置的大量变量和需要阅读的代码，部署人员也很难看到如何做到。
有人对为其他服务（例如：rally、congress 等）创建角色表现出兴趣。实施每个角色一个仓库的策略可以使这些新兴角色更快地进入开放状态并进行协作。一旦它们达到可以集成到集成用例中并进行集成门控测试的阶段，它们就可以标记一个版本并实施 openstack-ansible playbook 和脚本来测试适当的用例。
作为项目的一部分实施的基础设施角色没有得到太多关注，因为它们更像是角色结构中的二等公民。这导致部署的配置通常不符合最佳实践。
对角色进行任何小的更改都需要执行完整的集成门控测试，这既缓慢又容易出错。在当前的单体堆栈中很难隔离错误。

提议的变更¶

应开发以下文档

项目测试的主要用例/实施。
如何申请添加新的用例进行集成测试。
如何在 openstack-ansible 的框架内注册新角色。
构建新角色的第一步。
更新每个角色的 README，以描述如何独立使用它，无论使用静态清单还是动态清单。它还应涵盖可用的选项、它是否依赖于任何其他角色、如何处理升级、任何已知问题等。

应遵循以下流程来注册新角色

必须注册一个蓝图，并提供一个规范来供实施审查，特别是要关注需要在当前的 openstack-ansible playbook 和角色中进行哪些更改才能集成新角色。
规范批准后，openstack-ansible PTL 或指定的 openstack-ansible-core 团队成员应将注册新仓库的审查提交到上游。
新仓库创建后，可以开始进行新角色的开发。
在为角色设置第一个标签之前，必须已经到位对角色进行全面的测试。

应遵循以下流程来拆分现有角色

对于每个目标拆分的角色，必须注册一个单独的蓝图，并提供一个规范来描述当前 openstack-ansible playbook 和角色需要进行哪些高级别的更改以适应此更改。
规范批准后，openstack-ansible PTL 或指定的 openstack-ansible-core 团队成员应将注册新仓库的审查提交到上游。
新仓库创建后，可以开始进行角色提取工作，如角色迁移规范中所计划的那样。
一旦角色仓库上的独立门控检查确认其工作正常，并且完成了准备角色用于集成用例的工作，则标记角色的初始版本并实施 openstack-ansible playbook、脚本和角色要求更改以使用新角色。在集成门控检查通过之前，openstack-ansible 中的更改不能合并。

备选方案¶

保持一切不变，继续将任何新角色合并到同一个单体仓库中。

Playbook/Role 影响¶

对 playbook 的影响应该是逐步的，但需要根据每个角色进行确定。这必须在每个角色的规范中描述。

很明显，库、过滤器和插件需要拆分为自己的仓库，并且每个使用它们的角色都需要在角色中使用子模块引用。这确保了所有角色使用一组通用的库、过滤器和插件。

升级影响¶

需要考虑升级影响的两个方面

角色本身处理来自自身先前迭代的升级的能力。
消耗角色的集成构建用例的可升级性。

每个角色都应考虑到可升级性，并符合正在为 Kilo -> Liberty 升级过程开发的升级框架。

安全影响¶

n/a

性能影响¶

n/a

最终用户影响¶

最终用户不会知道任何差异。

部署者影响¶

角色文件在部署主机上的结构和位置会有所不同。这些更改需要记录在案以供支持目的。但是，现有 playbook 的配置和执行应尽可能保持相同，以最大限度地减少中断。

任何角色特定的影响都需要根据每个角色单独定义。

开发人员影响¶

最大的负面开发影响是在两种不同结构之间工作时的困难——主分支被拆分，而 liberty 和 kilo 则被合并。在完成转换后，值得考虑使它们都以相同的方式工作。

正面影响已在简介中概述。

依赖项¶

这应该在 liberty 发布后才实施。

实现¶

负责人¶

主要负责人: https://launchpad.net/~jesse-pretorius odyssey4me https://launchpad.net/~kevin-carter cloudnull
其他贡献者: 待定

工作项¶

请参阅提议的更改部分。

测试¶

需要根据每个角色单独描述测试影响。

作为标准，预计为每个角色实施以下测试

所有 shell 脚本的 bashate 测试
所有 python 文件的 pep8 测试
所有 ansible 任务文件的 ansible 语法检查
所有 ansible 任务文件的 ansible-lint 测试
服务的单元测试

预计集成测试将在 openstack-ansible 仓库中实施，并在每次增加角色版本时执行。这确保了只有在通过完整的集成测试后，才能接受角色标签的增量发布。

文档影响¶

虽然角色文件在部署主机上的位置会有所不同，但部署的配置和执行应保持相同，从而最大限度地减少文档影响。

请参阅提议的更改部分，了解开发人员参考文档。

参考资料¶

n/a

独立的角色仓库