跳转到： 导航, 搜索

Ironic/开发者指南

开发者指南

开发者文档 提供了一个良好的起点。 这提供了进行开发的一些通用指南。

异常

通常情况下，ironic 应该只抛出 ironic 异常。 特别是

  • 驱动程序应该处理（非 ironic 异常）并且只让 ironic 异常被抛出
  • 内部方法不需要文档字符串（尽管 rloo 喜欢它们）
  • 公共方法需要有文档字符串，并且包含所有已知该方法（或该方法调用的任何方法）可能抛出的异常的“:raises:”。

向后兼容性

我们需要确保我们不会无意中破坏向后兼容性。

这方面很重要的地方

  • REST API。 客户端的先前版本不应因 API 的相同主要版本（例如 /v1/）的更改而严重损坏。 这即使在微版本中也是如此。
  • 驱动程序 API。 我们鼓励使用树外驱动程序。 对在 /ironic/drivers/base.py 中定义的驱动程序 api 的任何更改都必须向后兼容。 重大的更改可以通过弃用周期来处理。


需要注意的一些事项

  • 异常名称。 如果你想更改异常类的名称，请为原始名称添加一个别名。 提交应该有一个 DocImpact 标记，其中包含对已弃用内容、何时删除以及使用什么（如果有）的描述。

弃用

Ironic 遵循 OpenStack 的 标准弃用流程。 如果某些内容将被弃用，我们需要

  • 通过电子邮件告知 Ironic 社区它已被弃用以及何时删除
  • 在弃用期间，如果合理，我们应该警告和/或记录对已弃用内容的所有使用
  • 弃用和删除之间应至少提供一个发布周期，并且必须经过至少 3 个月
  • 删除后，通过电子邮件告知 Ironic 社区

Tempest 测试

[Tempest] 测试是黑盒功能测试。 [Ironic 使用 tempest] 进行 API 和功能测试。

如果你的更改包含重要的 API 可见功能，应该有相应的 tempest 测试覆盖。 例如，nova.virt.ironic 驱动程序所做的一切。 负责代码更改的开发人员也负责确保有 tempest 测试覆盖。 （开发人员不必进行 tempest 测试更改；他们可以与其他开发人员合作来帮助编写 tempest 测试。）

Tempest 通过 devstack 运行，其中克隆了 Ironic 的最新 master 分支，然后对其运行测试。 因此，更改必须在 Ironic 中才能通过 tempest 测试。 建议的流程是

  • 代码更改准备好进行审查
  • 相应的 tempest 更改准备好进行审查
  • 如果没有相应的 tempest 更改，代码更改可能会被阻止批准
  • 在代码更改合并后，将合并 tempest 更改。 如果 tempest 测试失败，我们都会尖叫。

文档

图表

  • 对于规范，使用 http://asciiflow.com，所以我们决定也将其用于我们的 ironic 文档

自动化 CI 测试

*重新检查*失败的 CI 测试

  • 检查从 CI 测试上传的日志，看看问题是否与你的更改有关。
  • 如果你认为没有，请在 http://status.openstack.org/elastic-recheck/ 中检查问题是否之前已经报告过
  • 如果你发现这是一个已知问题，请在 gerrit 审查中发布评论“recheck bug <bug#>”，其中 <bug#> 是错误的数字标识符。 例如“recheck bug 1408067”。 这也有助于跟踪一天内相同问题被击中的次数。
  • 如果你找不到 bug #，你有以下选项
从 "https://wiki.openstack.org/w/index.php?title=Ironic/Developer_guidelines&oldid=161103" 检索