14.11.2022 13:46
rikki_tikki 0 292 Источник

Tempest — это официальный компонент OpenStack для интеграционного тестирования. Tempest поддерживает три вида тестов: API, сценарии (scenario) и стресс-тесты (stress). API-тесты проверяют функциональность API. Сценарии имитируют сложные многоэтапные операции. Стресс-тесты запускают задания параллельно для тестирования высокой нагрузки. Tempest использует собственную реализацию клиента вместо стандартных клиентов Python, поэтому может отправлять фейковые или некорректные запросы для проверки реализации API.

Настройка Tempest довольно сложна вследствие не совсем понятной документации. И некоторые проблемы могут быть вызваны не конфигурацией Tempest, а настройкой вашего облака. К счастью, есть несколько инструментов, которые помогают в использовании Tempest. В серии статей мы покажем, как запустить Tempest автономно и с помощью дополнительных инструментов.

В этой статье рассмотрим использование клиента RefStack для запуска тестов Tempest. RefStack — это инструмент, разработанный для запуска тестов DefCore. DefCore — это набор требований, которым должно удовлетворять облако OpenStack, чтобы быть сертифицированным OpenStack Foundation. На момент написания статьи последняя версия тестов 2016.01, состоящая из 306 тестов. Tempest находится в активной разработке, и если вы посмотрите ветку master у Tempest, то увидите, что 10 из 306 тестов больше не актуальны.

Установка refstack-client очень проста и описана в этом документе. Если вкратце, то нужно выполнить пять шагов:

  1. Скачать исходный код: 

git clone https://git.openstack.org/openstack/refstack-client

  1. Установить в локальное виртуальное окружение: 

./setup_env

  1. Скачать тесты 2016.01:

https://refstack.openstack.org/api/v1/guidelines/2016.01/tests?type=required

  1. Запустить тесты: 

./refstack-client test -c ~/tempest.conf --test-list test-list-file-name

  1. Загрузить результаты теста на refstack.openstack.org (опционально):

./refstack-client upload .tempest/.testrepository/[some-number].json

На последнем шаге результаты загружаются на refstack.openstack.org для анализа и статистики. Подробнее об этом вы можете почитать здесь.

Документация refstack-client довольно проста и лаконична, но проблемы появляются на четвертом шаге с подготовкой tempest.conf. Для этого нужно разобраться, что входит в тесты DefCore, и включить необходимую функциональность OpenStack. Мы будем настроивать All-In-One (AIO) OpenStack (версия Mitaka), в котором все компоненты будут на одном хосте. Устанавливать будем, используя Puppet, по этим инструкциям. Эти же тесты можно запустить и в многохостовой конфигурации.

Тесты DefCore 2016.01 охватывают шесть компонент: Keystone, Glance, Cinder, Nova, Neutron, Swift. Поскольку выполняются только API-тесты, Horizon устанавливать не нужно. Включаем все сервисы в tempest.conf.

[service_available]
cinder = true
neutron = true
glance = true
swift = true
nova = true

Для тестов 2016.01 требуется возможность Nova изменять размеры инстансов. Включаем эту функцию в tempest.conf и настраиваем два flavor, чтобы Tempest мог создать экземпляр сначала с одной конфигурацией, а потом изменить на другую. Мы используем стандартные flavor: 1 (m1.tiny) и 2 (m1.small).

[compute]
flavor_ref = 1
flavor_ref_alt = 2
[compute-feature-enabled]
resize = true

Разрешаем AIO OpenStack изменение инстанса на одном узле в nova.conf.

allow_resize_to_same_host=True
scheduler_default_filters=AllHostsFilter

Затем перезапускаем сервисы nova.

service nova-scheduler restart
service nova-compute restart

Также для поддержки версионирования требуется Swift.

/etc/swift/container-server.conf

[app:container-server]
allow_versions = true

Для Swift нужно создать две роли (если они еще не существуют).

openstack role create Member
openstack role create ResellerAdmin

Их имена совпадают с конфигурацией в tempest.conf.

[object-storage]
operator_role = Member
reseller_admin_role = ResellerAdmin

