Fuel/如何贡献

加入 Fuel 团队

第一步

阅读 开发者指南 并了解如何设置帐户和 git。

克隆仓库

• git clone git://github.com/stackforge/fuel-main.git
• git clone git://github.com/stackforge/fuel-web.git
• git clone git://github.com/stackforge/fuel-astute.git
• git clone git://github.com/stackforge/fuel-ostf.git
• git clone git://github.com/stackforge/fuel-library.git
• git clone git://github.com/stackforge/fuel-docs.git

您可以 在 gerrit 中搜索与 Fuel 相关的所有审查，或者使用 Fuel 仪表板 获取一个优先排序的开放审查列表（此 URL 使用 Gerrit 仪表板生成器 生成，您需要登录 Gerrit 才能使用它）。

请注意，OpenStack Infra 对您的 git 提交消息有严格的检查。最重要的规则是

• 保持您的提交标题简短（小于 80 个字符）。它不能以句点结尾。
• 提交消息的正文应与标题之间用一个空行分隔
• 如果补丁关闭了错误，那么它必须在正文中包含“Closes-Bug: #12345”，其中 12345 是您的 LP 错误编号
• 如果补丁与错误相关，但没有完全解决问题，那么您必须使用“Related-Bug: #12345”

有关更多详细信息，请参阅 Git 提交消息 wiki 页面。

如何以及在哪里获取帮助

订阅邮件列表

• OpenStack 开发者邮件列表。如果您正在修改 Fuel，或者对 Fuel 内部有技术问题，欢迎使用带有“[Fuel]”主题的邮件列表。
• OpenStack 用户邮件列表。Fuel 流量带有“[Fuel]”主题。欢迎提问与 Fuel 使用相关的问题，包括错误等。
• OpenStack 公告邮件列表。关于 OpenStack 项目的公告，例如产品发布信息、安全建议、重要讨论。这是一个低流量的只读列表。
• 还有更多的邮件列表，请访问 MailingLists 查看其他 OpenStack 相关列表。

freenode.net 的 IRC

• 通用的 Fuel 频道称为 #fuel，并且已记录 此处。
• Fuel 开发频道称为 #fuel-dev，并且已记录 此处。
• Fuel 主要组件的开发频道：#fuel-library、#fuel-python、#fuel-ui、#fuel-qa、#fuel-infra。
• Gerrit 通知所有 Fuel 仓库：#fuel-tracker。

快速参考开发链接

• 开发环境 http://docs.mirantis.com/fuel-dev/develop/env.html
• 如何构建您的 Fuel ISO http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
• Nailgun 开发 http://docs.mirantis.com/fuel-dev/develop/nailgun.html
• Health Check (OSTF) 贡献者指南 http://docs.mirantis.com/fuel-dev/develop/ostf_contributors_guide.html
• 贡献 Fuel Library（Puppet 模块） http://docs.mirantis.com/fuel-dev/develop/module_structure.html
• Devops 框架 - Fuel 环境的分布式测试 http://docs.mirantis.com/fuel-dev/devops.html

贡献

Fuel 是一个编程、Linux 和网络交叉的大型项目。它使用 Python、Ruby 和 JavaScript 编写。它还具有许多用 bash 和 make 编写的构建脚本。文档使用 Sphinx 编写。欢迎新的贡献者。

Fuel 用于 Puppet 清单的库

在 fuel-library 中使用 Puppet 上游模块

如果您要添加新的上游模块的分支，请不要这样做。相反，请遵循上游模块的贡献规则，并将此模块作为 Fuel 的可插拔组件提供。这可以作为 可插拔架构 的一部分完成，并作为软件包分发。请注意，如果上游模块不符合您的要求，您应该首先适应上游模块的需求，或者在紧急情况下，提供自定义补丁集作为 Fuel 插件分发的一部分。

具有与 Apache 2.0 不兼容的许可证（GPL 等）的模块将不被接受。*请注意许可证信息。*

