Авторы: Евгения Шумахер, Илья Стечкин

Всем привет. Да, если вы любите деньги, то оно вам надо. Дальше мы расскажем, что такое “валидация плагинов” и почему это полезно для бизнеса. Если у вас нет бизнес-интересов, а программирование — способ самовыражения, то дальше можете не читать.

Плагины как часть архитектуры Fuel

А если решили читать, то давайте сперва вспомним, что такое Fuel и Fuel-плагины (см. блог-посты от августа и октября 2015 года). Опросы пользователей показывают, что Fuel — очень популярный инструмент развертывания OpenStack. Возможность создавать плагины появилась во Fuel, начиная с версии 6.1. Нужно было позволить пользователям произвольно расширять функциональность этого инструмента развертывания облака. Раньше это можно было делать исключительно в ходе работы над кодом самого проекта. Внедрение плагинов позволило пользователям кастомизировать Fuel в обход сложной процедуры внесения изменений в “ядро” проекта.

Впрочем, и сегодня у пользователей остается возможность внести лепту в развитие Fuel напрямую. Но это другая история, не связанная с темой нашей статьи. Расширять функциональность Fuel с помощью плагинов проще, потому что в этом случае не надо проходить через миллион циклов аппрува блюпринтов (определение терминов см. в Словаре контрибутора) и т.п. Дело в том, что плагин сам является проектом, которым управляете вы сами ( вот, например, как это делает Mellanox).

Термины, которых нет в словаре:

Fuel plugin framework — архитектурный термин, который говорит о том, что продукт создан таким образом, что его функционал можно расширять с помощью плагинов.

Fuel plugin SDK (Software Development Kit) — набор инструментов, практик, документов и обучающих материалов, которые помогают разработчику создавать плагины для Fuel. Текущая версия доступна здесь, хотя в скором времени переедет сюда, см. коммит). В основе этого набора инструментов лежат правила, выведенные на основании анализа лучших практик разработки и внедрения плагинов. Для валидации плагина необходимо следовать этим правилам. Особенностью OpenStack является обязанность разработчика следовать правилам комьюнити. Если какая-то инициатива предложена без соблюдения соответствующих процедур, принятых в сообществе (например, заведение блюпринта) — она гарантировано не будет принята. В случае с плагинами для Fuel у разработчиков есть больше свободы. Необходимость строго следовать “best practices” возникает только в том случае, если предполагается валидация плагина. Например, необходимо следить за соблюдением норм, разработанных для свободных лицензий (преимущественно Apache 2.0): Fuel — открытый проект. А значит официальные плагины для Fuel тоже должны быть открытыми. Однако, для собственных нужд можно разрабатывать и использовать невалидированные плагины.

Драйверлог — это каталог плагинов для OpenStack компонентов, который управляется сообществом разработчиков.

Почему вам все-таки интересно провалидировать плагин

В валидации есть бизнес-аспект. Если вы официально получите подтверждение того, что ваш плагин работает с MOS (Mirantis OpenStack), то он будет опубликован не только в Драйверлоге (что крайне рекомендуется, уже более 30 плагинов для Fuel официально известны сообществу, хотя на самом деле их гораздо больше, просто мы о них не знаем), но еще и на сайте Mirantis, для того, чтобы об этом знали клиенты нашей компании и могли использовать ваш продукт в своих решениях.

В этом случае Mirantis выступает своего рода “кор-ревьюером”. Мы говорим: “Вот правила написания плагинов”. Если вы по какой-то причине решили не следовать этим правилам — это ваше право. До тех пор, пока вы не решили пройти процедуру валидации. Но если вы идете на валидацию, то мы читаем ваш код и можем поставить как +1, так и -1. То есть мы можем рекомендовать доработки к коду. Проверяем документацию (для валидации обязательно задокументировать плагин определенным образом — см. SDK). Кроме того, вы должны предоставить нам свой CI, включая сценарии тестирования и его результаты. Мы обязательно проводим собственные тесты по вашим сценариям. И их результаты должны совпасть с теми, которые предоставили вы.

Варианты MOS с провалидированными плагинами могут быть взяты на поддержку саппортом Mirantis совместно с разработчиком плагина (т.е. Мирантис ответит на звонок клиента, но если проблема в функциональности, которую предоставил Fuel плагин, то заявка на поддержку будет передана разработчику плагина).

Ограничения

