贡献者指南¶
提交代码前¶
在开始编写代码之前，应该采取一系列步骤
是否有针对此问题的 bug 报告？你能追踪到是否有人遇到过相同的 bug 吗？
你确定目前没有人正在处理这个问题吗？是否有待审核的修复相同问题的补丁？
你是否检查过你的问题/功能请求是否已经在另一个分支中得到解决？
如果你愿意提交代码，请记住以下规则
评审流程¶
任何新代码在合并到我们的仓库之前都会被审查。
我们遵循 OpenStack 关于 代码审查 流程的指南。
请注意，如果补丁不符合 提交代码通用指南，社区可以拒绝任何补丁。
处理 bug 修复¶
任何 bug 修复都应在其提交消息中包含
Closes-Bug: #bugnumber
或者
Related-Bug: #bugnumber
其中 #bugnumber 指的是 Launchpad 上的一个 issue。
另请参阅 OpenStack 文档的 处理 bug 部分。
处理新功能¶
如果你想为角色贡献代码，以引入 OpenStack 或基础设施服务，或者改进现有角色，OpenStack-Ansible 项目欢迎你的贡献和协助维护。
以下是一些入门规则
所有大型功能添加/删除都应附带蓝图/规范。例如，向 neutron 添加额外的活动代理，开发新的服务角色等… 另请参阅 提交规范。
在创建蓝图/规范之前，可以在 launchpad 上提出一个相关的“Wishlist Bug”。该 issue 将被 triaged，并确定更改的大小以及更改是否需要蓝图/规范。功能和 bug 修复可能都需要创建蓝图/规范。此要求将由核心评审人员投票决定，并基于更改的大小和影响。
所有蓝图/规范都应经过核心评审人员的投票和批准，然后才能合并任何相关的代码。有关蓝图/规范的更多信息，请查看 OpenStack 文档关于 处理规范和蓝图 以及我们自己的 提交规范。
一旦蓝图工作完成，作者可以请求将蓝图工作回移植到稳定分支。每个回移植将根据回移植对任何现有部署的影响进行逐个评估。有关更多信息，请参阅 回移植 部分。
任何实现具有 Tempest 测试的可用 OpenStack 服务的服务，必须连同功能测试一起实现，作为功能开发的一部分，以确保对代码库的任何更改都不会破坏服务功能。
功能添加必须包含文档，其中引用了 OpenStack 文档，说明该功能是什么以及它是如何工作的。文档应描述如何在 OpenStack-Ansible 中实现它以及有哪些配置选项。另请参阅 文档和发布说明指南 部分。
开发新角色的示例流程¶
以下是编写角色的步骤
你可以通过检查我们的 specs 仓库 和 review.openstack.org 上的 未合并的 specs 来查看当前正在开发的角色。如果你找不到该角色的规范，请提出蓝图/规范。另请参阅 提交规范。
创建一个源代码仓库（例如在 Github 上）来开始你的角色工作。
生成 Ansible 角色的参考目录结构，这是文档 最佳实践 的必要子集。你可以使用 Ansible Galaxy 工具来执行此操作（例如
ansible-galaxy init）。你可能还需要包含诸如docs和examples和tests的目录来用于你的角色。立即生成 meta/main.yml。此文件对 Ansible 来说很重要，可以确保安装并可用你的依赖角色，并为其他人提供了解你的角色目的所需的信息。
为每个安装阶段开发任务文件，根据需要创建任何处理程序和模板。确保在影响服务运行方式的任何任务之后通知处理程序（例如配置文件修改）。还要注意文件所有权和权限是否合适。
提示
填写变量默认值、库和先决条件，当你发现需要它们时。你也可以同时为你的角色开发文档。
为角色添加测试。另请参阅我们的 测试 页面。
确保角色符合 OpenStack-Ansible 的最新标准。另请参阅我们的 代码规则 页面。
确保角色收敛
实现 developer_mode 以从 git 源代码构建到 Python 虚拟环境。
将适用的配置文件部署到正确的位置。
确保服务启动。
收敛可能涉及使用其他 OpenStack-Ansible 角色（例如：galera_server, galera_client, rabbitmq_server），以确保适当的基础设施到位。强烈建议重用 OpenStack-Ansible 或 Ansible Galaxy 中的现有角色。
一旦初始收敛工作完成并且服务正在运行，角色开发应侧重于实现某种程度的功能测试。另请参阅 使用 tempest 改进测试。
使用我们提供的脚本在新机器上测试角色。
提交你的角色进行审查。
如果需要，请要求 OpenStack-Ansible PTL 将 github 角色导入 openstack-ansible 命名空间（这只能在开发周期的早期完成，并且可能会推迟到下一个周期）。
如果需要，在 openstack-ansible 集成仓库中进行集成工作，并在 AIO 上部署角色。另请参阅 使用 AIO 测试新角色。
向现有角色添加功能的示例流程¶
在 OpenStack-Ansible Launchpad 项目 中搜索该功能请求。
如果在 Launchpad 中不存在针对你的功能的“Wishlist”项目，请创建一个 bug。不要犹豫，在 bug 中询问是否需要规范。
Bug triage 将确定此新功能是否需要规范。
按照我们的 代码规则 工作于角色文件。
添加额外的角色测试场景，以确保你的代码路径经过测试并正常工作。
使用新机器测试你的新场景。另请参阅 本地运行测试 页面。
提交你的代码进行审查，并附带必要的文档和发布说明。
孵化新的“ops”项目的示例流程¶
可以在任何时候启动“openstack-ansible-ops”中的新项目，而无需编写规范或创建 bug 等约束。
相反，新代码必须隔离在 openstack-ansible-ops 仓库 的单独文件夹中。
回移植¶
回移植被定义为将更改从另一个分支复制的行为。干净/压缩/修改的 cherry-pick 和完整的重新实现是可以的。
回移植通常是通过使用相同的代码（通过 cherry-pick）来完成的，但这并不总是如此。当 cherry-pick 提供针对目标问题的完整解决方案时，此方法是首选的。
当将提交从一个分支 cherry-pick 到另一个分支时，提交消息应使用任何可能在执行 cherry-pick 操作时发生冲突的文件进行修改。此外，cherry-pick 提交消息应在新的提交消息的底部包含原始提交 SHA。可以使用
cherry-pick -x来完成。有关更多信息，请参阅 提交更改到分支进行审查。每个回移植提交仍然只能解决一个问题，如 提交代码通用指南 中的指南所述。
如果回移植是 cherry-pick 提交的压缩集合，则应在提交消息中引用原始 SHA，并清楚说明压缩提交的原因。
如果 cherry-pick 以任何方式被修改，则必须在提交消息中明确说明所做的更改以及原因。
重构工作不能回移植到“已发布”分支。
回移植审查应充分考虑补丁对 OpenStack-Ansible 部署的任何现有环境的影响。通用的 OpenStack 稳定分支指南 可用作参考。
