Triple CI 改进

https://blueprints.launchpad.net/tripleo/+spec/tripleo-juno-ci-improvements

Tripleo CI 目前令人头痛，我们在运行作业的可靠性和时间一致性方面都存在问题，本规范旨在解决我们一直面临的一些问题。

问题描述

开发者应该能够依赖 CI 及时地生成可靠的测试结果，并最大程度地减少误报，目前情况并非如此。迄今为止，Tripleo CI 的可靠性受到网络故障、网络资源可用性以及 CI 云可靠性的严重影响。本规范旨在解决我们一直看到的问题。

问题： hp1 的可靠性 (hp1_reliability)

在 hp1 云上运行的作业间歇性故障导致大量作业失败，有时甚至使该区域完全瘫痪。目前的想法是，这些问题的大部分根源在于 mellanox 驱动程序的问题。

问题： 网络资源访问不可靠 (net_reliability)

对各种网络资源的可靠访问一直不稳定，导致当任何一个网络资源不可用时，CI 都会中断。此外，下载这些资源的速度不一致也使得衡量 Tripleo 的整体速度改进变得困难。

问题： (system_health) 整个 CI 系统的健康状况不是

立即显而易见，问题通常会持续数小时（或偶尔数天）才能得到解决。

问题： (ci_run_times) Tripleo 开发测试耗时，

这会消耗 CI 资源和开发人员的时间，我们应尽可能减少运行开发测试所需的时间。

问题： (inefficient_usage) 用于运行 Tripleo 的硬件是一种有限的

资源，目前有一项规范是在 OpenStack 部署上运行开发测试[1]，这是以最有效的方式利用我们现有资源的最佳途径。我们还有许多选项可以探索，以帮助最大程度地减少资源浪费。

问题： (system_feedback) 我们的 CI 未提供有关趋势的反馈。

一个好的 CI 系统应该不仅仅是一个报告通过或失败的系统，我们应该获得有关指标的反馈，从而使我们能够观察退化，尽可能地利用基础设施已经提供的服务。这将使我们能够在 CI 开始退化时主动介入吗？

问题： (bug_frequency) 我们目前没有迹象表明哪些 CI

错误最常发生。这阻碍了使 CI 更可靠的努力。

问题： (test_coverage) 目前 CI 只测试了它应该测试的子集。

它应该。

提议的变更

为了解决我们一直看到的问题，需要进行多项更改，每项都列在此处（按优先级顺序）。

解决方案

  • 通过删除一个 overcloud 作业暂时缩减 CI（以便 rh1 有能力运行 CI Solo）。

  • 从配置中删除 hp1。

  • 对每个 hp1 主机运行老化测试，删除（或修复）出现故障的主机。老化测试应包括在与预期在该区域运行的负载相匹配的新部署云上运行 CI。任何故障率不应超过当前部署区域的故障率。

  • 在 hp1 上重新部署测试基础设施并使用 tempest 进行测试，此重新部署应使用我们的 tripleo 脚本完成，以便可以重复，并且我们确定 ci-overcloud 部署之间的一致性。

  • 将 hp1 重新放入 CI 并监控情况。

  • 添加回任何已删除的 CI 作业。

  • 确保在未来部署的区域中遵循老化/tempest 测试。

  • 应尝试处理已部署云上出现的问题，如果 48 小时后发现无法快速处理，则应暂时将其从 CI 基础设施中删除，并且在重新投入生产之前需要通过老化测试。

解决方案

  • 在每个区域部署 pypi.openstack.org 的镜像。

  • 在每个区域部署 Fedora 和 Ubuntu 软件包存储库的镜像。

  • 在每个区域部署 squid 并通过它缓存 http 流量，尽可能镜像应被视为我们的首选，但部署 squid 应该缓存任何未镜像的资源。

  • 镜像其他资源（例如 github.com、percona tarball 等）。

  • 添加到开发测试的任何新要求都应在添加要求之前使用缓存进行缓存。

解决方案

  • 使用 Icinga 监控我们的 CI 云和测试环境，监控应包括 ping、启动（并连接到）新实例、磁盘使用情况等……。

  • 监控 CI 测试结果，如果连续有“X”个相同类型的作业失败，则触发警报。使用 logstash 监控 CI 结果的示例可以在这里找到[5]。

一旦一致性不再是问题，我们将研究我们可以对 CI 作业速度进行的改进。

解决方案

  • 调查不安全的磁盘缓存策略是否会加快磁盘镜像创建速度，如果发现改进，则在生产 CI 中通过以下方式之一实现：

    • 在 ci 云虚拟机上运行“不安全”磁盘缓存策略（这将涉及通过 nova api 暴露此 libvirt 选项）。

    • 使用“eatmydata”来 noop 磁盘同步系统调用，目前 F20 没有打包，但我们可以尝试重新启动该进程[2]。

解决方案

  • 失败时放弃：向 zuul 添加一项功能（如果已存在则开启），以便一旦投票提交失败，就立即放弃特定提交队列中的所有作业。这将最大程度地减少运行我们已经知道必须重新检查的长时间运行作业的资源使用。

  • 在计算节点和测试环境主机中添加 collectl 元素将使我们能够找到瓶颈，并确定可以安全地超额承诺的地方（例如，我们可能会发现，在测试环境主机上大量超额承诺 CPU 是可行的）。

解决方案

  • 结合使用 logstash 和 graphite

    • 输出误报测试结果发生次数的图表。

    • 输出 CI 运行时间随时间变化的图表，以识别趋势。

    • 输出 CI 作业峰值内存使用量随时间变化的图表。

    • 输出 CI 镜像大小随时间变化的图表。

解决方案

  • 为了能够跟踪对我们伤害最大的误报，我们应该同意不使用“recheck no bug”，而是使用相关的 bug 号进行重新检查。向 Elastic recheck 添加已知 CI 问题的签名应该有助于提高这种做法的普及。

解决方案

  • 针对已部署的 overcloud 运行 tempest。

  • 通过升级到新镜像来测试我们的升级方案。最初，为了避免构建新镜像，我们可以就地编辑 overcloud qcow 镜像中的内容，以获取一组要升级的镜像[3]。

替代方案

  • 作为部署我们自己的发行版镜像的替代方案，我们可以直接指向一个已知可靠的镜像。作为长期解决方案，这是不可取的，因为我们仍然无法控制中断。

安全影响

无

其他最终用户影响

  • 不再使用“recheck no bug”会给开发人员带来调查作业失败原因的负担。

  • 增加测试覆盖率将增加作业运行的总时间。

性能影响

CI 的整体性能应该会提高。

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

derekh

其他贡献者

寻找志愿者…

工作项

  • hp1 升级到 trusty。

  • 潜在的 pypi 镜像。

  • Fedora 镜像。

  • Ubuntu 镜像。

  • 镜像其他非发行版资源。

  • 每个区域的缓存代理。

  • 文档 CI。

  • 在 overcloud 节点中运行不安全的磁盘缓存策略。

  • ZUUL 失败时放弃。

  • 在计算和测试环境主机上包含 collectl 并分析输出。

  • 监控 CI 运行时间的机制。

  • 监控 nodepool 连接实例失败的机制。

  • 取消“recheck no bug”功能，或者至少不鼓励使用它。

  • 监控云/测试环境健康状况。

  • 扩展 CI 以包含 tempest。

  • 扩展 CI 以包含升级。

依赖项

无

测试

将跟踪 CI 故障率和时间，以确认改进。

文档影响

tripleo-ci 存储库需要额外的文档来描述当前的布局，然后应随着更改进行更新。

参考资料