测试¶
向新的角色添加测试¶
每个角色的测试都在其 tests/ 文件夹中。
此文件夹至少包含以下文件
test.yml(“超级” playbook，作为子 playbook 的测试路由器)<role name>-overrides.yml。此变量文件由我们的 shell 脚本在我们的 tests 仓库中自动加载。inventory。用于角色测试的静态清单。有些角色可能有多个清单。例如，neutron 角色及其ovs_inventory。group_vars和host_vars。这些文件夹将保存用于测试的必要文件的覆盖。例如，您可以在此处覆盖 IP 地址、IP 范围和 ansible 连接详细信息。ansible-role-requirements.yml。这应该相当简单明了：此文件包含在运行您的角色之前要克隆的所有角色。这些角色的相对 playbook 必须在test.yml文件中列出。但是，请记住不要重复造轮子。例如，如果您的角色需要 keystone，则不需要创建您自己的 keystone 安装 playbook，因为我们在 tests 仓库 中有一个通用的 keystone 安装 playbook。仅当您的角色导入到 openstack-ansible 命名空间中时，才添加
zuul.d文件夹。
扩展现有角色的测试¶
修改 tox.ini 以添加您的新场景。如果需要，您可以覆盖清单和/或变量文件。
在
zuul.d/jobs.yaml中添加一个新的非投票作业，并在项目测试文件zuul.d/project.yaml中将其连接起来。
使用 tempest 改进测试¶
一旦初始收敛工作正常并且服务正在运行，角色开发应侧重于实施一定程度的功能测试。
理想情况下，OpenStack 角色的功能测试应使用 Tempest 来执行功能测试。理想的测试是场景测试，因为它们测试了服务在生产部署中预期执行的功能。如果服务没有可用的场景测试，则可以考虑实施烟雾测试作为替代方案。
如果没有提供 tempest，应该进行其他功能测试。对于 API，您可以使用精心设计的请求检查 HTTP 响应代码。
本地运行测试¶
Linting¶
使用 PEP8 测试 Python 编码约定，并具有以下约定例外
F403 - ‘from ansible.module_utils.basic import *’
可以通过执行以下操作在本地进行测试
./run_tests.sh pep8
使用 Bashate 测试 Bash 编码约定，并具有以下约定例外
E003: 缩进不是 4 的倍数。我们更喜欢使用 2 的倍数。
- E006: 行长超过 79 列。由于许多脚本作为模板部署
并使用 jinja 模板，因此很难实现这一点。仍然被认为是一种偏好，应该在合理范围内改进可读性。
- E040: 使用 bash -n 确定的语法错误。由于许多脚本作为模板部署
并使用 jinja 模板，这通常会失败。此测试可以安全地忽略，因为语法错误将在执行结果脚本时被识别。
可以通过执行以下操作在本地进行测试
./run_tests.sh bashate
使用 ansible-lint 进行 Ansible lint 测试。
可以通过执行以下操作在本地进行测试
./run_tests.sh ansible-lint
使用 ansible-playbook 测试 Ansible playbook 语法。
可以通过执行以下操作在本地进行测试
./run_tests.sh ansible-syntax
可以通过执行以下操作在本地完成所有 lint 测试的综合集合
./run_tests.sh linters
文档构建¶
文档使用 reStructuredText (RST) 开发，并使用 Sphinx 编译成 HTML。
可以通过执行以下操作在本地构建文档
./run_tests.sh docs
OpenStack-Ansible 集成仓库还有一个额外的文档构建过程，用于构建部署指南。
可以通过执行以下操作在本地构建此指南
./run_tests.sh deploy-guide
发布说明构建¶
发布说明使用 reno 工具 生成，并使用 Sphinx 编译成 HTML。
可以通过执行以下操作在本地构建发布说明
./run_tests.sh releasenotes
注意
releasenotes 构建参数仅测试提交的更改。在运行 releasenotes 构建之前，请确保您的本地更改已提交。
角色功能或场景测试¶
要运行角色的功能测试，请执行
./run_tests.sh functional
使用 AIO 测试新角色¶
将您的角色包含在部署主机上。另请参阅 在您的 OpenStack-Ansible 安装中添加或覆盖角色。
执行任何其他主机准备（例如
bootstrap-aio.ymlplaybook 执行的任务）。这包括任何特定于您的服务的准备任务。使用
env.d和conf.d文件为您的部署主机生成包含您的服务的文件，以将其包含在 Ansible 清单中。提示
您可以遵循其他角色的示例，进行适当的修改，确保
env.d和conf.d文件中的组标签一致。提示
可以在 了解主机组（conf.d 结构） 和 了解容器组（env.d 结构） 中找到这些工作方式的描述。
生成秘密（如果有），如 配置服务凭据 中所述。您可以将密钥附加到现有的
user_secrets.yml文件，或将新文件添加到openstack_deploy目录中以包含它们。同时提供您现在需要的任何其他变量的覆盖，例如在user_variables.yml或另一个文件中。另请参阅我们的 覆盖默认配置 页面。
任何角色正常工作所需的秘密必须在
etc/openstack_deploy/user_secrets.yml文件中注明，以便其他用户重用。如果您的服务是从源代码安装的或依赖于需要从源代码安装的 python 包，请通过将文件添加到您的部署主机上的
inventory/group_vars/<service_group>/source_git.yml中 OpenStack-Ansible 源代码仓库中，并遵循该目录中现有文件的模式，为源代码指定一个仓库。您也可以简单地将条目添加到现有的文件中。如果需要，对负载均衡器配置（例如，修改 OpenStack-Ansible 源代码仓库中部署主机上的
inventory/group_vars/all/haproxy.yml）进行任何必要的调整，以便您的服务可以通过负载均衡器访问，并确保稍后运行haproxy-install.ymlplaybook 以应用您的更改。请注意，如果您不想为每个人提供您的服务作为默认服务，您也可以使用haproxy_extra_services变量。为您的角色组装一个服务安装 playbook 文件。这也可以从具有类似依赖项的现有服务 playbook 进行建模（数据库、消息传递、存储驱动程序、容器挂载点等）。在 Galaxy 角色中保存 playbook 文件的常见位置是在角色的根目录下的
examples目录中。如果 playbook 旨在安装 OpenStack 服务，请将其命名为os-<service>-install.yml并将其定位到服务env.d文件中定义的相应组。至关重要的是，服务的实现应该是可选的，并且部署者必须通过在适用的主机组中填充主机来选择部署。如果主机组中没有主机，Ansible 会自动跳过 playbook 的任务。其他角色连接到新角色所需的任何变量，或者新角色连接到其他角色所需的任何变量，都应在
inventory/group_vars中实现。组变量基本上是 playbook 用于确保所有角色获得适当信息的粘合剂。实现组变量时，应将其设置为最小集合，以实现将新角色集成到集成构建的目标。必须在角色中添加文档，以描述如何在集成环境中实现新服务。此内容必须符合 文档和发布说明指南。
在角色实施了集成的功能测试（另请参见角色开发成熟度段落）之前，文档必须明确说明在 OpenStack-Ansible 中的服务包含是实验性的，并且未在 OpenStack-Ansible 的集成构建中完全测试。或者，可以创建一个用户故事。
必须添加一个功能发布说明，以宣布新的服务可用性并参考角色文档以获取更多详细信息。此内容必须符合 文档和发布说明指南。
提示
必须能够执行一个功能集成测试，该测试以与生产环境相同的方式执行部署。该测试必须使用 Tempest 执行一组功能测试。这是在服务可以从文档中删除实验性警告之前的最后一步。
如果您遵循将角色额外的部署需求（秘密和变量文件、HAProxy yml 片段、repo_package 文件等）隔离到各自文件中的模式，那么可以轻松地自动化这些额外的步骤来测试您的角色。
集成仓库功能或场景测试¶
要测试集成仓库，请遵循 部署指南
或者，您可以查看 aio 指南，甚至运行 gate wrapper 脚本，名为 scripts/gate-check-commit.sh，如下所述。
OpenStack 基础设施自动化测试¶
在 openstack 基础设施中运行测试与本地运行测试之间不应有任何差异。
基础设施中的测试由每个仓库 zuul.d 文件夹中定义的作业触发。
另请参阅 zuul 用户指南。
但是，为了可靠性，定义了几个变量来指向 OpenStack 基础设施 pypi 和软件包镜像。
集成仓库功能测试使用 scripts/gate-check-commit.sh 脚本，该脚本从 zuul 运行 playbook 定义接收参数。
虽然此脚本主要为在 OpenStack-CI 中使用而开发和维护，但它可以在其他环境中运行。
角色开发成熟度¶
即使角色未集成到 openstack-ansible 仓库中，一个角色也可能是完全成熟的。成熟度取决于其测试级别。
一个角色可以是以下四个成熟度级别之一完整未维护孵化
已退休
以下是一系列定义成熟度级别的规则
如果角色不再相关，则可以随时将其退休。
一个角色最多可以
孵化2 个周期。通过功能测试的
孵化角色将被升级到完整状态，并且不能返回到孵化状态。如果在六个月的时间范围内未实施功能测试的
孵化角色，它将变为未维护。
根据成熟度降级程序，处于 完整 状态的角色可以降级到 未维护 状态。
成熟度降级程序¶
如果角色在两个星期内未能通过周期性测试或 gate 测试，应提交一个错误报告，并向邮件列表发送一条消息，引用该错误报告。
下一个社区会议应讨论角色弃用问题，如果没有任何贡献者提出修复角色，则将关闭周期性测试，并且该角色将进入 未维护 状态。
成熟度矩阵¶
并非所有 OpenStack-Ansible 角色都具有相同的成熟度和测试级别。
以下是角色当前状态的仪表板
| 角色名称 | 在周期期间创建 | 成熟度级别 | 默认包含在 openstack-ansible 中 | 支持 Ubuntu | 支持 CentOS |
|---|---|---|---|---|---|
| ansible-hardening | Liberty | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| apt_package_pinning | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✘ |
| ceph_client | Newton | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| galera_server | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| haproxy_server | Newton | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| lxc_container_create | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| lxc_hosts | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| memcached_server | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| openstack_hosts | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| openstack_openrc | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_adjutant | Ussuri | 完整 | ✔ | ✔ | ✔ |
| os_aodh | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_barbican | Ocata | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_ceilometer | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_cinder | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_cloudkitty | Ocata | 完整 | ✘ | ✔ | ✔ |
| os_designate | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_glance | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_gnocchi | Newton | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_heat | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_horizon | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_ironic | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_keystone | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_magnum | Newton | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_manila | Stein | 完整 | ✔ | ✘ | ✘ |
| os_masakari | Stein | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_neutron | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_nova | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_octavia | Pike | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_rally | Newton | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_skyline | 2024.1 | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_swift | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_tacker | Queens | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✘ |
| os_tempest | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| os_trove | Ocata | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✘ |
| os_zun | Rocky | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| pki | Wallaby | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| 插件 | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| rabbitmq_server | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| repo_server | Mitaka | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| uwsgi | Train | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
| zookeeper | Zed | 一个角色可以是以下四个成熟度级别之一 | ✔ | ✔ | ✔ |
已退役的角色
| 角色名称 | 在周期期间创建 | 本周期内退役 |
|---|---|---|
| galera_client | Mitaka | Ussuri |
| openstack-ansible-security | Liberty | Pike |
| pip_lock_down | Liberty | Newton |
| repo_build | Mitaka | Ussuri |
| rsyslog_client | Mitaka | Zed |
| rsyslog_server | Mitaka | Zed |
| pip_install | Mitaka | Ussuri |
| os_almanach | Queens | Train |
| os_congress | 未知 | Ussuri |
| os_murano | Train | 2024.1 |
| os_monasca | Ocata | Train |
| os_monasca-agent | Ocata | Train |
| os_monasca-ui | Ocata | Train |
| os_molteniron | Pike | Train |
| os_sahara | Newton | 2024.1 |
| os_searchlight | Queens | Train |
| os_senlin | Ussuri | 2024.1 |
| os_watcher | Queens | Train |
| os_panko | Rocky | Xena |
| os_zaqar | Queens | Train |