案例 A：添加新的上游模块

如果需要使用新的 Puppet 模块，则应通过 Puppetfile 添加该模块，如 Fuel/Library and Upstream Modules 页面中所述。您应该遵循 New Module 工作流程

案例 B：通过 Puppetfile 使用现有的上游模块

如果需要使用新的 Puppet 模块，则应通过 Puppetfile 添加该模块，如 Fuel/Library and Upstream Modules 页面中所述。您应该遵循 Updating Existing Module 或 Custom Upstream Module Changes 工作流程。理想情况下，所有上游更改都应首先在上游完成，并且可以使用简单的 Puppetfile 更新将其拉入 fuel-library。

案例 C：使用现有的上游模块

如果需要对尚未迁移到 librarian-puppet-simple 工作流程的现有上游模块进行更改，则应遵循的工作流程是

1. 创建一个包含来自您正在使用的任何点的未修改的上游模块副本的审查请求，并且没有其他相关的修改。

• 此审查还应在提交消息中包含上游仓库的提交哈希。
• 审查应评估其适用性并被拒绝（出于许可、代码质量、过时的版本请求）或被接受而无需修改。
• 审查不应包含调用此新模块的代码。

2. 然后，应提出任何必要的更改以使其与 Fuel 协同工作作为依赖更改。

贡献到现有的 fuel-library 模块

作为 Puppet 模块的开发者，我们倾向于与 Puppet OpenStack 社区合作。因此，我们将所有改进、修复和自定义贡献给上游模块，以改进 Fuel。这意味着每个贡献者都必须遵循 Puppet DSL 的基本知识、puppet-openstack 开发文档 和 Puppet rspec 测试要求。

最常见和普遍的规则是，只有当错误修复和改进可以使社区中的每个人受益时，才应修改上游模块。并且应在 Fuel 项目之前向上游项目提出适当的补丁。

在其他情况下（例如应用一些非常具体的自定义逻辑或设置），贡献者应提交补丁到 openstack::* 类

Fuel 库包含自定义模块以及从上游来源分叉的模块。请注意，如果存在 Modulefile（或 metadata.json），则应使用它来识别给定的模块是分叉的上游模块还是不是。如果模块的目录中没有 Modulefile，则贡献者可以直接提交补丁到 Fuel 库中的该模块。否则，他或她应首先将补丁提交到上游模块，并且一旦合并或从核心审查者处收到 +2，则应将补丁回移植到 Fuel 库。请注意，提交到 Fuel 库的补丁应在提交消息中包含上游提交 SHA 或指向 github 拉取请求的链接（如果模块不在 stackforge 上）或 gerrit 补丁的 Change-Id。

Fuel 开发环境

VirtualBox

开始使用 Fuel 的最快方法是在 VirtualBox 下设置环境。这是开始测试的好方法，例如使用 nightly 构建来尝试验证、确认或分类错误。可以在 https://software.mirantis.com/quick-start/ 找到快速启动脚本和说明。

Fuel ISO 构建和开发环境

设置一个环境来构建 Fuel ISO 将允许您轻松地针对特定的提交构建，以便进行更复杂的错误测试/确认/分类/修复工作，或者用新功能增强 Fuel。除了准备 ISO 构建的环境之外，准备其他 Fuel 组件（nailgun、astute 和文档构建）的环境的步骤也可以在那里找到。可以在 http://docs.mirantis.com/fuel-dev/develop/env.html 找到准备环境的说明。

Fuel DevOps 环境

将 Linux 机器设置为 Fuel DevOps 环境将允许您自动化构建/验证/测试过程，除了构建 ISO 和进行其他 Fuel 相关开发之外。使用 libvirt，devops 环境能够部署多个完整的 OpenStack 环境在虚拟机上。可以在 http://docs.mirantis.com/fuel-dev/devops.html 找到准备 devops 环境的说明。

文档

