Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

"Весь из себя Python" - первая часть интервью с Александрой Федоровой о тестировании OpenStack

Это архивная статья

В корпоративном блоге компании "Мирантис" опубликовали первую часть интервью с с Александрой Федоровой о тестировании OpenStack:

System Message: ERROR/3 (<string>, line 8)

Error in "rubric" directive: no content permitted.

.. rubric:: Весь из себя Python
   :name: весь-из-себя-python

    Реплика Александры Федоровой, руководителя команды CI (Москва,
    Россия).


Весь из себя Python

От редакции

Когда мы решили регулярно публиковать обновления в корпоративном аккаунте в 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.

Итак, модульные, функциональные и интеграционные тесты есть в апстриме. Остальное — фреймворки системных тестов.

Фреймворки системных тестов

Весь из себя Python-02

Почему это специфично было для 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 и дергают что-то еще…

Продолжение следует!

Комментарии