跳转到: 导航, 搜索

Manila/docs/HOWTO use tempest with manila

< Manila‎ | docs

警告:由于 tempest 和 manila_tempest_tests 的变化,此页面上的信息可能已过时。请参阅此处提供的开发人员文档:https://docs.openstack.org/manila/ocata/devref/tempest_tests.html


目录

前言

本页描述了如何使用 Tempest 项目进行 Manila 项目测试。

假设阅读此内容的用户至少熟悉 Tempest 的常见信息

https://docs.openstack.org/developer/tempest/
https://github.com/openstack/tempest

自 Liberty 版本发布以来,Manila 正在使用本文档中记录的 tempest 插件

https://docs.openstack.org/developer/tempest/plugin.html

此外,假设以下项目已安装在测试环境中:

- cinder
- glance
- keystone
- manila
- neutron
- nova

Manila 的 Tempest 测试位于哪里?

Manila 在其 repo 中存储 Tempest 的测试,位于此处

https://github.com/openstack/manila/tree/master/manila_tempest_tests

由于 Manila 正在使用 Tempest 插件机制,所有测试都通过运行 setup.py 自动注册。如果使用 devstack,只需启用 Manila devstack 插件即可。

可以通过浏览 Tempest 源代码目录并执行以下命令来列出所有 Manila 测试

 testr list-tests | grep manila_tempest_tests

要查看插件是否已正确注册,可以运行

 echo 'import pkg_resources; print list(pkg_resources.iter_entry_points("tempest.test_plugins"))' | python

配置 Tempest 前运行测试

使用 Tempest 运行任何测试都需要更新 Tempest 的配置文件,该文件位于

etc/tempest.conf

如果安装了 tempest 插件,可以使用以下命令生成所有配置选项

oslo-config-generator --config-file tools/config/config-generator.tempest.conf

只需复制模板 "tempest.conf.sample" 并配置所需的选项即可

cp tempest.conf.sample tempest.conf

以下子部分描述了可以在 Tempest 配置文件中更新的部分和选项。

集群相关的通用选项

Manila 测试所需的选项如下所述。

Section "cli"

Option "enabled"

将其设置为

True

值,以便能够运行 Manila cli 测试。

Section "identity"

Option "uri"

如果使用 localhost,它应该如下所示:

http://127.0.0.1:5000/v2.0/

用于所有测试,如果启用了 v2 身份验证。

Option "uri_v3"

如果使用 localhost,它应该如下所示:

http://127.0.0.1:5000/v3/

Option "username"

如果使用 devstack 安装,它应该具有以下值:

demo

Option "password"

如果使用 devstack 安装,它应该具有以下值:

secrete

可以重新定义密码,只需在此处放置 'demo' 用户的密码即可。

Option "tenant_name"

如果使用 devstack 安装,它应该具有以下值:

demo

Option "alt_username"

如果使用 devstack 安装,它应该具有以下值:

alt_demo

Option "alt_password"

如果使用 devstack 安装,它应该具有以下值:

secrete

可以重新定义密码,只需在此处放置 'alt_demo' 用户的密码即可。

Option "alt_tenant_name"

如果使用 devstack 安装,它应该具有以下值:

alt_demo

Option "admin_username"

如果使用 devstack 安装,它应该具有以下值:

admin

Option "admin_password"

如果使用 devstack 安装,它应该具有以下值:

secrete

可以重新定义密码,只需在此处放置 'admin' 用户的密码即可。

Option "admin_tenant_name"

如果使用 devstack 安装,它应该具有以下值:

admin

Section "network"

Option "public_network_id"

此选项用于创建隔离的租户。其值可以从

$ neutron net-list

Option "public_router_id"

此选项用于创建隔离的租户。其值可以从

$ neutron router-list

Manila 相关的选项

Section "service_available"

此部分在 vanila Tempest 中定义。但是 "manila" 选项在 Manila 的扩展中定义。

Option "manila"