Fuel 中有两种类型的文档：开发者 和 用户。两种文档的源代码都可以在 fuel-docs 仓库 中找到。该仓库使用 reStructuredText 格式。文档被视为源代码，我们使用相同的 开发流程 来更新文档，就像我们更新 Fuel 代码一样。

编写文档

保持文档的更新是一项困难的任务，也是每个项目中的关键部分。Fuel 开发者使用 OpenStack DocImpact 流程来突出显示需要在文档中反映的代码更改。当一个补丁集应该被记录或需要文档更改时，审查者应该要求提交者在他们的提交消息中添加“DocImpact”标签，并确保提交消息提供关于代码更改的影响的足够信息。当一个带有 DocImpact 标签的提交被合并时，一个新的错误将被自动创建并分配给 Fuel 文档团队。技术作者然后与提交者合作，将提交反映在文档中。

由 DocImpact 提交生成的错误应分配给 fuel-docs 团队，直到技术作者接手。技术作者从原始提交作者那里收集信息，并将其添加到正确的文档区域。最初提供信息丰富的提交消息是提交作者的责任，以便回答技术作者的问题，并审查解决该 DocImpact 错误的文档提交。

更新和扩展当前文档

如果您发现文档有问题，请随时提交错误，并提供修复程序，通过相同的代码贡献策略和程序。

编写发布说明

新功能

对于 Launchpad 里里程碑页面上列出的每个蓝图（例如 https://launchpad.net/fuel/+milestone/5.1），请找到以下问题的答案

• 该变更对用户有什么可见的影响？
• 这之前是否作为已知问题记录在案？

如果这是一个用户可见的改进，请添加一个“新功能”条目来描述它。解释何时此功能重要，如何启用它，以及当前的期望和限制。

如果之前是已知问题，请添加一个“已解决问题”条目。

已知问题和已解决问题

扫描发布里程碑页面（例如 fuel 6.0）。审查所有针对当前里程碑的目标 bug，这些 bug 满足以下条件之一

• "release-notes" 标签
• 关键优先级
• 高优先级和“customer-found”标签。

按照编号从高到低对里程碑页面上的 bug 表进行排序，以便您可以查看您已经审查过的 bug。如果当前里程碑的 bug 状态为 Fix Committed 或 Fix Released，请将其视为“已解决问题”列表。找到以下问题的答案

• 这个问题是否存在于之前的 GA 版本中？（如果是，它将至少针对一个之前的发布系列进行目标设置，并将目标里程碑设置为该系列的维护版本。）
• 如何确认您的环境受到影响？（识别受 bug 影响的特定配置，包括错误消息或其他区分此 bug 的症状。）
• 如果受到影响，如何恢复？
• 根本原因是什么？为了解决问题，需要更改什么？

如果当前里程碑的 bug 状态为 Won't Fix 并且满足上述条件，请将其视为“已知问题”列表。需要回答的问题是

• 如何确认您的环境受到影响？
• 是否有解决方法？（如何防止此问题影响您？）
• 恢复流程是什么？

审查发布说明

发布说明的每个部分都有一个技术作者负责。作者会识别需要在其部分中反映的功能和 bug。对于每个功能和 bug，作者会找到负责的软件工程师：功能负责人或最近 bugfix 的提交者。

如果无法从 bug 描述、蓝图描述、规范和相关提交的提交消息中获得足够的信息（请参阅上面的问题列表），作者会私下联系工程师，请求更多信息。当功能或 bug 的描述在 gerrit 审查中发布时，作者会将工程师订阅到该审查中，并再次私下发送请求，其中包含指向 Gerrit 中文档审查的链接以及有关如何识别需要工程师审查的特定文档文件和行（例如，LP bug 号码、特定的 RST 文件、章节标题或标签等）的说明。

Fuel 工程师必须优先处理这些信息和审查请求，以便在正常的开发过程中在一周内做出响应，并在硬代码冻结和 GA 发布期间的一天内做出响应。当未及时收到信息请求或审查请求的响应时，将使用标准升级流程。技术作者负责跟踪其发布说明部分的信息和审查请求的状态和升级情况。

