您的规范标题¶
包含您的 StoryBoard 故事的 URL（应该带有 rfe` 标签）
https://storyboard.openstack.org/#!/story/XXXXXXX
介绍段落 – 我们为什么要这样做？
关于使用此模板的一些说明
您的规范应使用 ReSTructured 文本，就像此模板一样。
请将文本换行到 79 列。
请勿删除此模板中的任何部分。如果您对整个部分没有什么要说的，只需写上：无
有关语法帮助，请参阅 https://sphinx-doc.cn/en/master/usage/restructuredtext/basics.html
要测试您的格式，请使用 tox 构建文档，或参见：http://rst.ninjs.org
如果您想在规范中提供图表，则需要使用 ASCII 图表。 http://asciiflow.com/ 是一个很好的工具，可以帮助创建 ASCII 图表。原因是用于审查规范的工具完全基于纯文本。纯文本将允许审查人员无需查看无法在 gerrit 中查看的附加文件即可进行审查。它还将允许对图表本身进行内联反馈。
提议的变更¶
在这里详细介绍您建议进行的更改。您如何提出解决此问题的方法？
如果这是更大工作的一部分，请明确说明这部分在哪里结束。换句话说，这项工作的范围是什么？
包含这将在 ironic-inspector 树结构层次中的位置。
备选方案¶
这是一个可选部分，在适用时，我们只是希望展示已经考虑过为什么建议的方法是最好的。
数据模型影响¶
需要修改数据模型的变化通常会对系统产生更广泛的影响。社区通常对数据模型应该如何演进持有强烈的意见，从功能和性能的角度来看都是如此。因此，尽早捕获并达成对任何拟议的数据模型更改的共识非常重要。
本节需要解决的问题包括
这将需要哪些新的数据对象和/或数据库模式更改？
将伴随此更改哪些数据库迁移？
如何生成初始的新数据对象集？例如，如果您需要考虑现有的实例，或修改其他现有数据，请描述其工作方式。
HTTP API 影响¶
描述 HTTP API 的更改。
每个添加或更改的 API 方法都应具有以下内容
方法的规范
对方法功能的描述，适合在用户文档中使用。
方法类型 (POST/PUT/GET/DELETE/PATCH)
正常的 http 响应代码
预期的错误 http 响应代码
应包含每个可能错误代码的描述。描述可能导致它的语义错误，例如提供给该方法的参数不一致，或者当资源不在请求成功状态时。JSON 模式定义涵盖的语法问题导致的错误无需包含。
资源的 URL
可以通过 URL 传递的参数，包括数据类型
如果允许，则为 body 数据定义 JSON schema
如果存在，则为响应数据定义 JSON schema
API 微版本是否需要递增？
示例用例，包括调用者提供的数据和响应的典型 API 示例
此更改是否可被客户端发现？并非所有客户端都会同时升级，因此此更改必须与旧客户端协同工作，而不会破坏它们。
请注意，模式应尽可能严格地定义。应将必需的参数标记为必需，并且在特殊情况下才允许未在模式中定义的额外参数。
强烈鼓励重用现有的预定义参数类型。
客户端 (CLI) 影响¶
通常情况下，但并非总是如此，如果有任何 REST API 更改，则会对应 ironic-inspector-client 的更改。如果是这样，用户界面是什么样的。如果不是，请描述为什么有 REST API 更改但没有客户端的更改。
Ironic python agent 影响¶
如果此更改影响 ironic-python-agent，请在此处描述相关的更改。
本节需要解决的问题包括
对 ironic-python-agent 的影响是什么？
如果更改影响现有功能，如何执行升级？如何进行测试？
性能和可扩展性影响¶
描述对系统造成的任何潜在性能影响，例如新代码将被调用多少次，以及现有代码的调用模式是否有重大变化。
描述系统可能存在的可扩展性影响，例如网络、RPC 或数据库流量的任何增加，或者该功能是否需要跨多个服务的同步。
安全影响¶
描述系统可能存在的安全影响。
部署者影响¶
讨论将影响您部署和配置 OpenStack 的事情，这些事情尚未提及，例如
正在添加哪些配置选项？它们是否应该比建议的更通用（例如，其他硬件驱动程序可能想要实现的标志）？默认值是否适合生产环境？提供解释说明为什么这些默认值是合理的。
这是一个合并后立即生效的更改，还是需要显式启用？
如果此更改添加了部署者需要运行的新服务，如何部署它？描述预期的拓扑结构，例如新服务需要哪些网络连接，它将与哪些服务交互，相对于部署规模应该运行多少个实例等。
请说明那些执行持续部署或从以前版本升级的人需要注意的事项。同时描述弃用配置值或功能的计划。
如果您的提案包含对 REST API 的任何更改，请描述现有客户端在与升级后的 API 服务器交互时将如何继续工作。
描述您将添加哪些测试来确保保持向后兼容性。
如果弃用现有功能或 API，请描述弃用计划，以及将保持兼容多长时间。
升级和向后兼容性¶
必须小心，通过不破坏 REST API 或数据处理插件 API 的向后兼容性来支持我们的用户。
如果您的提案包含对 REST API 的任何更改，请描述现有客户端在与升级后的 API 服务器交互时将如何继续工作。
如果您的提案包含对插件 API 的任何更改，请描述现有插件实现将如何与新的插件接口一起工作。
描述您将添加哪些测试来确保保持向后兼容性。
如果弃用现有功能或 API，请描述弃用计划，以及将保持兼容多长时间。
如果新代码需要比“数据库迁移”更多的东西，请在此处描述升级过程。
实现¶
负责人¶
谁在编写代码？或者这是一个蓝图，您正在将其抛出以查看谁会接受它？
如果有多个人正在进行实现，请指定主要作者和联系人。
- 主要负责人
<IRC 用户名、电子邮件地址或无>
- 其他贡献者
<IRC 用户名、电子邮件地址、无>
工作项¶
工作项目或任务 – 将该功能分解为实施它需要完成的事情。这些部分可能最终由不同的人完成，但我们主要试图了解实施的时间表。
依赖项¶
包含对 ironic-inspector 或其他项目中，此规范依赖或相关的规范和/或蓝图的具体引用。
此功能是否需要任何新的库依赖项或未包含在 OpenStack 中的代码？或者它是否依赖于库的特定版本？
测试¶
请讨论如何测试更改。我们特别想知道将添加哪些 tempest 测试。假设将添加单元测试覆盖率，因此无需显式提及，但讨论为什么您认为单元测试就足够了，我们不需要添加更多 tempest 测试将需要包括在内。
参考资料¶
请添加任何有用的参考资料。您不需要有任何参考资料。此外，当您的参考资料不可用时，此规范仍然应该有意义。您可以包括的内容示例是
邮件列表或 IRC 讨论的链接
峰会会议记录的链接
如果合适，相关研究的链接
相关的规范（例如，如果它是 EC2 事情，请链接 EC2 文档）
您认为值得参考的任何其他内容
