示例规范 - 您的蓝图标题¶
介绍段落 – 为什么要进行这项工作？一段操作员可以理解的散文。
关于使用此模板的一些说明
您的规范应使用 ReST 结构化文本，就像这个模板一样。
文本换行至 79 列。
Git 仓库中的文件名应描述该特性。例如，如果该特性名为“新特性”，则文件应命名为 new-feature.rst
请注意，此过程不再使用 Launchpad 中的蓝图，而是使用 bug 进行跟踪。Bug 优于蓝图，因为提出的并合并的补丁会收到评论，而 bug 上的评论是不可变的。这确保了我们的 bug 跟踪器中补丁的跟踪不会因有人编辑 bug 的正文而意外丢失（与蓝图不同，蓝图中的所有数据都类似于 bug 描述，并且没有历史跟踪）。
您需要在 Launchpad 中打开一个 bug 来跟踪更改。该 bug 将链接到每个补丁的提交消息中，用于该特性（包括此规范），以便在进行更改时，CI 系统会在 bug 上生成评论，并帮助我们跟踪为该特性所做的一切工作。bug 号码应替换链接中的
XXXXXXX。请务必在提交此规范的提交消息中使用
partial-bug: #XXXXXXX（其中XXXXXXX是 bug ID）。不要删除此模板中的任何部分。如果您对整个部分没有什么要说的，只需写：None
请注意，样板文本应替换为真实文本或
None。要测试您的格式，请使用 tox 构建文档，或参见：http://rst.ninjs.org
如果您想在规范中提供图表，则需要使用 ASCII 图表。 http://asciiflow.com/ 是一个很好的工具，可以帮助创建 ASCII 图表。原因是用于审查规范的工具完全基于纯文本。纯文本将允许审查人员无需查看无法在 gerrit 中查看的附加文件即可进行审查。它还将允许对图表本身进行内联反馈。
问题描述¶
问题详细描述
对于新特性，这可能是用例。确保您清楚地了解每个用例中的参与者：最终用户与部署者
对于代码部分的主要重构，它将描述正在解决该特性中的问题。
本节应清楚地说明为什么社区需要一个解决该问题的方案。
提议的变更¶
在这里，您描述您提议进行的更改。您如何提出解决此问题？在架构层面解决该问题，将实现细节留给代码审查。
如果这是更大工作的一部分，请明确说明这部分在哪里结束。换句话说，这项工作的范围是什么？
备选方案¶
我们还可以用什么方法来做这件事？我们为什么不使用那些方法？这不必是全面的文献综述，但它应该表明已经考虑过为什么建议的解决方案是合适的。
安全影响¶
描述对系统造成的任何潜在安全影响。需要考虑的一些项目包括
此更改是否涉及敏感数据，例如令牌、密钥或用户数据？
此更改是否以可能影响安全性的方式更改了 API，例如访问敏感信息的新方式或登录的新方式？
此更改是否涉及密码学或哈希？
此更改是否需要使用 sudo 或任何特权？
此更改是否涉及使用或解析用户提供的数据？这可能是直接在 API 级别，或间接例如更改缓存层。
此更改是否会启用资源耗尽攻击，例如允许单个 API 交互消耗大量的服务器资源？这方面的一些例子包括为每个连接启动子进程，或 XML 中的实体扩展攻击。
有关更详细的指导，请参阅 OpenStack 安全指南作为参考 (https://wiki.openstack.org/wiki/Security/Guidelines)。这些指南正在不断完善中，旨在帮助您识别安全最佳实践。有关更多信息，请随时通过 openstack-security@lists.openstack.org 联系 OpenStack 安全组。
通知影响¶
请指定任何通知的更改。无论是额外的通知、对现有通知的更改，还是删除通知。
其他最终用户影响¶
除了 API 之外，用户还有其他方式与此功能交互吗？
此更改是否对 python-keystoneclient 有影响？那里的用户界面是什么样的？
性能影响¶
描述对系统造成的任何潜在性能影响，例如新代码将被调用多少次，以及现有代码的调用模式是否有重大变化。
需要考虑的一些示例包括
对实用函数或常用装饰器的微小更改可能对性能产生巨大影响。
导致数据库查询的调用，在代码的关键部分调用时，可能会对性能产生重大影响。
此更改是否包含任何锁定，如果是这样，对持有锁有什么考虑？
其他部署者影响¶
讨论将影响您部署和配置 OpenStack 的事情，这些事情尚未提及，例如
正在添加哪些配置选项？它们是否应该比建议的更通用（例如，其他 hypervisor 驱动程序可能想要实现的标志）？默认值是否适用于实际部署？
此更改是否在合并后立即生效，还是需要显式启用？
如果此更改是新的二进制文件，将如何部署它？
请说明那些进行持续部署的人员，或那些从以前的版本升级的人员需要注意的事情。此外，请描述弃用配置值或功能的计划。例如，如果我们将实例存储的目录名称更改了，我们如何处理更改着陆之前创建的实例目录？我们是否移动它们？我们是否在代码中有一个特殊案例？我们是否假设操作员将重新创建云中的所有实例？
开发人员影响¶
讨论将影响在 OpenStack 上工作的其他开发人员的事情，例如
如果蓝图提出对驱动程序 API 的更改，则需要讨论其他后端将如何实现该特性。
实现¶
负责人¶
谁在编写代码？或者这是一个蓝图，您正在将其抛出以查看谁会接受它？
如果有多个人正在进行实现，请指定主要作者和联系人。
- 主要负责人
<launchpad-id 或 None>
- 其他贡献者
<launchpad-id 或 None>
工作项¶
工作项目或任务 – 将该功能分解为实施它需要完成的事情。这些部分可能最终由不同的人完成，但我们主要试图了解实施的时间表。
依赖项¶
包括对 Keystone 或其他项目中，此规范依赖或相关的规范和/或蓝图的具体引用。
如果这需要 Keystone 当前未使用另一个项目的功能（例如，当我们以前只需要 v1 时使用的 glance v2 API），请记录这一事实。
此功能是否需要任何新的库依赖项或未包含在 OpenStack 中的代码？或者它是否依赖于库的特定版本？
文档影响¶
此更改对文档团队有什么影响？有些更改可能需要向文档团队捐赠资源以更新文档。不要重复上面讨论的细节，但请在此处引用它们。
参考资料¶
请添加任何有用的参考资料。您不需要有任何参考资料。此外，当您的参考资料不可用时，此规范仍然应该有意义。您可以包括的内容示例是
邮件列表或 IRC 讨论的链接
峰会会议记录的链接
如果合适，相关研究的链接
相关的规范（例如，如果它是 EC2 事情，请链接 EC2 文档）
您认为值得参考的任何其他内容