错误

验证 bug

这很容易上手，但这里的帮助实际上非常有价值。特别是对于仅与某些类型的硬件相关的 bugfix。当 bugfix 合并时，bug 会自动移动到“Fix Committed”状态。在 Fuel 中，只有当其他人验证了 bug 时，我们才会设置“Fix Released”状态，而不是开发者本人。您可以简单地查看 所有 fix committed bugs 并开始验证它们。您需要加入 fuel-bugs LP 组才能更改 bug 状态。但是，您可以在 bug 报告中留下评论，这足以让 bug 管理员更改 bug 状态。如果您要求，您可以被添加到 fuel-bugs 团队中以自行管理 bug。

测试和报告 bug

您可以始终按照 http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso 中的说明从 master 构建开发人员的 ISO。测试不同的部署模式，并提交 bug。请随时在 IRC 中分享您的发现，以获取您想了解的任何详细信息。您可以按照您想要的方式提交 bug，但是，如果 bug 包含所有详细信息，以便于重现并节省开发人员的时间，那就太好了。您可以遵循以下简单的指导，它略微扩展了官方 OpenStack Bugs 页面。

您报告的 Fuel bug 可以是“Public”或“Private”。Private bug 仅对 Dev、QA 和 Support 团队可见。指导如下

• 通常，您希望报告一个“Public”bug
• 但是，如果 bug 包含任何敏感信息或安全漏洞信息，请报告一个“Private”bug

在创建新 bug 之前，始终检查项目中是否已经存在类似的 bug，并更新现有 bug 而不是创建稍后将被丢弃为重复项的内容。但是，重要的是要确保两个 bug 确实相关，处理重复项比理清混合到一个 bug 中的几个不相关的调查线索更容易。不要重新打开标题通用的 bug，例如“Horizon 崩溃”或“HA 无法工作”，这些 bug 涵盖了整个范围的根本原因。也不要创建带有此类标题的新 bug：尽可能具体地说明问题的性质。

以下是如何提交 bug

• 转到 https://launchpad.net/fuel
• 在右侧选择“Report a bug”
• 填写 bug 的“Summary”字段。这将是标题。请简洁明了地描述它。
  • 不好 - "Sahara doesn’t install"
  • 好 - "Sahara fails to install in HA mode when “Neutron with VLANs” network is selected"
• 输入“Further information”。这是 bug 描述。它应该包含以下部分
  • 重现步骤
    • 不好：在 HA 配置中运行部署
    • 好
      1. 创建一个新的集群
      2. 选择 HA 模式，“Neutron with VLANs”用于网络，并选择安装 Sahara
      3. 将其余设置保留为默认值。运行集群安装
  • 预期结果
    • 好：Sahara 已部署，正在运行。
  • 实际结果
    • 不好：Sahara 安装失败。
    • 好：Sahara 安装失败，并显示错误消息“xxx”。请参阅附件中的屏幕截图，其中显示“Logs”选项卡上的错误。
  • 解决方法
    • 不好：不要使用“Neutron with VLANs”
    • 好：将网络模式切换到“Neutron with GRE”以完成部署。
  • 影响
    • 不好：需要修复。
    • 好：无法完成部署，因为客户要求我们实施 Sahara 和“Neutron with VLANs”的用例。将配置更改为“Neutron with GRE”不是一个可接受的选项，因此必须尽快解决此问题。
  • 环境描述。提供足够的相关信息
    • 输出 http://fuel-master-node:8000/api/version/
    • shotgun2 report 命令的输出
    • 操作系统
    • 参考架构（HA / 非 HA）
    • 网络模型（Nova-network、Neutron+VLAN、Neutron+GRE 等）
    • 安装的相关项目（Sahara、Murano、Ceilometer）