Учетная запись, используемая для запуска тестов Tempest, должна иметь эти две роли. Создадим пользователя с именем swiftop, с указанными ролями.

openstack user create swiftop --password a_big_secret
openstack role add Member --user swiftop --project openstack
openstack role add ResellerAdmin --user swiftop --project openstack

Затем нужно создать файл с именем account.yaml с тестовой учетной записью. Клиент RefStack не поддерживает динамические учетные данные, поэтому нужно заранее создать тестовую учетную запись и указать ее в файле account.yaml. Аналогично нельзя попросить Tempest создать сеть для тестов — ее нужно создать перед запуском Tempest, как показано далее. По ряду причин некоторые тесты падают при их запуске под пользователем admin. Поэтому создаем учетную запись для запуска тестов.

- username: 'swiftop'
tenant_name: 'openstack'
password: 'a_big_secret'
roles:
- 'Member'
- 'ResellerAdmin'

Далее нам нужно сделать еще несколько вещей для запуска тестов Neutron. При установке Puppet мы включили туннелирование (для tenant-сети) и создали сеть public на мосту br-ex, чтобы хост, на котором запущен Tempest, мог общаться с экземплярами в нашем AIO OpenStack. Затем нужно создать tenant-сеть (типа vxlan) для использования Tempest.

neutron net-create mynet
neutron subnet-create mysubnet
neutron subnet-create --name mysubnet mynet 192.168.0.0/24
neutron router-create myrouter
neutron router-gateway-set myrouter public
neutron router-interface-add myrouter mysubnet

Для доступа к экземпляру с хоста можно создать плавающий IP-адрес (floating IP) и назначить этот IP экземпляру. Не забудьте разрешить порт 22 и icmp в группе безопасности "default", которые будет использоваться при создании экземпляров в тестах.

Затем в tempest.conf указываем сети:

[compute]
fixed_network_name = mynet
[network]
public_network_id = [UUID of ‘public’ network]
floating_network_name = public

В некоторых тестах 2016.01 Tempest необходимо подключаться к экземпляру по ssh для проверки, например, номера процессора и имени хоста. Поскольку мы используем образ cirros во всех тестах,  для входа в систему нет необходимости в использовании ssh-ключей. Логиниться будем с именем и паролем, которые укажем в tempest.conf.

[validation]
run_validation = true
connect_method = floating
image_ssh_user = cirros
image_ssh_password = cubswin:)

Tempest нужно два образа. Мы можем загрузить одинаковые образы cirros дважды, чтобы получить два разных UUID. Указываем их UUID в tempest.conf.

[compute]
image_ref = [UUID of cirros image]
image_ref_alt = [UUID of another cirros image]

Наконец, нам нужно указать Keystone uri.

[identity]
uri = http://localhost:5000/v2.0
uri_v3 = http://localhost:5000/v3
auth_version = v3

Мы запускаем Tempest на том же хосте, что и OpenStack AIO, поэтому используем здесь localhost. С версии Mitaka рекомендуется версия Keystone v3, поэтому в auth_version указываем v3 .

Со всеми этими изменениями запускаем тесты RefStack и загружаем результат на refstack.openstack.org.

Если ваше облако настроено правильно, то вы увидите зеленое "YES" на странице результатов, что означает соответствие DefCore 2016.01.

CI/CD очень часто используется в организации запуска тестов на различных стендах и окружениях. Также данные системы позволяют интегрировать процесс тестирования в процесс сборки продукта. Но часто возникает задача поднятия дженкинса и создания соответствующих сборок для прогона тестов на облаке. Создавать и настраивать руками сборки — это очень плохая практика, да и хочется хранить все в виде кода.

Уже завтра вечером состоится открытое занятие онлайн-курса «Автоматизация тестирования OpenStack», на котором обсудим:
— как поднять дженкинс, как docker compose service;
— как организовать сборку тестов и их прогон в докере дженкинс слейва;
— как сборки, описанные в виде конфигураций, задеплоить на дженкинс, используя Openstack Jenkins Jobs Builder.

Комментарии (0)