typeː boolean
default valueː True
descriptionː Whether or not manila is expected to be available

Section "share"

此部分使用 Manila 的扩展定义。

Option "catalog_type"

typeː str
default valueː share
descriptionː Catalog type of the Share service. Should be changed only if it is changed in Manila itself.

Option "endpoint_type"

typeː str
default valueː publicURL
descriptionː The endpoint type to use for the share service. Expected values are 'public', 'admin', 'internal', 'publicURL', 'adminURL' and 'internalURL'.

Option "multitenancy_enabled"

typeː boolean
default valueː True
descriptionː This option is used to determine backend driver type, multitenant driver uses share-networks, but single-tenant doesn't.
Current singletenant drivers: LVM, GlusterFS, NetApp 7-mode
Current multitenant drivers: Generic, NetApp Cluster-mode (cmode)
Default driver in manila is Generic driver, so "multitenancy_enabled" option is enabled by default.

Option "enable_protocols"

typeː list
default valueː nfs,cifs
descriptionː The first value of the list is protocol by default, items of the list show enabled protocols.
Expected values are:
nfs - will be tested only NFS type of shares and common actions
cifs - will be tested only CIFS type of shares and common actions
nfs,cifs - will be tested both share types and common actions, for common actions will be used nfs protocol
cifs,nfs - will be tested both share types and common actions, for common actions will be used cifs protocol

Option "enable_ip_rules_for_protocols"

typeː list
default valueː nfs,cifs
descriptionː Whether allow running of ip rules tests or not, and which share protocols should be used.
Expected values are:
nfs - sid rules will be tested only for nfs protocol
cifs - sid rules will be tested only for cifs protocol
nfs,cifs - sid rules will be tested with both share protocols
cifs,nfs - sid rules will be tested with both share protocols

Option "enable_sid_rules_for_protocols"

typeː list
default valueː (empty)
descriptionː Whether allow running of sid (username/usergroup) rules tests or not, and which share protocols should be used.
Expected values are:
nfs - sid rules will be tested only for nfs protocol
cifs - sid rules will be tested only for cifs protocol
nfs,cifs - sid rules will be tested with both share protocols
cifs,nfs - sid rules will be tested with both share protocols

Option "username_for_user_rules"

typeː str
default valueː Administrator
descriptionː What name should be used with user rule tests? Specify it if 'user rule' tests are enabled.

Option "storage_protocol"

typeː str
default valueː "" (empty)
descriptionː If you want Tempest to use some specific share-network instead of autocreated, specify it. This value is used for member creds.

Option "share_network_id"

typeː str
default valueː "" (empty)
descriptionː If you want Tempest to use some specific share-network instead of autocreated, specify it. This value is used for member creds.

Option "alt_share_network_id"

typeː str
default valueː "" (empty)
descriptionː If you want Tempest to use some specific share-network instead of autocreated, specify it. This value is used for alternative member creds. At the moment there are no tests, that use share_network with creds for alternative user.

Option "admin_share_network_id"

typeː str
default valueː 
descriptionː If you want Tempest to use some specific share-network instead of autocreated, specify it. This value is used for admin creds.

Option "multi_backend"

typeː boolean
default valueː False
descriptionː Does your environment has more than 1 backend or not? If yes, than you can set it to True to enable multibackend tests in tempest.

Option "backend_names"

typeː list
default valueː (empty)
descriptionː names of backends in Manila, that Tempest should use. Tempest will use first two values from list and will use it only if option "multi_backend" is Enabled.

Option "build_interval"

typeː int
default valueː 3
descriptionː time to wait between resend of requests.

Option "build_timeout"

typeː int
default valueː 500
descriptionː time to wait until raise of Exception with timeout.

如何运行测试

仅运行 cli 测试

tox -evenv bash tools/pretty_tox.sh \"tempest.cli.*manila*\"

仅运行 api 测试

tox -evenv bash tools/pretty_tox.sh \"tempest.api.share*\"