• 在“This bug contains information that is”字段下选择 bug 的可见性。要么将其保留为“Public”（默认值），要么根据上述指导将其设置为“Private”。
• 在“Extra Options”部分下添加附件
  • 日志
  • 诊断快照
  • 截图
• 在输入所有内容后，选择“Submit bug report”按钮

确认和分类 bug

Fuel 项目使用与 OpenStack 其他项目相同的 bug 管理实践。请遵循 Bugs 和 BugTriage 页面。

在 Fuel 部署过程中对 bug 进行分类

在对 Fuel 部署过程中的 bug 进行分类（与 Fuel 部署的 OpenStack 组件中的 bug 不同）时，请使用以下附加标准来确定 bug 的重要性

• Critical = 无法部署任何内容且没有简单的解决方法；数据丢失；或安全漏洞
• High = 某些硬件、配置或组件无法使用且没有解决方法；或者一切都已损坏，但有一个解决方法
• Medium = 某些硬件、配置或组件工作不正确；或者完全无法使用，但有一个解决方法
• Low = 次要功能已损坏，可以通过简单的解决方法修复；或者是一个外观缺陷
• Wishlist = 不是 bug，要么关闭为 Won't Fix，要么与蓝图关联（如果不存在涵盖 bug 中请求的功能的现有蓝图，则创建新的蓝图）

Fuel 还对两个 bug 状态有不同的含义

• Confirmed = 有人（不是提交者）查看了 bug 并确保其被正确分类。此人必须确保里程碑、重要性和分配者设置正确。但是，bug 可能无法重现或确认是真实的。
• Fix Released = 有人（不是分配者）验证了修复后问题不再重现。此状态留给 QA 以在 bug 修复后将 bug 标记为已验证。

用户体验 (UX) 问题附加指南

在某些情况下，bug 可能会对 UX 产生重大影响，在这种情况下，我们可以使用其他标准来设置 bug 优先级

• Critical = 需要大量精力才能解决，包括未记录/未充分记录的命令和对配置文件进行编辑
• High = 需要修改配置文件，使用用户不应使用的接口（例如，当它_应该_在 CLI / UI 中工作时使用 API（不包括仅应通过 API 可用的接口），或需要自定义节点 yaml（同样，除非它应该仅通过 API 可用））
• Medium: CLI 中的直接命令
• Low 和 Wishlist = 如上

基础设施 bug 附加指南

• Critical = 至少一个团队被阻止或关键功能的交付被阻止，没有解决方法
• High = 关键问题有解决方法，或者没有解决方法的其他基础设施回归，或者关键功能的交付被阻止
• Medium = 有解决方法的基础设施回归，或者需要交付中等严重程度的功能
• Low = 基础设施可靠性、可重现性或覆盖率改进
• Wishlist = 不符合更高优先级 UX 问题定义的化妆品基础设施改进

文档 bug 附加指南

• Critical = 遵循文档中的说明可能导致停机或数据丢失
• High = 文档包含不正确的信息，或者指令无法产生广告的结果
• Medium = 文档中缺少重要信息（例如，新功能描述）
• Low = 附加信息可以改善读者对功能的理解
• Wishlist = 格式和语法问题

Bug 分类例程

在对 bug 进行分类时，请使用以下例程

