您的规范标题

介绍段落 – 我们为什么要这样做？

问题描述

对问题的详细描述。

提议的变更

在这里详细介绍您建议进行的更改。您如何提出解决此问题的方法？

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

受影响或要求的操作系统版本有哪些？

受影响或要求的 OpenStack 版本有哪些？

需要哪个版本的 Juju？

备选方案

这是一个可选部分，在适用时，我们只是希望展示已经考虑过为什么建议的方法是最好的。

实现

负责人

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

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

主要负责人

<launchpad-id 或 None>

如果他们打算对该蓝图进行大量实现工作，可以可选地列出其他 ID。

Gerrit Topic

对于与此规范相关的所有补丁，请使用 Gerrit 主题“<topic_name>”。

git-review -t <topic_name>

工作项

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

仓库

是否需要创建新的 git 仓库？

识别所有新的 charm 仓库、接口仓库、层仓库，无论新旧，这些仓库将直接受到此规范定义的工作的影响或参与其中。

文档

这是否需要文档更改？如果是，哪些文档？它会影响开发人员的工作流程吗？是否需要进行额外的沟通？

明确识别文档更新的范围，例如 charm-guide、deployment-guide、charm README、wiki 页面链接。

安全性

这是否会引入任何额外的安全风险，或者是否有需要讨论的安全相关问题？

测试

将提供哪些测试，或者需要构建哪些测试来验证这一点？ 单元/功能测试、开发环境/服务器等。

测试此规范是否有任何特殊的硬件要求？

依赖项

• 包括对规范和/或故事，或其他项目的具体引用，该规范依赖于或与这些规范相关。

• 此功能是否需要任何尚未使用的新的库或程序依赖项？

• 有什么计划来打包和分发有效载荷和/或依赖项？