TEUTHOLOGY用户指南
测试-集成测试-简介
Ceph有两种类型的测试:[make check](https://docs . ceph . com/en/latest/dev/developer _ guide/tests-unit-tests/# make-check)测试和集成测试。当一个测试需要多台机器、root访问或者持续很长时间(例如，模拟一个真实的Ceph工作负载)时，它被认为是一个集成测试。集成测试被组织成“套件”，这些套件在[ceph/qa sub-directory](https://github . com/ceph/ceph/tree/master/QA)中定义，并使用teuthology-suite命令运行。
teuthology-suite命令是[teuthology framework](https://github . com/ceph/teuthology)的一部分。在接下来的几节中，我们试图从一个Ceph开发新手的角度来详细介绍这个框架。
TEUTHOLOGY使用包
了解这一事实的意义可能需要一些时间，但它非常重要。这意味着可以在多个平台上使用相同的软件包（RPM、DEB）进行自动化测试，这些软件包可以安装在运行这些平台的任何机器上。
Teuthology有一个支持的平台列表（截至2020年9月，该列表由“RHEL/CentOS 8”和“Ubuntu 18.04”组成）。它希望为这些平台提供预构建的Ceph包。Teuthology在机器上部署这些平台（裸机或云配置），在上面安装软件包，并在上面部署Ceph集群——所有这些都是测试所要求的。
夜间测试
Sepia实验室针对官方Ceph存储库（在 master开发分支和稳定分支上）定期进行大量集成测试。传统上，这些测试被称为“夜间测试”，因为Ceph核心开发人员过去生活和工作在同一个时区，从他们的角度来看，测试是通宵进行的。
夜间测试运行的结果发布在http://pulpito.ceph.com/在用户teuthology下。开发人员昵称出现在测试结果的URL和Pulpito仪表板的第一列中。结果也在ceph-qa邮件列表中报告.
测试优先级
简而言之：在teuthology-suite命令选项-p <N>中，将<N>的值设置为小于1000的数字。原因如下。
teuthology suite命令包含选项-p＜N＞。此选项指定提交到队列的作业的优先级。N的值越低，优先级越高。
N的默认值为1000。这是赋予夜间测试（夜宵）的相同优先级值。通常，夜间测试期间完成的测试量非常大，以至于夜间测试的全部数量在分配的运行时间内无法运行。
将N的值设置为低于1000，否则您的测试将不会优先于夜间测试。这意味着他们可能永远不会逃跑。
根据以下准则选择作业的优先级（N值）：
| 优先级 | 解释 |
|---|---|
| N < 10 | 如果天要塌下来，必须尽快运行一些测试组合，请使用此选项。 |
| 10 <= N < 50 | 如果您的测试是紧急的，并且阻碍了其他重要的开发，请使用此选项。 |
| 50 <= N < 75 | 如果您正在测试特定的功能/修复程序，并且运行的作业少于25个，请使用此选项。此范围也用于紧急释放测试。 |
| 75 <= N < 100 | 技术负责人定期安排具有此优先级的集成测试，以验证naster的拉取请求。 |
| 100 <= N < 150 | 此优先级用于点发布的QE验证。 |
| 150 <= N < 200 | 对于测试特定功能或修复的100个或更少的作业使用此优先级。结果将在24小时内揭晓。 |
| 200 <= N < 1000 | 将此优先级用于大型测试运行。结果将在大约一周内公布。 |
要查看teuthology-suite命令将触发多少作业，请使用--dry-run标志。如果对演练返回的作业数感到满意，请再次发出teuthology-suite命令，不使用--dry run，使用-p和适当的数字作为参数。
要跳过优先级检查，请使用--force-priority。考虑到其他开发人员运行测试的需要，并且仅在紧急情况下使用--force-priority。
套件清单
ceph/qa子目录的suites目录包含所有Ceph组件的所有集成测试。
| 组件 | 功能 |
|---|---|
| ceph-deploy | 使用Ceph-deploy（Ceph-deploy man page)安装Ceph集群 |
| dummy | 获得一台机器，什么都不做，然后返回成功(通常用于验证集成测试基础设施是否按预期工作) |
| fs | 测试使用内核和FUSE客户端挂载的cephfs，也使用多个mds。 |
| krbd | 测试RBD内核模块 |
| powercycle | 验证Ceph集群在机器断电并再次开机时的行为 |
| rados | 在各种压力条件下运行Ceph集群，包括OSD和MON |
| rbd | 使用实际的Ceph集群运行RBD测试，无论是否使用qemu |
| rgw | 使用实际的Ceph集群运行RGW测试 |
| smoke | 使用实际的Ceph集群运行Ceph API的测试 |
| teuthology | 验证teuthology可以运行集成测试，无论是否使用OpenStack |
| upgrade | 对于各种版本的Ceph，验证升级是否可以在不中断正在进行的工作负载的情况下进行（升级测试) |
TEUTHOLOGY描述
teuthology-describe已添加到teuthology框架以便于文档编制和更好地理解集成测试。
可以通过在用于定义测试的yaml文件中嵌入meta:注释来记录测试。结果见teuthology-describe用例
由于这是一个新特性，许多yaml文件还需要注释。鼓励开发人员提高文档的覆盖范围和质量。
如何运行集成测试
通常，Sepia实验室用于运行集成测试。但作为一名新的Ceph开发人员，您可能无法访问Sepia实验室. 然而，您可能能够在独立于[Sepia实验室]的环境中运行一些集成测试(https://wiki.sepia.ceph.com/doku.php) . 询问相关团队的成员如何做到这一点。
运行自己的集成测试的一种方法是在裸机上建立一个teuthology集群。在裸金属上建立一个teuthology集群是一项复杂的任务。以下是一些注释如果您决定有兴趣承担在裸机上建立teuthology集群的复杂任务，那么就开始吧。
对代码贡献运行集成测试并发布结果允许审阅者验证对代码库的更改不会导致回归，并允许审阅者在测试失败时进行分析。
每一个teuthology集群，无论是裸机还是云配置，都有一个所谓的“teuthology机器”，使用teuthology-suite命令从中触发测试套件。
每个teuthology-suite的详细和最新描述选项可通过在teuthology计算机上运行以下命令获得：
teuthology-suite --help
集成测试是如何定义的
集成测试由ceph/qa子目录的suites子目录中的yaml文件定义并由tasks子目录中的python代码实现。一些测试（“独立测试”）是在单个yaml文件中定义的，而其它测试是由包含yaml文件的目录树定义的，这些文件在运行时合并为一个更大的yaml文件。
读取独立测试
让我们首先考查一个独立的测试，或singleton。
下面是一个使用集成测试rados/singleton/all/admin-socket.yaml的注释示例
roles:
- - mon.a
- osd.0
- osd.1
tasks:
- install:
- ceph:
- admin_socket:
osd.0:
version:
git_version:
help:
config show:
config set filestore_dump_file /tmp/foo:
perf dump:
perf schema:
roles数组决定了设计在其上运行此测试的集群的组成（多少个MON、OSD等），以及这些角色将如何分布在测试集群中的计算机上。在这种情况下，顶级数组中只有一个元素：因此，只有一台机器被分配给测试。嵌套数组声明此计算机将运行id为a（即角色列表中的MON.a）的MON和两个osd（osd.0和osd.1）。
测试的主体位于tasks数组中：按顺序计算每个元素，从而在teuthology repository的task子目录中找到相应的python文件或要运行的ceph/qa子目录。在这种情况下，“运行”意味着调用该文件中定义的task()函数。
在这种情况下，install任务是第一位的。它在每台机器上安装Ceph包（由roles数组定义）。install任务的完整描述可在python文件中找到（搜索def task”）。
此处记录了ceph任务（再次搜索“def task”），根据roles数组的要求启动OSD和MON（可能还有MDSs）。在本例中，它将在同一台机器上启动一个MON（MON.a）和两个osd（osd.0和osd.1）。当Ceph集群达到HEALTH_OK状态时，控制移至下一个任务。
下一个任务是admin_socket（源代码). admin_socket任务（以及任何其他任务）的参数是一个结构，它被解释为在任务中记录。在本例中，参数是要发送到osd.0的管理套接字的一组命令。该任务将验证每个命令是否成功返回（即退出代码为零）。
此测试可以使用
teuthology-suite --machine-type smithi --suite rados/singleton/all/admin-socket.yaml fs/ext4.yaml
测试说明
每个测试都有一个“测试描述”，类似于目录路径，但不相同。对于独立测试，就像读取独立测试中的那样，测试描述与定义测试的yaml文件的相对路径(从ceph/qa子目录的suites/目录开始)相同。
更常见的是，测试不是由单个yaml文件定义的，而是由yaml文件的目录树定义的。在运行时，遍历树，并将所有yaml文件(facet)组合成定义测试的更大的yaml“程序”。在每个测试日志的开头都包含了定义测试的yaml的完整列表。
在这些情况下，每个测试的描述包括suites/下的子目录，其中包含yaml facet，后面是一个花括号({})中的表达式，该表达式由一个按连接顺序排列的yaml facet列表组成。例如测试描述:
ceph-deploy/basic/{distros/centos_7.0.yaml tasks/ceph-deploy.yaml}
表示两个文件的连接：
- ceph-deploy/basic/distros/centos_7.0.yaml
- ceph-deploy/basic/tasks/ceph-deploy.yaml
如何从目录构建测试
如前一节所述，大多数测试不是在单个yaml文件中定义的，而是从ceph/qa子目录的suites/子目录中的目录树中收集的文件的组合。
由suites/ 的给定子目录定义的所有测试集称为“集成测试套件”或“teuthology套件”。
yaml facet的组合由放置在目录树中的特殊文件（%和+）控制，可以将其视为运算符。%文件是“卷积”运算符，+表示串联。
CONVOLUTION OPERATOR
卷积运算符实现为一个名为%的(通常为空)文件，它告诉teuthology从包含运算符的目录下面的子目录中找到的yaml facet构造一个测试矩阵。
例如，ceph-deploy suite是由suites/ceph-deploy/ 树定义的，它由以下结构中的文件和子目录组成
qa/suites/ceph-deploy
├── %
├── distros
│ ├── centos_latest.yaml
│ └── ubuntu_latest.yaml
└── tasks
├── ceph-admin-commands.yaml
└── rbd_import_export.yaml
这被解释为由两个测试组成的2x1矩阵：
- ceph-deploy/basic/
- ceph-deploy/basic/
即centos7.0.yaml和ceph-deploy.yaml的级联以及ubuntu16.04.yaml和ceph-deploy.coml的级联。从人的角度来说，这意味着ceph-deploy.yaml中的任务将在CentOS 7.0和Ubuntu 16.04上运行。
如果没有文件%，ceph deploy树将被解释为三个独立测试：
- ceph-deploy/basic/distros/centos_7.0.yaml
- ceph-deploy/basic/distros/ubuntu_16.04.yaml
- ceph-deploy/basic/tasks/ceph-deploy.yaml
(在这种情况下这当然是错误的)。
参考ceph/qa子目录，您将注意到suites/ceph-deploy/basic/distros/目录中的centos_7.0.yaml和ubuntu16.04.yaml文件是作为符号链接实现的。通过使用符号链接而不是复制，单个文件可以出现在多个套件中。这简化了整个测试框架的维护。
所有从suites/ceph-deploy/目录树(也称为ceph-deploy套件)生成的测试都可以通过以下命令运行
teuthology-suite --machine-type smithi --suite ceph-deploy
ceph-deploy套件中的单独测试可以通过添加--filter选项来运行
teuthology-suite \
--machine-type smithi \
--suite ceph-deploy/basic \
--filter 'ceph-deploy/basic/{distros/ubuntu_16.04.yaml tasks/ceph-deploy.yaml}'
注
要运行像读取独立测试中那样的独立测试，仅
--suite就足够了。如果想从定义为目录树的套件中运行单个测试，--suite必须与--filter组合。这是因为--suite选项只理解POSIX相对路径。
嵌套子集
通过yaml配置的组合爆炸，套件可以变得相当大。在撰写本文时，rados套件有超过10万个作业。因此，调度通常使用--subset选项来仅运行作业的子集（另请参见：减少测试数量). 然而，这仅适用于正在运行的套件的顶层（例如fs）。这可能会使一些较大的子套件（如fs:workload）与较小但关键的套件（如：fs:volumes）的作业比例增加。
因此，自动子集化一些从未完全运行的子套件是很有吸引力的。这是通过为%卷积运算符文件提供一个整除数来实现的，而不是将其保留为空。该除数自动将结果矩阵子集化。例如，如果卷积文件%包含2，则使用与 --subset 机制相同的逻辑将矩阵分为两个。
请注意，分子没有像--subset 选项那样指定，因为当可能有几层嵌套时，没有任何有意义的方法来表达这一点。相反，选择了一个随机子集（在我们的示例中为2选1）。该选择基于用于调度的随机种子（--seed）。请记住，种子保存在结果中，这样失败测试的--rerun仍将保留正确的分子（子集的子集）。
可以使用teuthology-suite的--no-nested-subset参数禁用嵌套子集。
CONCATENATION OPERATOR
为了在套件之间更灵活地共享yaml文件，可以使用特殊的文件加号(+) 来连接目录中的文件。例如，考虑suites/rbd/thrash树
qa/suites/rbd/thrash
├── %
├── clusters
│ ├── +
│ ├── fixed-2.yaml
│ └── openstack.yaml
└── workloads
├── rbd_api_tests_copy_on_read.yaml
├── rbd_api_tests.yaml
└── rbd_fsx_rate_limit.yaml
这将创建两个测试:
- rbd/thrash/
- rbd/thrash/
因为 clusters/子目录包含特殊文件加号(+)，所以该子目录中的所有其他文件（在本例中为fixed-2.yaml和openstack.yaml ）都连接在一起，并作为单个文件处理。如果没有特殊文件加号 (+)，它们将与工作负载目录中的文件进行卷积，以创建2x2矩阵：
- rbd/thrash/
- rbd/thrash/
- rbd/thrash/
- rbd/thrash/
clusters/fixed-2.yaml 文件在许多套件中共享，以定义以下roles
roles:
- [mon.a, mon.c, osd.0, osd.1, osd.2, client.0]
- [mon.b, osd.3, osd.4, osd.5, client.1]
上面定义的rbd/thrash套件由两个测试组成，可以使用
teuthology-suite --machine-type smithi --suite rbd/thrash
通过添加--filter 选项，可以运行rbd/stutch套件中的单个测试
teuthology-suite \
--machine-type smithi \
--suite rbd/thrash \
--filter 'rbd/thrash/{clusters/fixed-2.yaml clusters/openstack.yaml workloads/rbd_api_tests_copy_on_read.yaml}'
升级测试
使用升级套件，我们能够验证从早期版本升级可以成功完成，而不会中断任何正在进行的工作负载。每个Release分支升级目录包括2-x升级测试。这意味着，我们能够测试从前两个版本到当前版本的升级。升级序列与其他给定的工作负载并行完成。
例如，Quincy发布分支的升级测试目录如下：
.
├── octopus-x
└── pacific-x
可以测试从Octopus（2-x）或从Pacific（1-x）到Quincy（x）的升级。简单的升级测试包括以下顺序：
├── 0-start.yaml
├── 1-tasks.yaml
├── upgrade-sequence.yaml
└── workload
在用旧版本启动集群之后，我们开始并行运行给定的 workload和upgrade-sequnce 。
- print: "**** done start parallel"
- parallel:
- workload
- upgrade-sequence
- print: "**** done end parallel"
与任何其他套件一样，workload目录包含常规yaml文件， upgrade-sequnce 负责运行升级并完成升级：
- print: "**** done start upgrade, wait"
...
mon.a:
- ceph orch upgrade start --image quay.ceph.io/ceph-ci/ceph:$sha1
- while ceph orch upgrade status | jq '.in_progress' | grep true ; do ceph orch ps ; ceph versions ; sleep 30 ; done\
...
- print: "**** done end upgrade, wait..."
也可以分阶段升级，同时在以下两个阶段之间运行工作负载：
├── %
├── 0-cluster
├── 1-ceph-install
├── 2-partial-upgrade
├── 3-thrash
├── 4-workload
├── 5-finish-upgrade.yaml
├── 6-quincy.yaml
└── 8-final-workload
启动集群后，我们只升级集群的2/3 (2-partial-upgrade)。下一阶段是运行冲击测试和给定的工作负载测试。稍后，继续升级集群的其余部分(5-finish-upgrade.yaml)。最后一个阶段是要求更新版本(ceph require-osd-release quincy， ceph osd set-require-min-compat-client quincy )并运行final-workload。
位置无关链接
在qa/suites 目录下，每个目录中都有.qa符号链接。通过始终链接到../.qa/，每个链接都是递归的。最后一个终止链接在 qa/ 目录中，本身为qa/.qa -> .。这种符号链接的布局允许在不中断多个符号链接的情况下轻松复制或移动套件。例如：
qa/suites/fs/upgrade/nofs/centos_latest.yaml -> .qa/distros/supported/centos_latest.yaml
如果将 nofs 套件复制到其他地方，在nofs 上方添加父目录，或将centos_latest.yaml片段移动到子目录中，链接将不会断开。比较对象：
qa/suites/fs/upgrade/nofs/centos_latest.yaml -> ../../../../distros/supported/centos_latest.yaml
如果链接被移动，它很可能会断开，因为到达distros 目录的父目录的数量可能会改变。
在添加新目录或套件时，建议还记得添加.qa符号链接。一个简单的find命令可以为您完成以下操作：
find qa/suites/ -type d -execdir ln -sfT ../.qa/ {}/.qa \;
按描述筛选测试
当一些作业失败并需要再次运行时，可以使用--filter选项选择具有匹配描述的测试。例如，如果“rados”套件未能通过all/peer.yaml测试，以下将仅运行包含此文件的测试
teuthology-suite --machine-type smithi --suite rados --filter all/peer.yaml
--filter-out选项的作用相反（它匹配不包含给定字符串的测试），并且可以与--filter选项组合使用。
--filter和--filter-out 都使用逗号分隔的字符串列表（这意味着在ceph/qa子目录中找到的文件名中不允许使用逗号字符）)。例如
teuthology-suite --machine-type smithi --suite rados --filter all/peer.yaml,all/rest-api.yaml
将运行包含all/peer.yaml或all/rest-api.yaml的测试
每个字符串都在测试描述中的任何位置查找，并且必须完全匹配：它们不是正则表达式。
减少测试次数
rados 套件从几百个文件中生成数万甚至数十万个测试。这是因为teuthology在遇到名为 %的文件时，都会从子目录中构造测试矩阵。例如，rados/basic套件中的所有测试使用不同的 messenger类型运行：simple、async和random，因为它们（通过特殊文件%）与msgr目录组合在一起
所有集成测试都需要在Ceph发布之前运行。当仅仅验证一个贡献是否可以合并而不冒着微不足道的回归风险时，运行一个子集就足够了。--subset选项可用于减少触发的测试数量。例如
teuthology-suite --machine-type smithi --suite rados --subset 0/4000
会尽量少做测试。这种情况下的权衡是，并不是所有测试变体的组合都会在一起，但无论--subset,中提供的比例有多小，teuthology仍然会确保套件中的所有文件至少在一个测试中。理解驱动它的实际逻辑需要阅读teuthology源代码。
注意：一些套件现在使用嵌套子集功能，该功能自动将子集应用于一组精心选择的YAML配置。可以使用 --no-nested-subset 选项禁用此行为（可能用于某些自定义筛选）。
--limit选项只运行套件中的前N 个测试：然而，这很少有用，因为无法控制哪个测试将是第一个。
使用TEUTHOLOGY工作流的集成测试
调度测试运行
获取二进制文件
必须为分支构建Ceph二进制文件，然后才能使用teuthology对其运行集成测试。按照以下步骤构建Ceph二进制文件：
-
将分支推到ceph-ci存储库。这触发了在Jenkins CI上构建二进制文件的过程。
-
为了确保构建过程已经启动，请确认分支名称已经出现在Shaman的“最新可用构建”列表中。在您开始构建过程后不久，测试基础设施将其他类似名称的构建添加到“最新可用构建”列表中。这些新构建的名称将包含Linux的各种Linux发行版的名称，并将用于针对这些Linux发行版测试构建。
-
等待软件包被构建并上传到Chacra，并等待创建提供包的存储库。Sharman上“可用的最新版本”列表中的分支名称条目将变为绿色，表示软件包已上传至Chacra并指示其存储库已创建。等待每个条目都显示为绿色。这通常需要两到三个小时，具体取决于机器的可用性。
可以从Chacra站点查询特定构建的Chacra URL.
注意
要在ceph-ci上推送的分支可以是任何分支。分支不必是PR分支。
注意
如果你打算推送master或任何其他标准分支，提前查看Shaman，因为它可能已经完成了构建。
触发测试
为分支构建Ceph二进制文件后，可以使用teuthology运行测试。此过程解释如何使用teuthology运行测试。
-
登录到teuthology计算机：
ssh <username>@teuthology.front.sepia.ceph.com这需要进入Sepia实验室。要请求访问Sepia实验室，请参阅:https://ceph.github.io/sepia/adding_users/
-
运行
teuthology-suite命令：上述命令中的选项定义如下：
选项 含义 -v 输出详细信息 -m 机器名称 -c ceph-ci上推送的分支的名称 -s 测试套件名称 -p 数字越高，作业的优先级越低 --filter 筛选给定套件中的测试。传递给此筛选器的参数指定要运行的测试 -e 当测试完成或超时时，向指定地址发送电子邮件。也可以在~/.teuthology.yaml中指定为“results_email” 注意
上面命令中的优先级数字是一个占位符。不要在自己的测试中使用它。有关推荐值的信息，请参见测试优先级。
注意
不要发出没有优先级数字的命令。默认值是1000，这个值太大了，作业不太可能运行。
运行
teuthology-suite --help来阅读这些选项和其他可用选项的描述。 -
等待测试运行。
teuthology-suite打印了一个到Pulpito的链接，可以在那里查看测试结果。
其他常用/有用的选项有 -d(或--distro)、--distroversion --filter-out、--timeout、flavor、-rerun、-l(用于限制作业数量)、-N (用于限制作业运行次数)和--subset(用于减少触发的测试数量)。运行 teuthology-suite --help来阅读这些选项和其他选项的描述。
测试QA更改（无需重新构建二进制文件）
如果只在qa/目录中进行更改，则在重新运行测试之前不必重新生成二进制文件。如果只在qa/中进行更改，则可以使用为ceph-ci分支构建的二进制文件重新运行测试。您只需确保告诉teuthology-suite 令使用单独的分支来运行测试。
如果仅在qa/ (https://github.com/ceph/ceph/tree/master/qa)中进行了更改，不需要重新生成二进制文件。可以使用为主分支和其他稳定分支定期构建的现有二进制文件，并针对它们运行测试更改。可以通过向teuthology-suite命令传递两个额外的参数来测试具有qa更改的分支：（1） --suite-repo，指定ceph repo；（2）--suite-branch，指定分支名称。
例如，如果想在测试branch-x(其中ceph-ci分支为 wip-username-branch-x)后对qa/进行更改，则运行以下命令
teuthology-suite -v \
-m smithi \
-c wip-username-branch-x \
-s fs \
-p 50 \
--filter cephfs-shell
然后在本地进行修改，更新PR分支，并从PR分支触发测试，如下所示:
teuthology-suite -v \
-m smithi \
-c wip-username-branch-x \
-s fs -p 50 \
--filter cephfs-shell \
--suite-repo https://github.com/$username/ceph \
--suite-branch branch-x
可以通过查看teuthology作业开始时打印的作业配置中suite_branch、suite_repo和 suite_sha1键的值来验证测试是使用该分支运行的。
注意
如果正在进行不在
qa/目录中的更改，则必须遵循触发构建的标准流程，等待构建完成，然后触发测试并等待测试结果。
关于套件和筛选器
有关可用的集成测试套件的列表，请参见套件清单。Ceph存储库中qa/suites下的每个目录都是一个集成测试套件，在那里可以找到-s后面合适的参数。
用于过滤测试的关键字可以在qa/suites/<suite-name>/<subsuite-name>/tasks 中找到，并且可以用作 --filter的参数。该目录中的每个YAML文件都可以触发测试;使用不带文件名扩展名的文件名作为 --filter的参数会触发这些测试。
例如，在测试QA更改部分的上面命令中，指定了cephfs-shell 。这是因为在qa/suites/fs/basic_functional/tasks/中有一个名为cephfs-shell.yaml的文件。
如果文件名没有显示它触发的测试类型，请在文件内容中搜索modules属性。对于 cephfs-shell.yaml，modules属性为tasks.cephfs.test_cephfs_shell。这意味着它将触发 qa/tasks/cephfs/test_cephfs_shell.py中的所有测试。
查看测试结果
PULPITO仪表板
在安排了teuthology作业之后，可以在https://pulpito.ceph.com/上检查测试运行的状态和结果。
TEUTHOLOGY存档
在测试完成运行后，可以通过单击与测试关联的Pulpito页面上的作业ID来获得作业的日志。下载日志然后查看比在互联网浏览器中查看更方便，因为这些日志的大小可以轻松达到1gb。ssh进入teuthology机器(teuthology.front.sepia.ceph.com)并访问以下路径更容易:
/ceph/teuthology-archive/<test-id>/<job-id>/teuthology.log
例如:对于上面的测试ID，路径为:
/ceph/teuthology-archive/teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi/4588482/teuthology.log
使用此方法可以比通过浏览器更快地查看日志。
注意
为了更方便地访问档案，
/a/被象征性地链接到/ceph/teuthology-archive/。例如，要访问前面的例子，我们可以使用如下代码:/a/teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi/4588482/teuthology.log
终止测试
teuthology-kill 可以用来终止意外运行了几个小时的作业，或者当开发人员想要在测试完成之前终止测试时。
下面是终止作业的命令:
teuthology-kill -r teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi
让我们把传递给 -r 的参数称为测试ID。可以很容易地在到Pulpito页面的链接中找到您触发的测试。例如，对于上面的测试ID，链接是- http://pulpito.front.sepia.ceph.com/teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi/
重新运行测试
The teuthology-suite command has a -r (or --rerun) option, which allows you to re-run tests. This is handy when your tests have failed or end up dead. The --rerun option takes the name of a teuthology run as an argument. Option -R (or --rerun-statuses) can be passed along with -r to choose which kind of tests should be picked from the run. For example, you can re-run only those tests from previous run which had ended up as dead. Following is a practical example:
teuthology-suite命令有一个 -r(或 --rerun)选项，允许重新运行测试。当测试失败或最终失败时，这很方便。 --rerun选项以teuthology运行的名称作为参数。选项-R(或--rerun-statuses)可以与 -r一起传递，以选择应该从运行中选择哪种类型的测试。例如，可以只重新运行上次运行中失效的那些测试。下面是一个实际的例子:
teuthology-suite -v \
-m smithi \
-c wip-rishabh-fs-test_cephfs_shell-fix \
-p 50 \
-r teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi \
-R fail,dead,queued \
-e $CEPH_QA_MAIL
以下是本节介绍的新选项的定义：
选项 含义 -r, --rerun 尝试重新安排运行，只选择那些状态由--rerun-status提到的作业。 -R, --rerun-statuses 要与--reun一起使用的状态的逗号分隔列表。支持的状态：‘dead’, ‘fail’, ‘pass’, ‘queued’, ‘running’ 和 ‘waiting’。默认值：“fail，dead”
命名CEPH-CI分支
在将分支推到ceph-ci之前，预先添加您的名称。例如，一个名为feature-x 的分支应该命名为wip-$yourname-feature-x，其$yourname 被替换为你的名字。用你的名字来标识你的分支可以让你的分支在Shaman和Pulpito上很容易被找到。
如果您正在使用一个稳定的分支(quincy, pacific等)，请在ceph-ci分支名称中包含该稳定分支的名称。例如， feature-xPR分支应该命名为wip-feature-x-nautilus。这不仅仅是一个惯例。这将确保您的分支构建在正确的环境中
当不再需要时，从ceph-ci中删除该分支。如果登录到GitHub，在ceph-ci上的所有分支都可以在这里找到:https://github.com/ceph/ceph-ci/branches。
分析和调试TEUTHOLOGY作业
要了解关于如何调度集成测试的更多信息，请参阅调度测试运行。
查看测试结果
当成功完成一次teuthology运行后，使用pulpito的仪表盘查看结果：
http://pulpito.front.sepia.ceph.com/<job-name>/<job-id>/
或者SSH到teuthology服务器查看集成测试的结果:
ssh <username>@teuthology.front.sepia.ceph.com
访问teuthology archives，如下例所示:
nano /a/teuthology-2021-01-06_07:01:02-rados-master-distro-basic-smithi/
注意
这需要访问Sepia实验室。要了解如何请求访问Sepia实验，请参阅：https://ceph.github.io/sepia/adding_users/
识别失败的作业
在pulpito上，红色的作业要么是失败的作业，要么是死亡的作业。job是qa/suites中yaml片段中定义的守护进程和配置的组合。Teuthology使用这些配置并运行qa/tasks中列出的任务，这些任务是设置测试环境和测试Ceph组件的命令。这些任务涵盖了大量的用例子集，并帮助暴露make check测试未暴露的错误。
作业失败可能是由以下一个或多个原因引起的:
-
环境设置（在不同系统上测试)：测试与受支持版本的稳定版本的兼容性。
-
配置值的排列：例如qa/suites/rados/thrash确保我们在压力较大的工作负载下对Ceph运行抖动测试，以便我们能够捕捉到角落的bug。用于测试的最终设置配置yaml文件可以在以下位置访问：
/a/<job-name>/<job-id>/orig.config.yaml
关于配置的更多详细信息。Yaml可以在详细的测试配置上找到
分析失败的原因
当作业失败时，您需要阅读它的teuthology日志，以确定其失败的原因。使用papito中的作业名称和id查找失败作业的teuthology日志：
http://qa-proxy.ceph.com/<job-name>/<job-id>/teuthology.log
打开日志文件：
/a/<job-name>/<job-id>/teuthology.log
例如：
nano /a/teuthology-2021-01-06_07:01:02-rados-master-distro-basic-smithi/5759282/teuthology.log
每个作业失败都会记录在teuthology日志中作为Traceback，并添加到作业摘要中。
查找Traceback关键字，并在调用堆栈和日志中搜索导致失败的问题。通常，Traceback将包括失败的命令。
注意
teuthology日志会不时被删除。如果您无法访问本例中的链接，请使用http://pulpito.front.sepia.ceph.com/中的任何其他情况
报告问题
简而言之：首先检查一下你的作业失败是否是由已知问题引起的，如果不是，提出跟踪罚单。
After you have triaged the cause of the failure and you have determined that it wasn’t caused by the changes that you made to the code, this might indicate that you have encountered a known failure in the upstream branch (in the example we’re considering in this section, the upstream branch is “octopus”). If the failure was not caused by the changes you made to the code, go to https://tracker.ceph.com and look for tracker issues related to the failure by using keywords spotted in the failure under investigation.
在对失败的原因进行了分析并确定它不是由您对代码所做的更改引起的之后，这可能表明在上游分支中遇到了已知的失败（在本节中我们正在考虑的示例中，上游分支是“octopus”）。如果故障不是由您对代码所做的更改引起的，请转到https://tracker.ceph.com并使用调查中的故障中发现的关键字查找与故障相关的跟踪问题。
If you find a similar issue on https://tracker.ceph.com, leave a comment on that issue explaining the failure as you understand it and make sure to include a link to your recent test run. If you don’t find a similar issue, create a new tracker ticket for this issue and explain the cause of your job’s failure as thoroughly as you can. If you’re not sure what caused the job’s failure, ask one of the team members for help.
如果您在https://tracker.ceph.com上发现了类似的问题，请在该问题上留下评论，解释您所理解的失败，并确保包含您最近测试运行的链接。如果您没有发现类似的问题，请为此问题创建一个新的跟踪记录，并尽可能详细地解释作业失败的原因。如果你不确定作业失败的原因，向团队成员寻求帮助。
使用INTERACTIVE-ON-ERROR调试问题
当在测试期间遇到作业失败时，应该尝试重现它。这就是 --interactive-on-error 的用武之地。本节解释如何使用 interactive-on-error 以及它的作用。
当你验证了一个作业失败后，在teuthology中再次运行相同的作业，但添加interactive-on-error标志:
ideepika@teuthology:~/teuthology$ ./virtualenv/bin/teuthology -v --lock --block $<your-config-yaml> --interactive-on-error
使用custom config.yaml或失败作业中的yaml文件。如果使用失败作业中的yaml文件，则复制orig.config.yaml 到本地目录:
ideepika@teuthology:~/teuthology$ cp /a/teuthology-2021-01-06_07:01:02-rados-master-distro-basic-smithi/5759282/orig.config.yaml test.yaml
ideepika@teuthology:~/teuthology$ ./virtualenv/bin/teuthology -v --lock --block test.yaml --interactive-on-error
如果在使用 interactive-on-error标志时作业失败，teuthology将锁定config.yaml所需的机器。Teuthology将停止测试机器，并将它们保持在作业失败时的状态。将进入一个交互式python会话。从那里，您可以通过ssh登录到系统，以调查作业失败的原因。
在调查了故障之后，只需终止会话。Teuthology将清理会话并解锁机器。
建议的资源
用于内核开发的集成测试
CEPHFS
fs套件运行内核YAML片段中描述的各种内核. 这些都由 fs套件下的其他子套件象征性地链接。
片段矩阵允许测试以下配置：
-
RHEL 8上的“stock”内核(即附带的内核)。
-
内核开发团队的测试分支，它代表正在进行积极测试的补丁。这些补丁可能会出现在下一个上游内核发行版中，也可能不会出现，并且会混合包含CephFS或kRBD更改。对于测试内核，我们使用子套件指定的任何发行版进行测试。例如，
fs:functional子套件使用支持的随机发行版的随机选择。
测试自定义内核
如果在ceph-client.git上有一个内核分支，并且使用shaman构建了它，那么您也可以通过指定对内核的重写轻松地进行测试。这是通过传递给teuthology-suite命令的YAML片段完成的:
$ cat custom-kernel.yaml
overrides:
kernel:
branch: for-linus
这为套件矩阵中指定的内核分支指定了覆盖。还可以将覆盖指定为“内核”任务的标记或SHA1。当覆盖内核时，应该减少对作业的选择，因为矩阵将包括许多您不想测试的内核配置，如[ChefFS](https://docs.ceph.com/en/latest/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-kernel/#kernel-cephfs）中所述部分；重写YAML将应用于内核的所有配置，因此将导致重复测试。运行测试的命令如下所示：
teuthology-suite ... --suite fs --filter k-testing custom-kernel.yaml
其中... 指示运行 teuthology-suite时通常指定的其他典型选项。重要的过滤器--filter k-testing将限制对使用内核testing 分支的作业的选择（参见k-testing.yaml文件）。因此，只能使用带有“测试”分支的内核客户端来选择作业。自定义YAML文件custom-kernel.yaml将进一步覆盖testing分支以使用您指定的任何内容。
浙公网安备 33010602011771号