Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущих частях мы разобрали, что же такое Terraform, осознали границу между ответственностью HashiCorp и вендора и сформировали примерный облик решения — провайдера инфраструктуры.  

Третья статья этого цикла будет посвящена обзору достижений (и злоключений) других людей — тех, кто уже попытался привнести IaC в oVirt и не достиг успеха. Что у них получилось? А что не получилось и почему? Ответим на эти вопросы чуть ниже. 

Статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему, — все это серьезно сказалось на terraform-provider-ovirt.

Terraform-provider-ovirt 

Итак, проект открытого провайдера инфраструктуры для системы виртуализации oVirt. Формально он живой — последний релиз вышел 10 декабря 2025 года. Три месяца без минорных релизов для TF-провайдера — ситуация, я бы сказал, несколько нездоровая и характеризует размер пользовательской базы. Она есть, просто очень специфическая, но не будем забегать вперед.

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

 Вот так выглядит наш первый, сильно упрощенный манифест, для быстроты знакомства:

Запускаем!

Одна ВМ будет создана, пока все неплохо.

Выполнение отрабатывает очень быстро. Обязательное напоминание о том, что мы используем небезопасное соединение, — это правильно. Пока все хорошо. 

Проверяем результат:

ВМ на месте! Руками запустил, вошел в систему — все порядке. 

Terraform destroy отработал без проблем, ВМ удалилась. Ну, самое «минус первое»  впечатление можно считать составленным:

• Провайдер подтянулся автоматически, ничего доставлять руками не пришлось;

• Взятый из документации кусок после переименования отработал как положено; 

• Безопасности уделяется достаточное внимание (на первый взгляд, как минимум). 

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

«Мне нужна виртуальная машина из шаблона, к ней прицепить новый диск, машину подключить к сети, запустить, адрес она получит сама, мы его как-нибудь узнаем и дальше пользователь по SSH разберется», — для более реалистичного ознакомления вполне хватит, несмотря на очевидные вопросы к сетевой части. 

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

ВМ отдельно, диск отдельно

Итак, создаем диск. Верим документации, так как задача не выглядит сложной. Обновляем манифест. (Уже упомянутые комменты удалил для экономии места, также опустил блок подключения самого провайдера — он не меняется в ходе статьи. И не обращайте внимания пока на две новенькие строчки в описании ВМ, о них чуть позже).

Диск на месте.

А теперь нюанс: я получил отдельно ВМ и отдельно диск. Кажется, диски в отрыве от ВМ слабо помогают мне решать бизнес-задачи. Как это выглядит в UI? Вот так, выделяем виртуальную машину и нажимаем «Изменить»: 

Пристальный просмотр описания ресурса ВМ в документации к провайдеру не показывает ничего, связанного с дисками. Еще бы! Ведь для организации связи у нас есть отдельный ресурс — disk_attachment! Более того, есть и во множественном числе — disk_attachments. Это ресурсы, которые определяют подключение диска/дисков к ВМ. Давайте попробуем: 

Работает.

С сетями та же история — ресурс ovirt_nic определяет, какую сеть (vNIC профиль, на самом деле) к какой ВМ прицепить:

Тоже работает.

После такого опыта появляется очень много вопросов даже чисто с UX-точки зрения. И в своих требованиях отдельного провайдера для zVirt заказчики в том числе отмечают эти маленькие неудобства. 

Нетривиальный подход к управлению ресурсами

Итак, не «по клику», но мы собрали нашу виртуальную машину. Пришло время ее включить. Как же это делается? Среди полей объекта ovirt_vm лишь поле status выглядит многообещающе (может быть down, reboot_in_progress, powering_up и т.п.), но оно доступно только для чтения. Идем в документацию и обнаруживаем ресурс (!!!) ovirt_vm_start:

• vm_id — какую ВМ надо включить, обязательный параметр;

• status — всегда up;

• force_stop, status, stop_behaviour — как выполнять отключение ВМ, уточнение процесса. 

Terraform apply — ВМ создалась и запустилась. Если данный ресурс ovirt_vm_start удалить, она выключится. Что делать, если вы хотите перезагрузить ВМ? Видимо, сначала выключить, а потом включить.

Мы видим ситуацию, когда состояние ВМ отделено от объекта самой ВМ и управляется семейством собственных ресурсов. Более того, в документации сразу дан пример о необходимости прописывать взаимные зависимости от других ресурсов вручную, без автоматики terraform.

