System Message: ERROR/3 (<string>, line 8)
Error in "rubric" directive:
no content permitted.
.. rubric:: Весь из себя Python
:name: весь-из-себя-python
Реплика Александры Федоровой, руководителя команды CI (Москва,
Россия).

От редакции
Когда мы решили регулярно публиковать обновления в корпоративном
аккаунте в Facebook на русском
языке, то лелеяли надежду,
что аудитория, заинтересованная в OpenStack-теме, начнет
разговаривать с нами. И вот, это произошло! Мы начали получать
вопросы от читателей. И это очень, очень важно для нас! Пожалуйста,
не останавливайтесь!
Вопрос, ответ на который мы подготовили сегодня, касается
тестирования и звучит следующим образом:
Можете ли вы описать в общих чертах процесс тестирования на
Python ваших продуктов OpenStack, так как очень сложно
разобраться в взаимосвязях их отдельных элементов.
Для первой беседы на тему тестирования мы пригласили Александру
Федорову, руководителя команды CI из московского офиса нашей
компании. И вот что она рассказала…
Виды тестирования, применяемые в OpenStack
OpenStack — это много разных Python-проектов. Каждый проект
тестируется на нескольких уровнях. Если точнее — на четырех:
Начнем по порядку. Специфика OpenStack в том, что это набор из
большого числа достаточно независимых проектов. У каждого
проекта
есть свой фреймворк для unit-тестов. Функциональные тесты так же,
как unit-тесты, связаны с особенностями использования того или иного
сервиса. Управляются и автоматизируются эти тесты, опять же, на
уровне одного конкретного проекта. Для Python-кода при этом
используется стандартный подход запуска кода в tox-окружении.
Интеграционные тесты позволяют протестировать совместную работу
нескольких проектов. Для этого принято использовать так называемый
Devstack — написанный на Bash фреймворк для деплоймента базового
OpenStack-окружения. На развернутом окружении далее прогоняется
Python-based
Tempest
framework, он и позволяет тестировать сценарии взаимодействия между
разными сервисами экосистемы OpenStack. Например, для создания
compute-ноды нужно авторизоваться в Keystone, получить базовый образ
из Glance и IP-адрес из Neutron.
Длинные цепочки взаимодействия между сервисами тестируются в
апстриме на девелоперском окружении
(DevStack), с
помощью Tempest.
Нет ли конкуренции между фреймворками Tempest и Rally
внутри экосистемы OpenStack?
Нет, сейчас эти два проекта сотрудничают друг с другом. Rally
отвечает за
бенчмарк-тестирование
(или проверку производительности системы) и нагрузочное
тестирование.
Tempest — это про сценарии, про логику взаимодействия между
сервисами, а Rally — про нагрузку: что произойдет, если я “прогоню”
этот сценарий 100500 раз? Сколько времени это займет? Часто
тестировщики “гоняют” Rally поверх Tempest. Или используют Tempest
как Rally-case.
Итак, модульные, функциональные и интеграционные тесты есть в
апстриме. Остальное — фреймворки системных тестов.
Фреймворки системных тестов

Почему это специфично было для
Fuel?
Потому что Fuel — это сервис развертывания OpenStack, и мы тестируем
не просто сервисы и их работу друг с другом, а проверяем полный
цикл, от установки управляющей Fuel-ноды на «пустой» сервер,
предоставления доступа к OpenStack Dashboard, проигрывания типичных
сценариев работы с облаком, до апгрейда кластера. Еще тестируем
отдельно много разнообразных сценариев установки.
В апстриме DevStack предполагает довольно однообразное базовое
девелоперское развертывание OpenStack: на одной ноде разворачиваются
все сервисы, каждый из которых получает собственную screen-сессию,
где разработчик может интерактивно выполнять какие-то операции,
смотреть лог или даже патчить код «наживую». Во Fuel поддерживается
установка OpenStack в HA-режиме с несколькими контроллерами, с
разнообразными конфигурациями сети. Это тестирование более «тяжелое»
— базовый системный тест занимает около полутора часов на
«стандартном» bare-metal сервере.
Для системных тестов опять используется фреймворк, основанный на
Python, который состоит из двух частей: Fuel
devops, который
готовит окружение из 5-10 виртуальных машин, и Fuel
QA — тестовый фреймворк на
базе Proboscis, в котором, собственно, содержится вся логика
тестовых сценариев и реализация работы с Fuel и OpenStack.
Человек готовится к собеседованию в Mirantis: что ему
нужно знать о тестировании?
С моей точки зрения, у нас QA-процессы построены на многих
взаимодействиях с низкоуровневыми вещами. Например, процесс создает
виртуальные машины, делает запрос к низкоуровневому API, “ходит” по
серверам… Это не чисто python-в-себе. Из него всегда есть выходы на
какие-то системные или OpenStack-сервисы. То есть ты не можешь
ограничиваться только знанием python-фреймворка, нужна хорошая база.
Но основные принципы те же. Возьмем, например, nose test
фреймворк:
тест-кейсы, настройка начального окружения, реверт к стандартному
окружению, зависимости… Но наполнение каждого из этих шагов может
быть нестандартным для классической python-разработки, потому что
всегда есть “хвосты” наружу, которые смотрят из Python и дергают
что-то еще…
Продолжение следует!