Авторы: Евгения Шумахер, Илья Стечкин Всем привет. Да, если вы любите деньги, то они вам нужны.
Далее мы объясним, что такое «проверка плагинов» и почему она полезна для бизнеса.
Если у вас нет бизнес-интересов, а программирование — это способ самовыражения, то дальше читать не нужно.
Плагины как часть архитектуры Fuel
И если вы решили читать, то давайте сначала вспомним, что это такое Топливо и плагины Fuel (см.сообщения в блоге от Август И Октябрь 2015).
Опросы пользователей показывают, что Fuel — очень популярный инструмент развертывания OpenStack. Возможность создавать плагины появилась в Fuel начиная с версии 6.1. Необходимо было позволить пользователям произвольно расширять функциональность этого инструмента облачного развертывания.
Раньше это можно было сделать только во время работы над кодом самого проекта.
Внедрение плагинов позволило пользователям настраивать Fuel, минуя сложный процесс внесения изменений в «ядро» проекта.
Однако сегодня у пользователей все еще есть возможность внести свой вклад в развитие Топливной напрямую.
Но это уже другая история, не имеющая отношения к теме нашей статьи.
Расширять функционал Fuel с помощью плагинов проще, ведь в этом случае не придется проходить миллион циклов утверждения чертежей (определение терминов смотрите в разделе ниже).
в словаре автора ) и так далее.
Дело в том, что сам плагин - это проект, которым вы управляете сами( Вот, например, как это делает Мелланокс ).
Термины, которых нет в словаре: Фреймворк плагина топлива — архитектурный термин, обозначающий, что продукт спроектирован таким образом, что его функциональность может быть расширена с помощью плагинов.
Плагин Fuel SDK (комплект разработки программного обеспечения) — набор инструментов, практик, документов и обучающих материалов, помогающих разработчику создавать плагины для Fuel. Доступна текущая версия Здесь , хотя он скоро переедет здесь , см.
совершить ).
Этот набор инструментов основан на правилах, полученных в результате анализа лучших практик разработки и внедрения плагинов.
Чтобы проверить плагин, вы должны следовать этим правилам.
Особенностью OpenStack является обязанность разработчика следовать правилам сообщества.
Если какая-либо инициатива предлагается без соблюдения соответствующих процедур, принятых в сообществе (например, создания плана), она гарантированно не будет принята.
Плагины Fuel дают разработчикам больше свободы.
Необходимость строго следовать «лучшим практикам» возникает только в том случае, если плагин подлежит проверке.
Например, необходимо обеспечить соответствие стандартам, разработанным для открытых лицензий (в основном Apache 2.0): Fuel — открытый проект. Это означает, что официальные плагины для Fuel также должны быть открыты.
Однако вы можете разрабатывать и использовать непроверенные плагины для своих нужд. Журнал драйверов - Этот каталог плагинов для компонентов OpenStack , которым управляет сообщество разработчиков.
Почему вы все еще заинтересованы в проверке плагина?
У валидации есть бизнес-аспект. Если вы официально получите подтверждение того, что ваш плагин работает с MOS (Mirantis OpenStack), то он будет опубликован не только в Журнал драйверов (что очень рекомендуется, более 30 плагинов для Fuel уже официально известны сообществу, хотя на самом деле их гораздо больше, просто мы о них не знаем), но и на сайте Мирантис , чтобы клиенты нашей компании знали об этом и могли использовать ваш продукт в своих решениях.В этом случае Мирантис выступает своего рода «основным рецензентом».
Мы говорим: «Вот правила написания плагинов».
Если по каким-то причинам вы решите не следовать этим правилам, это ваше право.
Пока вы не решите пройти процедуру валидации.
Но если пойти на валидацию, то мы читаем ваш код и можем поставить и +1, и -1. То есть мы можем рекомендовать улучшения кода.
Проверяем документацию (для валидации необходимо определенным образом документировать плагин — см.
SDK).
Кроме того, вы должны предоставить нам свой CI, включая тестовые сценарии и результаты тестов.
Мы обязательно проведем собственные тесты на основе ваших сценариев.
И их результаты должны совпадать с теми, которые вы предоставили.
Варианты MOS с проверенными плагинами могут быть приняты на поддержку службой поддержки Мирантис совместно с разработчиком плагина (т.е.
Мирантис ответит на звонок клиента, но если проблема в функционале, который предоставляет плагин Fuel, то запрос в поддержку будет передан в службу поддержки).
разработчик плагина).
Ограничения
Проверка не означает, что мы гарантируем, что плагин будет работать для всех клиентов и всех установок MOS. Разработчик плагина определяет конкретный вариант использования (вариант использования), а также описывает ограничения плагина.Мирантис проверяет корректность работы плагина в рамках конкретного варианта использования (варианта использования).
Всегда есть риск, что плагин не подойдет конкретному клиенту.
Плагин написан, задокументирован, успешно проверен, специалисты нашей компании или клиент заинтересованы в использовании плагина, но.
В ходе работы выясняется, что у клиента весьма специфические требования к развертыванию.
И плагин не работает. Таким образом, проверка не гарантирует, что плагин будет работать для всех клиентов.
Возможно, потребуется добавить или переписать плагин.
В таких случаях команда внедрения связывается со службой поддержки плагина и просит внести необходимые изменения в код для расширения функциональности плагина.
Важно помнить, что ни один плагин не входит в состав дистрибутива MOS. Последний не включает в себя никаких плагинов.
Плагины необходимо скачивать отдельно.
Это набор марионеточных манифестов, упакованных в формате rpm, который позволяет доставлять пакеты в определенном порядке.
Эта часть должна быть открытой.
При этом пакеты, устанавливаемые плагином, могут быть проприетарными и продаваться.
Например, Можжевельник Контрейл.
Чтобы использовать этот плагин, необходимо приобрести у Juniper право на использование пакетов Juniper Contrail, указав при покупке количество узлов и конфигурацию.
Только после того, как клиент разместит купленные пакеты по определенному адресу, MOS (с помощью плагина) сможет получить к ним доступ.
Ээтапы процесса проверки
Валидация – это сложный процесс, состоящий из нескольких этапов: 1. Предоставление спецификации («спецификация»), описывающей дизайн плагина.2. Обзор кода.
Конечно, на практике мы не ставим «оценки» проверяемому плагину, но даем свои комментарии.
Разработчик оставляет за собой право игнорировать наши комментарии.
Но возможно, что процесс проверки не будет завершен до тех пор, пока не будут внесены изменения.
3. Проверка документации.
Застройщики должны предоставить следующий пакет документов: — Руководство пользователя — важнейший документ, содержащий информацию о том, как и зачем использовать плагин, какие есть ограничения на его использование, какие «лайфхаки» будут полезны пользователю и с какими «подводными камнями» он может столкнуться.
— План испытаний.
— Отчет об испытаниях.
Последние два документа позволяют проверить полноту покрытия вариантов использования тестами.
Для всех упомянутых выше документов разработаны шаблоны.
Они являются частью SDK Fuel Plugin. Что касается тестов, то мы различаем два типа: общие/обязательные и специальные.
Мы ожидаем, что партнеры добавят уникальные тестовые примеры в свой план тестирования.
Кроме того, партнеры должны создавать собственные CI и разрабатывать автоматизированные тесты, чтобы упростить процесс создания и тестирования плагинов.
Отчет об испытаниях, в свою очередь, позволяет нам сравнить результаты наших испытаний с тем, что получили вы.
Для того, чтобы провести это сравнение, мы полностью повторяем путь «неназванного пользователя» — просим прислать плагин в виде пакета и в нашей лаборатории (или лаборатории партнера) последовательно выполняем все шаги из руководство пользователя, предоставленное разработчиком.
После этого берем план тестирования и выборочно проходим тесты.
Таким образом мы получаем представление о том, насколько правдивы результаты протокола испытаний.
Обычно эта процедура позволяет отловить большое количество ошибок.
До сих пор не было случая, чтобы у нас не было комментариев.
Иногда это рутинные правки, но бывают и критические ошибки, которые необходимо исправить перед публикацией.
Некоторые партнеры считают нас слишком строгими.
Но мы убеждены, что сила Мирантис – в надежности предлагаемых ею решений.
4. Мы просим наших партнеров предоставить нам живую демо-версию плагина.
Это позволяет а) всем заинтересованным отделам Мирантис ознакомиться с плагином и б) наглядно продемонстрировать функциональность предлагаемого решения.
После завершения процесса проверки мы публикуем плагин в нашем партнерском каталоге.
Разработчик также может самостоятельно опубликовать его в журнал драйверов .
Заключение
Со стороны процесс кажется сложным, но для тех, кто знаком с тем, как работает сообщество, здесь нет ничего нового.Наша партнерская команда помогает всем разработчикам плагинов добиться успеха.
Мы не только разрабатываем SDK, но и всегда готовы ответить на вопросы.
Чтобы связаться с нами, используйте IRC-чат на freenode.net (общий канал Fuel называется #fuel, канал разработчиков Fuel — #fuel-dev, каналы для разработчиков основных компонентов Fuel — #fuel-library, #fuel -python, #fuel-ui , #fuel-qa, #fuel-infra Уведомления Gerrit для всех репозиториев Fuel доступны здесь: #fuel-tracker), вы также можете использовать почтовый адрес.
разблокировано[email protected] .
Более подробная информация Здесь .
Теги: #Mirantis #Mirantis #Fuel #валидация #mellanox #плагин #Apache #puppet #open source #puppet
-
Alpha 400 — Новый Субноутбук Для Linux
19 Oct, 24 -
Microsoft Продала 1 Миллион Плееров Zune
19 Oct, 24 -
Jmeter: Забудьте О Сэмплере Beanshell
19 Oct, 24 -
Я Люблю Красивые Диаграммы
19 Oct, 24