Валідація Fuel-плагінів в рамках Mirantis Unlocked validation program. Воно вам треба?

Автори: Євгенія Шумахер, Ілля Стечкин

Всім привіт. Так, якщо ви любите гроші, то воно вам треба. Далі ми розповімо, що таке «валідація плагінів» і чому це корисно для бізнесу. Якщо у вас немає бізнес-інтересів, а програмування — спосіб самовираження, то далі можете не читати.

Плагіни як частина архітектури 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. Більш детальна інформація здесь.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.