1. 审查所有 New bug。
2. 将每个 New bug 分配给正在开发中的发布系列（根据 Fuel 项目时间线 重点开发），并为该发布系列设置相应的 bug 状态和里程碑。
3. 考虑更改 bug 标题以使其更具体，替换通用的语句，例如“部署超时”，并描述根本原因（如果已识别）或该 bug 的独特症状。
4. 考虑 bug 的可见性状态。如果它包含敏感信息，请将其设置为 Private。如果它描述了安全漏洞，请将其设置为 Private Security。
5. 如果 bug 不包含 Fuel/How_to_contribute#Test_and_report_bugs 中描述的足够信息，请请求缺失的信息，并将 bug 状态设置为 Incomplete。添加使用以下模板的评论：我们没有收到正确排除故障所需的详细信息，因此我们将此 bug 设置为 Incomplete 状态。请提供请求的信息，我们将进一步调查此问题。如果您认为它被错误地设置为 Incomplete，请在 bug 中评论。
6. 根据 Fuel/Bug_tags#Area_tags 列表添加区域标签。
7. 从 Fuel bug tags taxonomy 添加其他适用的标签。
8. 如果有关如何重现 bug 的信息足够，并且里程碑、重要性和分配者设置正确，则将状态设置为 Confirmed。
9. 如果有关如何开始实施修复的信息足够，则将状态设置为 Triaged。
10. 如果已识别 bug 的根本原因，请将其包含在 bug 描述中。
11. 审查所有 Incomplete bug
12. 如果 Incomplete bug 有新的更新，请按照上述 New bug 的步骤操作。
13. 如果 Incomplete bug 在 4 周内没有更新，请将其关闭为 Invalid。添加使用以下模板的评论：此 bug 不完整超过 4 周。我们无法进一步调查它，因此我们将状态设置为 Invalid。如果您认为不正确，请随时提供请求的信息并重新打开 bug，我们将进一步查看它。
14. 在发布进行 Code Freeze 时，审查所有针对该发布里程碑的 bug，确保分配者（或 bug 报告者，如果 bug 未分配给任何人）每天更新它。
15. 如果您知道该 bug 与某些蓝图相关，请将此 bug 链接到这些蓝图。为此，请转到相应的蓝图页面并点击“Link a bug report”链接。

请记住，bug 的每个状态更改都必须附带一条评论，解释进行更改的原因。

有用的 LaunchPad 搜索和工具

• 新错误
• Incomplete bugs
• Unassigned bugs
• fuel-library 中的 bug，按里程碑排序
• Firefox 的 Launchpad Helper
• Chrome 的 Launchpad Helper

修复 bug

为 Fuel 贡献代码的最简单方法是从修复 bug 开始。首先，查看 带有“low-hanging-fruit”标签的 bug。您也可以选择任何其他 bug。为了更轻松地管理 bug，Fuel 使用多个功能组，您会看到 bug 分配给 fuel-python、fuel-library、fuel-qa 和其他团队。随意选择其中任何一个。它分配给组，以便组可以收到有关 bug 的电子邮件通知。除非它重新分配给特定工程师来处理该 bug，否则这意味着该 bug 尚未被任何人采用，因此您可以随意采用它。分配给某个人的 bug 并不一定意味着有人正在处理它们（但在理想情况下应该如此）。即使它处于“正在进行中”状态，也请随意联系该人并询问他是否真的在处理该 bug，如果确实如此，请随意分配给自己。

带有 swarm-blocker 标签的 bug 的特殊流程

带有“swarm-blocker”标签的 bug 会阻止我们的夜间测试，应尽快修复。其他开发人员也可能被此类 bug 阻止。我们对这些 bug 有两个额外的要求，以改善沟通、计划、分析和减少它们的发生。

修复此错误的开发者应提供带有“ETA: 合并日期”文本的评论，说明当前版本的初步修复交付日期。应在分配错误时提供此信息，并在需要时使用新的评论进行更新。

此外，修复此错误的开发者应提供带有“RCA: 根本原因分析”文本的评论，其中描述了此错误出现的原因。理想情况下，它应包含指向回归审查的链接。其他常见情况包括“新的测试用例”和“测试用例中的错误”。应在可用时提供此信息。之后，开发者应添加“rca-provided”标签。

将错误修复回移植到稳定的发布系列

当您创建一个新的高或关键优先级的错误，或升级一个现有的错误时，请始终检查此错误是否存在于受支持的稳定发布系列中（至少一个最新的稳定发布）。如果存在，则将其定位到所有受影响的系列（即使您不期望最终能够回移植修复）。如果它不存在于稳定版本中，请在错误中记录该信息，以便其他人无需重新检查。

