Действующие лица и исполнители:

Александр Кислицкий — автор кода,
Евгения Шумахер, Ирина Поволоцкая — полезные замечания и ссылки,
Вячеслав Струк — ревью,
Илья Стечкин — рассказчик

Важная оговорка: мир плагинов очень быстро развивается. То, что описано ниже, актуально для плагинов, созданных под MOS 6.0. Напомним, что MOS — это Mirantis OpenStack, наш дистрибутив, открытый, как и все, что мы делаем. Однако на прошлой неделе было официально объявлено об официальном выпуске MOS 7.0, а это совсем другая история, которую мы тоже постараемся рассказать. Но в другой раз. Для ленивых копипастеров сразу предлагаем ссылку на GitHub и напоминаем, что лень — двигатель прогресса.

Итак, переходим ко второй части и поговорим, наконец, о том, как же был сделан конкретный NFS-плагин. В нашем случае NFS-сервер, который был использован в качестве бэкенда для Cinder, уже установлен. Если вам повезло меньше, то советуем почитать соответствующий мануал. Его пересказ не входит в наши планы — итак текст получился довольно объемным. Зато в наши планы входит поделиться опытом создания плагина и снабдить вас полезными ссылками на дополнительные материалы, имеющие непосредственное отношение к теме. Да, кстати, нас иногда обвиняют в том, что в текстах слишком много общих слов. В этот раз мы постарались исправиться. Поехали!

Создание среды разработки

Чтобы построить свой плагин, необходимо вначале сделать виртуальную среду разработки: создать директорию, активировать ее и установить Fuel plugin builder:

$ mkdir plugins
$ cd plugins
$ virtualenv .venv
$ source .venv/bin/activate
$ pip install fuel-plugin-builder

Фишка в том, что вам не нужно быть рутом на сервере, чтобы построить новый плагин в этой виртуальной среде разработки.

Создание плагина

Теперь используйте Fuel plugin builder, начните работу над плагином со следующей команды для того, чтобы сгенерировать “скелет” будущего плагина:

$ fpb -create external_nfs

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

Бэкенд плагина

Задайте определение плагина в metadata.yaml, как показано ниже. Здесь мы используем Fuel 6.0 с плагинами в HA и multinode режимах.
Самая подробная информация о том, как это делается, доступна в документе под названием OpenStack Cloud Administrator Guide.

Важно! Только плагины, созданные в Mirantis OpenStack 6.0 и выше могут быть провалидированы. О том, что такое валидация и для чего она нужна, мы писали в первой части этого эпохального повествования. А как пройти валидацию — расскажем в конце этого текста.

А теперь несколько абзацев для тех, кто и без гайдов в теме:

$ Plugin name
name: external_nfs
title: External NFS backend for Cinder
$ Plugin version
version: 1.0.0
$ Description
description: External NFS backend for Cinder
$ Required fuel version
fuel_version: ['6.0']

$ The plugin is compatible with releases in the list
releases:
- os: ubuntu
   version: 2014.2-6.0
   mode: ['ha', 'multinode']
   deployment_scripts_path: deployment_scripts/
   repository_path: repositories/ubuntu
- os: centos
   version: 2014.2-6.0
   mode: ['ha', 'multinode']
   deployment_scripts_path: deployment_scripts/
   repository_path: repositories/centos

$ Version of plugin package
package_version: '1.0.0'

Добавление shell таски

Теперь скачайте пакеты, необходимые для NFS Ubuntu и CentOS и переместите их в директории external_nfs/repositories/ubuntu и external_nfs/repositories/centos соответственно, чтобы добавить задачу для установки пакета.
Сохраните пакеты в deployment_scripts / install_packages.sh и добавьте исполняемые разрешения для скрипта “chmod +x install_packages.sh”:

$ !/bin/bash

OS_NAME=''
if grep -i CentOS /etc/issue.net >/dev/null; then
   OS_NAME='centos';
elif grep -i Ubuntu /etc/issue.net >/dev/null; then
   OS_NAME='ubuntu';
fi

function install_package {
   if [ $OS_NAME == 'ubuntu' ]; then
       apt-get install -y rpcbind nfs-common libevent-2.0 \
           libgssglue1 libnfsidmap2 libtirpc1
   elif [ $OS_NAME == 'centos' ]; then
       yum install -y rpcbind nfs-utils nfs-utils-lib libevent \
           key-utils libtirpc libgssglue
   fi
}

install_package

Далее добавьте shell таски, чтобы установить пакеты. Наш tasks.yaml файл со скриптом install_packages.sh, который запускается после развертывания на Cinder ноде, выглядит следующим образом:

- role: ['cinder']
stage: post_deployment
type: shell
parameters:
   cmd: ./install_packages.sh
   timeout: 180

Фронтенд плагина