В принципе, это работает, но разработчики провайдера предлагают нам весьма нетривиальный подход к управлению ресурсами. Если бы это был UI, то нам бы пришлось:

• Создать диск в отдельной оснастке «Диски»;

• Создать ВМ в оснастке «Виртуальные машины»;

• В оснастке «Сетевые подключения» подключить ВМ к сети; 

• В оснастке «Подключения дисков» установить связь между созданным диском и ВМ;

• В оснастке «Запуск ВМ» кликом запустить виртуальную машину.

Это видится крайне неудобным, особенно если выйти за пределы простого примера. Но формально на этом этапе еще можно сказать: «Пусть и неудобно, но работает». Теперь обсудим следующий вопрос — а работает ли?

ВМ под снос?

Terraform силен не своими возможностями сходить и что-то создать. Это можно сделать десятком других способов, тот же Ansible с этим вполне справляется. Сила Terraform в превращении «хотелки» в «план», составления списка действий на основе общего пожелания пользователя и его образа результата. Для этого Terraform реализует два больших высокоуровневых механизма:

• Автоматические вычисление зависимостей. Если виртуальная машина содержит диск, то перед созданием ВМ нужно создать диск. Это логично и подразумевается; 

• Автоматическое управление состоянием. Для уже созданного и администрируемого объекта Terraform  вычисляет минимальный и безопасный набор шагов по приведению его из имеющегося состояния А в запрошенное состояние Б. 

Разумеется, эти механизмы очень сильно зависят от качества данных, поставляемых провайдером (Откуда Terraform знать, как там в oVirt диски и сети с чем-то связаны?).

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

1. Создаем инфраструктуру из примера выше — ВМ, диск, сеть, запуск. Дополним объект ВМ указанием количества ядер и характеристик ЦП, чтобы было что редактировать в плане ресурсов — 1 сокет, 2 ядра, 1 поток на ядро.

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

3. Вносим некое изменение в конфигурацию ВМ по сценариям ниже из UI.  

4. Выполняем terraform apply  и ждем, что он восстановит описанную в манифесте картину.

5. В качестве эталонной ожидаемой реакции будем рассматривать пользовательский путь «все починить» из UI. 

В таблице отражаем, какой сценарий используем, что ожидаем от Terraform и что получаем в реальности:

Время вспомнить про те «две новые строчки», о которых в начале статьи предлагалось «пока не думать». Они определяют привязку ВМ к хостам:

Давайте упростим ВМ и посмотрим, что будет, если их не задавать.

Запускаем terraform apply, ВМ создается, отлично. А теперь еще раз вызовем terraform apply, ничего не меняя. 

Видим, что только что созданную ВМ нужно заменить. То есть уничтожить и создать заново. Почему?

1. Пользователь не задавал политику принадлежности и миграции ВМ. Он мог  выбрать кластер хостов, а дальше — пусть ВМ сама разберется; 

2. Код oVirt выставил стандартные параметры для новых ВМ (или взял из шаблона, хоть у нас он и задан как Blank);

3. Terraform видит разницу: он просил null, а там migratable; 

Что делать? Конечно, всю ВМ под снос вместе с данными.

Комментировать такое поведение Terraform непросто, а объяснять потом клиенту — еще сложнее.

Резюме

После описанных нюансов работы провайдера и перед тем, как мы начнем разбираться в причинах их появления, давайте остановимся и подытожим:

• Формально провайдер работоспособен: базовые операции с ним можно выполнять, некий уровень бизнес-полезных работ на нем можно проводить;

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

• Реализация ключевых особенностей Terraform — отслеживание состояний и зависимостей — фактически сломана.

При этом у провайдера есть пользовательская база. Это правда, он существует давно, им пользуются, но схема типового применения выглядит примерно так:

• Пользователи проходят путь, примерно схожий с описанным выше путешествием по граблям; 

• Четче формулируют ТЗ, определяют ключевые для бизнес-задачи ресурсы и поля;

• Силами разработчика реализуют точечные проверки необходимых полей;

• Игнорируют любые другие поля за пределами описанного процесса. 

Можно ли так жить? Да. Удобно ли? Нет. Можно ли это легко масштабировать? Конечно же, нет.  В следующей статье цикла мы рассмотрим причины, по которым terraform-provider-ovirt оказался там, где оказался, и перейдем к рассказу о проектировании нашего собственного провайдера и инструментах, которые помогли нам обойти «тысячу и одни грабли».