当您提出错误的修复方案时，请始终从修复主分支开始。如果修复仅适用于稳定分支并且与主分支无关，请在提交消息中说明。对于针对稳定发布系列的错误，在修复合并到主分支后（过早创建回移植会导致主分支和稳定/x.x版本之间可能的不一致），将修复提交cherry-pick到每个目标系列的稳定/x.x分支。使用相同的Change-Id和主题（git review -t bug/<id>）以便更容易跟踪该错误的 所有回移植。如果提交可以应用于稳定分支而没有冲突，您还可以使用Gerrit中的“Cherry Pick To”按钮。请注意，通常由作者管理补丁的Change-Id，但我们坚持在所有相关回移植中保持Change-Id相同。

当您批准主分支的错误修复提交时，请使用错误和审查请求中可用的信息来审查并可能更新错误的后移植状态。它的优先级是否足够高，需要进行后移植？它是否针对所有受影响的发布系列？是否有后移植提交已经存在？如果是，它们是否与合并到主分支的提交保持最新？

• 对于应存在但不存在的每个系列，请自行创建一个后移植审查请求。
• 对于所有其他受影响的系列，将错误状态更改为“不会修复”，并在错误评论中说明原因。
• 在提交合并到主分支之前，请勿将其合并到稳定分支，除非提交消息明确记录了为什么它不适用于主分支。

当您在稳定版本中发现错误时，不要简单地将其定位到该维护版本系列中的下一个版本。相反，将其定位到Launchpad上的Fuel主页上指定为“当前重点”的版本。如果这是一个高或关键优先级的错误，此外还将它定位到最初发现错误的发布系列，以及（如果适用）所有介于两者之间的发布系列。

如果一个错误存在于维护版本中，而不存在于当前发布系列中，则它应在当前发布系列中具有以下状态之一

• 不完整，如果根本原因分析尚未完成
• 已修复，如果根本原因分析表明该错误已通过维护版本发现后合并的更改修复
• 无效，如果根本原因分析表明该错误是由此维护版本系列特定的更改引入的

增强功能

提出增强功能

Fuel的增强功能使用蓝图机制提出。该过程与错误非常相似

• 选择“注册蓝图”。通常，您会在launchpad页面的右侧找到此链接。
  • 输入蓝图的名称。如果可能，请将Fuel的子组件名称作为名称的第一个词（或者对于更广泛的蓝图，只需使用fuel），然后使用破折号分隔的简短描述符。例如，ui-declarative-wizard或fuel-stop-deployment。
  • 输入蓝图的标题。标题应尽可能清楚地描述该功能，最多70个字符。此标题将显示在每个功能列表或报告中。
• 输入蓝图的摘要。
  • 用用户故事总结蓝图的想法。如果您在公共文档中有一个现有的用户故事，请包含该链接。
  • 如果尚未创建公共文档并且用户故事很长，您可以使用https://etherpad.openstack.org/来记录完整的用户故事。您可以使用用于蓝图的名称作为Pad名称。
• 通过选择计划完成蓝图的里程碑来提出您的蓝图。
• 您无需输入任何其他字段，现在只需选择“注册蓝图”。

如果您只是输入一个新想法而没有设计，您可以将“规范URL”字段留空。如果您有设计，以下是如何发布和批准它

• 将设计规范上传到fuel-specs中的“specs/<release>”文件夹
  • 例如，access-control-master-node
  • 它应基于模板，有关更多详细信息，请参阅模板中的说明
  • 通过 Gerrit 提交您的补丁以进行审查，以通常的方式：开发工作流程
  • 在每个版本的结束时，未完成的规范将被删除
  • 如果蓝图延期，您需要重新提交以供下一个版本使用

