门限拆分¶

日期:: 2015-09-07 12:00
标签:: 门限，米塔卡

当前集成门限检查依赖于一个一体化 (AIO) 构建，该构建资源不足，并且不能充分测试项目主要用例所需的所有代码路径。

本规范概述了一个提案，即切换到使用多个门限检查，这些检查侧重于测试多个代码路径，从而更好地反映主要用例。

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

问题描述¶

当前的 AIO 门限检查

受到 OpenStack-CI 每个实例 8 vCPU、8GB RAM 可用资源严重限制。虽然这对于基本的开发者测试来说是足够的，但它并不能充分反映生产环境中的部署方式。
OpenStack-CI 目前仅提供单节点和双节点门限检查，并且明确要求尽可能使用单节点检查，然后再实施双节点检查。
无法提供足够的代码路径覆盖。它没有测试 Glance/Cinder 的 Ceph 客户端配置，Glance/Cinder 的 NFS 客户端配置，独立的 Swift 部署，或没有 Swift 的部署。
试图在一个单体测试中测试尽可能多的内容，使得检查难以理解、维护和诊断故障。
失败过于频繁。在 https://review.openstack.org/221957 中测试的减少容器亲和力表明，资源限制很可能是 OpenStack-CI 的 HP Cloud 提供商中常规 tempest 测试失败的主要原因。

提议的变更¶

使用 AIO 实现 OpenStack 的各个用例的独立门限检查

使用 NFS 备份的镜像和块存储服务的计算。这是具有现有存储硬件投资的环境中一种非常常用的部署设计。此 AIO 将使用以下特性构建：- 主机上的 NFS 服务 - 主机上的计算服务 - 主机上的 HAproxy 服务 - 配置为使用 NFS 服务的容器中的 Cinder - 配置为使用 NFS 服务的容器中的 Glance - Keystone、Horizon、Galera、Repo、RabbitMQ 容器的单亲和性 - Ceilometer 和 Neutron 部署方式与当前 AIO 相同
使用 Ceph 备份的镜像和块存储服务的计算。这种设计正变得越来越流行。此 AIO 将使用以下特性构建：- 主机上的计算服务 - 主机上的 HAProxy 服务 - 在三个容器中运行的简单 Ceph 集群 - 配置为使用 Ceph 服务的容器中的 Cinder - 配置为使用 Ceph 服务的容器中的 Glance - Keystone、Horizon、Galera、Repo、RabbitMQ 容器的单亲和性 - Ceilometer 和 Neutron 部署方式与当前 AIO 相同
带有 Keystone 的对象存储。这是典型的“独立 Swift”设计。为了使用通用基础设施，我们可以将 Glance 添加到此设计中，以验证 Glance 与 Swift 后端是否仍然正常工作。此 AIO 将使用以下特性构建：- 主机上的 HAProxy 服务 - 主机上的 Swift 账户、容器和对象存储 - 配置为使用 Swift 作为后端的容器中的 Glance - Keystone、Galera、Repo、RabbitMQ 容器的单亲和性 - Ceilometer 部署方式与当前 AIO 相同
仅 Keystone。这是用于验证三个 Keystone 服务器的代码路径的特定门限测试。此 AIO 将使用以下特性构建：- 主机上的 HAProxy 服务 - 3 个 Keystone 容器 - Galera、Repo、RabbitMQ 容器的单亲和性
带有 LDAP 的 Keystone。这是用于验证带有 LDAP 后端的 Keystone 代码路径的特定门限测试。此 AIO 将使用以下特性构建：- 主机上的 HAProxy 服务 - 主机上的 OpenLDAP - 3 个 Keystone 容器 - Galera、Repo、RabbitMQ 容器的单亲和性
带有 SSL 的 Keystone。这是用于验证启用 SSL 的 Keystone 代码路径的特定门限测试。此 AIO 将使用以下特性构建：- 主机上的 HAProxy 服务 - 3 个 Keystone 容器，Keystone 的 Apache 上启用了 SSL - Galera、Repo、RabbitMQ 容器的单亲和性
高可用性 RabbitMQ 集群。这是为了测试集群的部署和可用性，并在经过一系列已知的故障场景后进行测试。测试本身的细节需要在一段时间内明确定义和实施，因此门限检查将从我们今天所拥有的内容开始 - 一个简单的测试，验证部署是否正常工作。AIO 将使用以下特性构建：- 三个 RabbitMQ 容器 - 用于执行测试的实用程序容器
高可用性 Galera 集群。这是为了测试集群的部署和可用性，并在经过一系列已知的故障场景后进行测试。测试本身的细节需要在一段时间内明确定义和实施，因此门限检查将从我们今天所拥有的内容开始 - 一个简单的测试，验证部署是否正常工作。AIO 将使用以下特性构建：- 主机上的 HAproxy 服务 - 三个 Galera 容器 - 用于执行测试的实用程序容器
仅 Repo。这是用于验证三个 Repo 服务器的代码路径并使其经过一系列已知故障场景的特定门限测试。测试本身的细节需要在一段时间内明确定义和实施，因此门限检查将从我们今天所拥有的内容开始 - 一个简单的测试，验证部署是否正常工作。此 AIO 将使用以下特性构建：- 主机上的 HAProxy 服务 - 3 个 Repo 容器 - 用于执行测试的实用程序容器

每个用例门限检查必须具有参考文档，涵盖设计、实施的配置以及对其执行的测试。

同时，将当前的 lint 检查（将 Ansible 语法和 lint 检查与 python pep8 检查结合）切换为以下检查，这些检查尽可能使用与其他项目相同的 OpenStack-CI 作业

bashate lint 检查 bash 脚本
pep8 lint 检查 python 脚本
Ansible 语法和 lint 检查 Ansible playbook 和 roles

备选方案¶

保留当前的门限检查不变。

Playbook/Role 影响¶

作为这项工作的一部分，不会更改 playbook 或 roles。

升级影响¶

n/a

安全影响¶

n/a

性能影响¶

n/a

最终用户影响¶

n/a

部署者影响¶

n/a

开发人员影响¶

将测试更多的代码路径。

依赖项¶

为了实现可变负载均衡配置，这项工作依赖于：https://blueprints.launchpad.net/openstack-ansible/+spec/role-haproxy-v2

实现¶

负责人¶

主要负责人: https://launchpad.net/~jesse-pretorius odyssey4me
其他贡献者: https://launchpad.net/~hughsaunders hughsaunders

工作项¶

对于每个用例

开发并记录设计。
实施一个非投票的实验性门限检查。
上传代码和文档以供审查，并使用“check experimental”来验证其功能。
将门限检查切换到正常的检查队列，并将其保持为非投票状态，以便进行最终的功能验证。
将门限检查切换为投票状态并将其添加到合并队列。

测试¶

请参阅“工作项目”。

文档影响¶

如提议的更改所示，每个门限检查都应正确记录，以便于参考和理解。

参考资料¶

无。

网关拆分