示例规范 - 您的规范标题¶

日期:: 2016-10-13 22:00
标签:: 用于分组和索引

请使用规范提出日期更新您的规范日期。添加任何对理解规范内容有帮助的标签。

提供一个关于您创建此规范/蓝图的原因的概要。

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/openstack-ansible/+spec/example

引言段落 – 我们为什么要这样做？一段运维人员可以理解的文字。尽可能详细地描述问题。

关于使用此模板的一些说明

您的规范应使用 ReSTructured 文本，就像此模板一样。
请将文本换行到 79 列。
Git 仓库中的文件名应与 Launchpad URL 匹配，例如：URL 为：https://blueprints.launchpad.net/openstack-ansible/+spec/awesome-thing 应命名为 awesome-thing.rst
请勿删除此模板中的任何部分。如果您对整个部分没有要说的内容，只需写“None”或“N/A”。
有关语法帮助，请参阅 https://sphinx-doc.cn/rest.html
要测试您的格式，请使用 tox 构建文档，或参见：http://rst.ninjs.org
如果您想在规范中提供图表，则需要使用 ASCII 图表。 http://asciiflow.com/ 是一个很好的工具，可以帮助创建 ASCII 图表。原因是用于审查规范的工具完全基于纯文本。纯文本将允许审查人员无需查看无法在 gerrit 中查看的附加文件即可进行审查。它还将允许对图表本身进行内联反馈。

问题描述¶

问题详细描述

对于新功能，这可能是用例。确保您清楚地说明每个用例中的参与者：最终用户与部署者。
对于现有功能的重大重构，需要描述该功能中正在解决的问题。

提议的变更¶

提供您希望看到的更改的概述。在这里详细介绍您提出的更改。您打算如何解决这个问题？

显著变更

列出所有显著的变更。

如果这是更大工作的一部分，请明确说明这部分在哪里结束。换句话说，这项工作的范围是什么？

备选方案¶

您提出的更改有哪些替代方案？我们还可以用其他什么方式来做这件事？为什么我们不使用那些方案？这不必是全面的文献综述，但它应该表明您已经考虑过为什么提出的解决方案是合适的。

Playbook/Role 影响¶

这些更改将对 playbook 产生什么影响？

升级影响¶

如果此更改涉及任何类型的升级过程，请描述它如何处理这些内容。例如，如果容器被删除或其特定用途发生更改，您打算如何处理现有安装的最终升级？此更改是否需要文档才能完全支持，或者是否需要创建特定的工具才能完成升级？

安全影响¶

描述对系统造成的任何潜在安全影响。需要考虑的一些项目包括

此更改是否涉及敏感数据，例如令牌、密钥或用户数据？
此更改是否会改变已部署的 OpenStack API，从而可能影响安全性，例如以新的方式访问敏感信息或以新的方式登录？
此更改是否涉及密码学或哈希？
此更改是否需要使用 sudo 或任何特权？
此更改是否涉及使用或解析用户提供的数据？这可能是直接在 API 级别，或间接例如更改缓存层。

有关更详细的指导，请参阅 OpenStack 安全指南作为参考 (https://wiki.openstack.org/wiki/Security/Guidelines)。这些指南正在不断完善中，旨在帮助您识别安全最佳实践。有关更多信息，请随时通过 openstack-security@lists.openstack.org 联系 OpenStack 安全组。

性能影响¶

描述任何潜在的系统性能影响。例如，代码是如何执行的，它是否依赖于可能不可用的上游资源？

需要考虑的一些示例包括

添加用于升级软件包的新 PPA，维护者是谁？此人多久推送一次？此人/公司维护特定软件包多久了？
为用于 Python wheel 添加额外的固定软件包。此软件包是否经常更改？是否有测试？

最终用户影响¶

此更改将如何影响最终用户？“最终用户”定义为已部署云的用户。

部署者影响¶

此更改将如何影响部署者？讨论将影响 OpenStack 部署方式的事情，例如

正在添加哪些配置选项？它们是否应该比建议的更通用？默认值是否适用于实际部署？
此更改是否在合并后立即生效，还是需要显式启用？
如果此更改是新的二进制文件，将如何部署它？
请说明那些进行持续部署的人员，或那些从以前版本升级的人员需要注意的任何事情。同时描述弃用配置值或功能的计划。例如，如果更改了 playbook 的名称，我们如何处理更改发布之前的部署？代码中是否有特殊情况？我们是否假设操作员将在云的基础设施内重新创建容器？这是否会影响云中的运行实例？

开发人员影响¶

此更改如何影响未来开发 Ansible playbook 的开发人员？讨论将影响 OS-Ansible-Deployment 中其他开发人员的事情，例如

如果此规范提出新的 role，该 role 将如何部署？这是新的默认 role 吗？此 role 是否对主机产生影响？

依赖项¶

此蓝图/规范是否依赖于其他蓝图或规范？

包括对 os-ansible-deployment 或其他项目中，此规范依赖或相关的规范和/或蓝图的具体引用。
新的需求是否是由于上游更改引起的？如果是，请记录它并提供对更改的引用。

实现¶

负责人¶

谁在编写代码？或者这是一个蓝图，您正在将其抛出以查看谁会接受它？

如果有多个人正在进行实现，请指定主要作者和联系人。

主要负责人: <launchpad-id 或 None>
其他贡献者: <launchpad-id 或 None>

请在适用时添加 IRC 昵称。

工作项¶

工作项目或任务 – 将该功能分解为实施它需要完成的事情。这些部分可能最终由不同的人完成，但我们主要试图了解实施的时间表。

测试¶

请讨论如何测试更改。您应该能够回答以下问题

此更改是否会影响 gating 的方式？
此更改是否可以基于 每次提交 进行测试？
考虑到 OpenStack Infra 中实例大小的限制（8GB Ram，vCPUs <= 8），测试是否可以在资源受限的环境中运行？
鉴于当前的限制（可用的特定硬件/软件配置），此测试是否无法进行？如果是这样，是否有缓解计划，以便在第三方测试、gate 增强等方式下测试此更改？
如果服务不是 OpenStack 特定的，我们如何测试更改？

文档影响¶

此更改对文档团队有什么影响？有些更改可能需要向文档团队捐赠资源以更新文档。不要重复上面讨论的细节，但请在此处引用它们。

参考资料¶

请添加任何有用的参考资料。您不需要有任何参考资料。此外，当您的参考资料不可用时，此规范仍然应该有意义。您可以包括的内容示例是

邮件列表或 IRC 讨论的链接
如果合适，相关研究的链接
相关的规范（如果适用）
您认为值得参考的任何其他内容

示例规范 - 您的规范标题