Теперь добавьте чекбокс и специфические элементы для вкладки “Настройки” (Settings) интерфейса Fuel. Для этого опишите UI в environment_config.yaml согласно следующим параметрам:

1. NFS shares file
2. NFS mount options
3. Is NFS sparse volumes are used

Добавьте описание интерфейса плагина так, как это показано в нижеследующем примере:

attributes:
endpoint:
   value: ''
   label: 'NFS endpoints'
   description: 'comma separated HOST:SHARE values'
   weight: 25
   type: "text"
mount_options:
   value: ''
   label: 'NFS mount options'
   description: 'optional NFS mount parameters'
   weight: 25
   type: "text"
nfs_sparsed_volumes:
   type: "checkbox"
   weight: 30
   value: false
   label: "NFS sparsed volumes"

description: ""

Добавление puppet таски

Puppet манифесты представляют задачи так, как описано в OpenStack Cloud Administrator Guide и отправляют их в директорию deployment_scripts/puppet directory на GitHub.

После применения puppet манифестов, обратите внимание на права в /etc/nfsshares файлах и выполните следующую команду, чтобы перезапустить службу Cinder:

Puppet apply external_nfs/deployment_scripts/puppet/modules/cindernfs/manifests/backend/nfs.pp.

Теперь добавьте задачу применить манифесты в tasks.yaml:

- role: ['cinder']
stage: post_deployment
type: puppet
parameters:
   puppet_manifest: puppet/site.pp
   puppet_modules: puppet/modules/:/etc/puppet/modules
   timeout: 360

Сборка плагина

Совместим pre_build_hook с соответствующей версией fuel-library. В нашем случае это выглядело так:

#!/bin/bash

set -eux
ROOT="$(dirname `readlink -f $0`)"
MODULES="${ROOT}"/deployment_scripts/puppet/modules
TMP_DIR="${ROOT}"/tmp
mkdir -p "${MODULES}"
mkdir -p "${TMP_DIR}"
REPO_PATH='https://github.com/stackforge/fuel-library/tarball/f43d885914d74fbd062096763222f350f47480e1'
wget -qO- "${REPO_PATH}" | \
   tar -C "${MODULES}" --strip-components=3 -zxvf - \
   stackforge-fuel-library-f43d885/deployment/puppet/{inifile,stdlib}

Теперь вы можете собрать свой пакет следующим образом:

fpb --build external_nfs

Пакет будет сохранен как external_nfs / external_nfs-1.0.0.fp, и теперь вы можете развернуть модуль, используя VirtualBox, как показано в руководстве Mirantis Quick Start.

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

Развертывание плагина

Итак, плагин создан. Скопируйте его на Fuel Master ноду и установите для развертывания:

scp external_nfs/external_nfs-1.0.0.fp root@master-node:
ssh root@master-node
fuel plugins --install external_nfs-1.0.0.fp

Убедимся что плагин установлен:

$ fuel plugins

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

Поиск неисправностей

Вот, например, часто встречающаяся ситуация: файл существует, но найти его не удается. Например, давайте предположим, что вы не указали путь для сценария install_packages.sh:

- role: ['cinder']
stage: post_deployment
type: shell
parameters:
   cmd: install_packages.sh
   timeout: 180

В этом случае развернуть клауд не удастся, система выдаст следующую ошибку:

Deployment has failed. Method deploy. Failed to deploy plugin external_nfs-1.0.0. Inspect Astute logs for the details.

Предполагается, что в этом случае вы захотите взглянуть на логи, которые будут находиться на /var/log/docker-logs/astute.log на Fuel master ноде, и в нашем конкретном случае будут иметь такой вид:

2014-12-23T16:31:54 debug: [395] c5d1e2b5-56bb-4428-9666-8c5574cb06a4: MC agent 'execute_shell_command', method 'execute', results: {:sender=>"3", :statuscode=>0, :statusmsg=>"OK", :data=>{:stdout=>"", :exit_code=>127, :stderr=>"sh: 1: install_packages.sh: not found\n"}}
2014-12-23T16:31:54 debug: [395] c5d1e2b5-56bb-4428-9666-8c5574cb06a4: cmd: cd /etc/fuel/plugins/external_nfs-1.0.0/ && install_packages.sh
cwd: /etc/fuel/plugins/external_nfs-1.0.0/
stdout:
stderr: sh: 1: install_packages.sh: not found

Отсюда видно, что путь install_packages.sh в tasks.yaml указан неправильно. Поправить это можно так:

- role: ['cinder']
stage: post_deployment
type: shell
parameters:
   cmd: ./install_packages.sh
   timeout: 180

После внесения исправлений пересоберите пакет и обновите его на Fuel Master ноде:

fpb --build external_nfs
scp external_nfs/external_nfs-1.0.0.fp root@master-node:
ssh root@master-node
fuel plugins -- install --force external_nfs-1.0.0.fp

Проверка результатов

Решив эту проблему, вы можете создать новую среду, настроить и развернуть клауд. После успешного развертывания, убедитесь, что Cinder работает должным образом с NFS-бэкендом. Сделать это несложно:

1. Залогиньтесь в Контроллер и создайте Cinder volume:

ssh root@master-node
ssh controller-node
source openrc
cinder create 1

2. Проверьте состояние тома (volume status) через Fuel CLI. Подробнее см. Mirantis OpenStack User Guide.

Cinder-list

3. Проверьте, что ID из cinder list output, созданный на NFS, шарится как файл с именем, соответствующим volume-Id value:

nfs-server$ ls
volume-d9382a2b-fd13-424b-9eba-3a77a1d16008

Если вы хотите поправить Puppet манифесты на Cinder ноде, то можете найти их в директории /etc/fuel/plugins/external_nfs-1.0.0/puppet

ssh root@master-node
ssh cinder-node
cd /etc/fuel/plugins/external_nfs-1.0.0/
puppet apply --modulepath=/etc/fuel/plugins/external_nfs-1.0.0/puppet/modules site.pp

Дополнительная информация доступна здесь.

Релиз плагина

После создания плагина вам доступна любая из опций:

1. Развернуть и использовать плагин самостоятельно, без каких-либо контактов с командой Mirantis. У этого сценария два минуса: ваш клауд не будет поддерживаться нашим саппортом и, следовательно, вы действуете на свой страх и риск. Ну и коммьюнити не узнает о вашем подвиге, не сможет воспользоваться результатами вашего труда и оценить по достоинству функциональность созданного плагина, так как плагин не будет опубликован в нашем каталоге.

2. Разместить плагин для MOS без валидации. То есть вы позволяете другим людям, которые скачивают Mirantis OpenStack, загружать также и ваш плагин, но такая установка не будет поддерживаться командой Mirantis. Для этого достаточно выложить entry плагина на драйверлог.

3. Разместить плагин, стать партнерами Mirantis (то есть соответствовать определенным требованиям проекта Mirantis Unlocked) и отправить запрос на валидацию, сертифицировать его, и, ЕСЛИ в ходе процедуры валидации подтвердится качество плагина, мы опубликуем его в каталоге и будем поддерживать MOS-клауды с этим плагином.

Процесс валидации не является обязательным и занимает некоторое время, но провалидированные плагины добавляются во Fuel plugin catalog и поддерживаются саппортом Mirantis. И это важно, особенно для крупных предприятий, не имеющих в штате большого количества специалистов по OpenStack.

Валидация плагина

Если вы все-таки решились провалидировать свой плагин, то мы сейчас расскажем коротко о процедуре. Но перед этим еще раз напомним, что вы должны быть партнером Mirantis. Любая интеграция плагинов (а валидация — один из шагов к интеграции с MOS) возможна только в рамках партнерской программы.

Во-первых, вам нужно предоставить в Mirantis определенный набор документов:

— Спецификацию проекта (или “спеку”, как называют этот документ в тусовке),
— Руководство по установке и развертыванию плагина,
— Руководство пользователя,
— План тестирования,
— Результаты тестирования.

Подробности о том, как структурировать руководства, можно почитать тут.

Во-вторых, сам процесс сертификации состоит из следующих шагов:

— Ревью спеки проекта,
— Ревью кода,
— Ревью плана тестирования,
— Ревью инструкции по развертыванию плагина,
— Ревью руководства пользователя,
— Анализ результатов тестирования, представленных разработчиком,
— Собственное тестирование плагина командой Mirantis.

Важно: работать с плагином можно и без Fuel, а сертификация вовсе не является обязательной процедурой. Она требуется в том случае, если вы хотите гарантировать поддержку вашего MOS-облака с авторским плагином командой Mirantis. Впрочем, кажется, мы повторяемся. Но это правда важно!

Вместо заключения: расширяем возможности OpenStack с помощью плагинов

Мы показали вам создание плагина на примере NFS, но вы можете создать плагин, отвечающий вашим уникальным потребностям. Гибкость Fuel позволит комфортно разворачивать ваше облако и управлять им. Кроме того, если вы не поленитесь пройти процедуру сертификации, то получите для своего плагина поддержку специалистов Mirantis.

Когда мы говорим про поддержку, речь идет о том, что поддержку самого плагина — его кода — осуществляют разработчики, а команда Mirantis может поддерживать MOS-клауды с провалидированными плагинами.

Создавая плагины для Fuel, вы помогаете расширять функционал экосистемы OpenStack. А тщательно пережевывая пищу — помогаете обществу!

Как сделать fuel-плагин (на примере NFS). Часть 2