• 为了使您的规范获得批准，通常需要获得以下人员的+1
  • 所有强制设计审查员（通常是熟悉所提议增强功能领域的 人员）
  • 如果有主题专家（例如，您的增强功能以某种方式影响Fuel Web UI，那么您需要从Fuel Web UI团队获得+1）
  • QA
  • 对于跨组件的增强功能，还需要获得受影响组件核心的+1。

• 一旦您的设计规范获得批准并合并到fuel-specs git仓库中
  • 更新您的蓝图的规范URL，以指向fuel-specs git中的设计规范
  • 请注意，这应链接到git（如上面的模板链接），而不是gerrit更改

完成后，向邮件列表发送一封关于新蓝图的电子邮件，以吸引Fuel开发人员的注意，他们可能会提供早期反馈并要求更多信息。

请阅读OpenStack Blueprints页面，以获取蓝图及其生命周期的详细定义。

实现新功能

要实现新功能，您需要解决以下问题

1. 提交蓝图，其中包含所有必需的功能详细信息，如Propose enhancements部分和Blueprints页面中所述
2. Fuel的PTL或核心开发者应在提供所有必要信息后批准蓝图。
3. 请不要进行任何积极的贡献，除非对设计达成一致。要获得批准，您可以在邮件列表中讨论该功能。
4. 每个新功能不得破坏其他功能，并且无论与我们之前拥有的功能一起工作，或者与不适用于新功能的那些功能一起禁用。以下是需要检查兼容性的功能简短列表
   • 所有发行版（当前CentOS和Ubuntu）
   • 网络（nova-network，Neutron）
   • 节点上与其他角色的组合。例如，MongoDB角色不应与Ceph放在一起。
   • 磁盘分区（它将使用现有分区还是需要创建新分区？）
   • 网络验证
5. 功能的其他要求
   • Fuel Library贡献的服务日志记录应通过rsyslog完成
   • 实现应具有可扩展性，否则应在设计文档中明确说明限制。降低现有功能的扩展性和性能是不可接受的。
6. 开始实现并频繁地提出小的代码更改。这是成功合并的唯一方法 - 审查包含1000多行代码的更改集是不现实的。
7. 每个功能都应有一组测试
   • CasperJS和Selenium测试用于Fuel Web UI
   • Nailgun使用Python Unit Test框架进行单元和集成测试
   • Astute使用RSpec进行单元和集成测试
   • 考虑扩展OSTF测试以实现该功能
   • 系统测试，它使用Devops框架，在ISO上运行，即当所有组件集成时。系统测试持续长达6-8小时，并且每晚运行一次。由于这些测试是在集成环境中运行的，因此其结果代表着更高的兴趣。每个在多个Fuel组件中具有组件的大型功能必须由系统测试覆盖。
   • 如果功能需要特殊硬件或特殊部署设置，则应使用此类硬件和所需的更改扩展现有的CI到devops框架。应在邮件列表中与Fuel社区讨论，以便达成共同的决定。
8. 文档。新功能必须在用户和开发文档中得到充分记录。
9. 请在功能冻结日期之前提出功能的更改。否则，在代码冻结之前甚至不会审查更改，并且我们不会在创建里程碑提出的分支之前将更改导入主分支。这将允许Fuel团队专注于当前版本的稳定化，并将所有力量投入到修复错误中。规则与核心OpenStack项目类似，请参阅FeatureFreeze和ReleaseCycle。

带有“feature”标签的错误

我们有一个专门的交付团队致力于小的增强功能，以弥补Fuel功能的不足

它处理带有“feature”标签的错误和估计持续时间小于5个工日的微型故事

您可以在Enhancements Team Trello Board上跟踪这些活动

测试

Nailgun的单元和集成测试

Nailgun使用Python Unit Test框架进行单元和集成测试。编写测试的帮助非常受欢迎 - 我们始终希望获得更好的覆盖率！请查看如何设置Nailgun单元测试开发环境，并遵循如何测试您的代码指导。

代码审查规则

向Fuel贡献代码更改时，请使用开发工作流程并遵循Fuel特定的规则和建议。