Валидация не означает, что мы гарантируем, что плагин подойдет для всех клиентов и всех инсталляций MOS. Разработчик плагина определяет конкретный юзкейс (вариант использования), а также описывает ограничения в работе плагина. Мирантис же проверяет корректность работы плагина в рамках конкретного юзкейса (варианта использования). Всегда есть риск того, что плагин не подойдет тому или иному клиенту.

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

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

Важно помнить, что ни один плагин не является частью дистрибутива MOS. Последний не включает в себя ни один плагин. Плагины нужно скачивать отдельно. Это набор puppet манифестов, запакетированный в формате rpm, который позволяет поставить пакеты в определенном порядке. Эта часть должна быть открытой. При этом пакеты, которые ставятся плагином, могут быть проприетарными и являться объектом продажи. Например, Juniper Contrail. Для того, чтобы использовать данный плагин, необходимо купить у Juniper право на использование Juniper Contrail пакетов, указав при покупке количество нод и конфигурацию. Только после того, как клиент разместит купленные пакеты по конкретному адресу, MOS (с помощью плагина) получит возможность обращаться к ним.

Этапы процесса валидации

Валидация — процесс сложный, состоящий из нескольких этапов:

1. Предоставление спецификации (“спеки”), которая описывает дизайн плагина.

2. Ревью кода. Конечно, на практике мы не выставляем “оценки” валидируемому плагину, но даем свои комментарии. За разработчиком остается право игнорировать наши замечания. Но возможна ситуация, при которой процесс валидации не будет завершен до тех пор, пока изменения не будет внесены.

3. Ревью документации. Разработчики должны предоставить следующий пакет документов:
— Руководство пользователя (user guide) — это самый главный документ, содержащий информацию о том, как и для чего пользоваться плагином, какие есть ограничения на его использование, какие “лайфхаки” пригодятся пользователю и с какими “подводными камнями” он может встретиться.
— Тест-план.
— Тест-репорт. Последние два документа позволяют нам проверить полноту покрытия юзкейса тестами.

Для всех упомянутых выше документов разработаны шаблоны. Они являются частью Fuel Plugin SDK.
Что касается тестов, то мы выделяем два типа: общие/обязательные и специфические. Мы рассчитываем, что партнеры будут добавлять уникальные тестовые сценарии в свой тест-план. Кроме того партнеры должны построить свой CI и разработать автоматические тесты для упрощения процедуры сборки и тестирования плагинов.
Тест-репорт, в свою очередь, позволяет нам сравнить наши результаты тестирования с тем, что получилось у вас.
Для того, чтобы провести это сравнение, мы полностью повторяем путь “безымянного пользователя” — просим прислать плагин в виде пакета и на своей лабе (или лабе партнера) последовательно осуществляем все шаги из представленного разработчиком руководства пользователя. После этого берем тест-план и выборочно проходимся по тестам. Таким образом мы получаем представление о том, насколько правдивы результаты тест-репорта. Обычно эта процедура позволяет отловить большое количество багов. Пока еще ни разу не было случая, чтобы у нас не возникло замечаний. Иногда это рутинные правки, но встречаются и критические ошибки, которые необходимо исправить до публикации. Некоторые партнеры считают нас слишком строгими. Но мы убеждены в том, что сила Mirantis — в надежности предлагаемых решений.

4. Мы просим партнеров провести для нас демонстрацию плагина в режиме реального времени. Это позволяет а) всем заинтересованным подразделениям Mirantis познакомиться с плагином и б) наглядно демонстрирует работоспособность предлагаемого решения.

По окончании процесса валидации мы публикуем плагин в нашем партнерском каталоге. Разработчик также может самостоятельно опубликовать его в драйверлоге.

Заключение

Со стороны процесс кажется сложным, но для тех, кто знаком с тем, как работает комьюнити, тут нет ничего нового. Наша команда, отвечающая за работу с партнерами, помогает всем разработчикам плагинов добиться успеха. Мы не только развиваем SDK, но и всегда готовы ответить на вопросы. Для связи с нами используйте IRC-чат на freenode.net (общий канал Fuel называется #fuel, канал разработчиков Fuel — #fuel-dev, каналы для разработчиков основных компонентов Fuel: #fuel-library, #fuel-python, #fuel-ui, #fuel-qa, #fuel-infra. Gerrit-уведомления для всех репозиториев Fuel доступны здесь: #fuel-tracker), также вы можете использовать адрес почтовой рассылки unlocked-tech@mirantis.com. Более подробная информация здесь.

Валидация Fuel-плагинов в рамках Mirantis Unlocked validation program. Оно вам надо?