仅运行 api 和 cli 测试

tox -evenv bash tools/pretty_tox.sh \"tempest.api.share* tempest.cli.*manila*\"

仅运行 api 和 cli 测试,并指定线程数

export TEMPEST_CONCURRENCY=4
tox -evenv bash tools/pretty_tox.sh \"tempest.api.share* tempest.cli.*manila* -- --concurrency=$TEMPEST_CONCURRENCY\"

上述操作将尝试在 4 个线程中运行 Tempest,如果您的主机至少有 4 个核心。默认情况下,它使用等于可用核心数的线程数。

Manila 测试可以使用并发线程。

如果测试启动出现问题

在测试收集和解析的步骤中可能会引发异常,结果我们将看到类似以下内容:

running testr
Non-zero exit code (2) from test listing. stdout='\xb3)\x01@d@Ytempest.api.share.admin.test_admin_actions.AdminActionsTest.test_force_delete_share[gate]<Z\x90"\xb3)\x01@g@\\
...
tempest.scenario.test_volume_boot_pattern6B\x1e\xcc', stderr=None
error: testr failed (3)
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \
OS_TEST_LOCK_PATH=${OS_TEST_LOCK_PATH:-${TMPDIR:-'/tmp'}} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./tempest/test_discover} --list 

======
Totals
======
Run: 0 in 0.0 sec.
 - Passed: 0
 - Skipped: 0
 - Failed: 0
ERROR: InvocationError: '/bin/bash tools/pretty_tox.sh tempest/api/share/test_extensions.py'
__________________________________________________________________________________________________________________ summary ___________________________________________________________________________________________________________________
ERROR:   venv: commands failed

可能有不同的原因导致这种情况,在大多数情况下 - 依赖性问题,当某些依赖项未安装并且无法导入时。或者 python 语法错误,如果代码中发生更改等...

正如我们所见,它并没有向我们展示真正的问题,我们需要深入挖掘根本原因。可以通过很多方式来完成,例如,尝试下一步:

nosetests -sv path/to/tests

或者

.tox/venv/bin/python -m testtools.run discover -t ./ path/to/tests

或者

testr run path/to/tests

如何编写自己的测试

将新测试放在哪里

所有涵盖 admin API 的测试都存储在

tempest/api/share/admin/*

所有涵盖非 admin API 的测试都存储在

tempest/api/share/*

将方法作为 API 调用者添加

所有这些方法都存储在

tempest/services/share/json/shares_client.py

XML 被认为已弃用,并且已删除用于它的测试,因此,仅预期 json "client"。

Positive/Negative

正向和负向测试被分成不同的模块,带有 "_negative" 后缀的模块用于负向测试。正向测试模块的示例:

tempest/api/share/test_shares.py

负向测试模块的示例:

tempest/api/share/test_shares_negative.py

解决并发问题

如果某些测试对其他测试可以进行的更改敏感,则此测试应使用隔离的租户,可以在配额测试中找到示例,位于

tempest/api/share/admin/test_quotas.py

重用资源

如果多个测试具有相同的依赖项,如果可能,它们应使用相同的资源,可以在 "setUpClass" 方法中创建。示例可以在此处找到:

tempest/api/share/test_shares_actions.py

资源利用率

利用率内容在以下模块中定义:

tempest/api/share/base.py

基本操作:

1) All setUpClass methods should be decorated with "@test.safe_setup" decorator.
Reasonː if we get Exception on some step in setUpClass, tearDownClass won't start. So, this decorator runs 'tearDownClass' in any case.
2) Create resources that should be deleted with methods from base class.
correctː self.create_share() - will add resources to deletion queue
incorrectː self.shares_client.create_share() - won't add resource to deletion queue

通用信息:

All resources in deletion queue will be deleted in LIFO sequence - "last in first out" or "last created first deleted".
There are two deletion queuesː
- runs after each test
- runs after each test-suite (class with tests)
Be attentive setting up it.