Ansible-коллекции для отечественного железа: тестируем YADRO Vesnin

Три независимые команды почти одновременно выложили в Ansible Galaxy community-коллекции для управления отечественным железом. community.yadro - для серверов YADRO Vesnin и Vegman, community.kraftway - для маршрутизаторов и коммутаторов Kraftway, community.aquarius - для серверов Aquarius Server T50 D48. Выглядело это немного как сговор, хотя авторы в разных чатах уверяли, что просто «совпало».

Нам это было актуально: в парке у нескольких клиентов стоят YADRO Vesnin, управление которыми до сих пор шло через BMC-веб-интерфейс и самописные shell-скрипты поверх IPMI. Автоматизировать это через Ansible хотелось давно - теперь появился повод попробовать готовое.

Что внутри community.yadro

Коллекция покрывает три основных класса задач:

• Управление через Redfish. Модули yadro.bmc_power, yadro.bmc_firmware, yadro.bmc_network обёртывают Redfish API BMC. Основа - ansible.builtin.uri под капотом, но с нормальной обработкой ошибок и идемпотентностью. Это уже не «curl в shell-task».
• Инвентаризация оборудования. Dynamic inventory plugin yadro.inventory умеет опрашивать BMC по списку адресов и возвращать host vars с серийниками, версиями firmware, статусами физических дисков.
• Управление BIOS-настройками. Модуль yadro.bios_config позволяет устанавливать и проверять параметры BIOS через Redfish Attribute Registry. Именно здесь всё становится интереснее.

Что реально работает

На тестовом стенде из четырёх YADRO Vesnin серверов мы прогнали несколько сценариев.

Power management через BMC встал без вопросов: graceful shutdown, hard power off, power on, reset - всё работает, идемпотентность корректная. check_mode тоже ведёт себя правильно - не меняет состояние, отдаёт what would change. Для нас это важно: плейбуки на power management обязаны нормально отрабатывать в dry run прежде чем касаться продуктивного железа.

Dynamic inventory работает приятно. Прогнали на двенадцати хостах - все опросились, host vars заполнились корректно. Плагин принимает список CIDR и параллельно опрашивает все адреса, что на широком диапазоне ощутимо быстрее последовательного обхода.

Firmware update - проверили только чтение текущей версии и upload образа в стейджинг-зону BMC, до применения не доходили: это продуктивные серверы, обновление firmware по плейбуку без дополнительного согласования мы не запускаем. Механика выглядит разумно, но подождём, пока кто-то в сообществе опубликует результаты полного прогона.

Где коллекция требует доработки

yadro.bios_config - главная точка боли. Модуль работает через Redfish Attribute Registry, и YADRO Vesnin возвращает имена атрибутов в нотации, которая отличается от того, что задокументировано в коллекции. Конкретно: несколько параметров, связанных с Hyper-Threading и NUMA topology, в Registry лежат под другими именами, чем в примерах из README. В результате задача завершается с ok, но атрибут не меняется - коллекция тихо пропускает неизвестный ключ вместо того, чтобы выдать ошибку. Это поведение опасно: playbook зелёный, но на деле конфигурация не применилась.

Мы разобрали это через yadro.bmc_raw_request (тоже есть в коллекции) - сделали прямой GET на /redfish/v1/Systems/1/Bios и сверили имена атрибутов. Несоответствие нашлось, мы написали issue в репозиторий на GitHub с конкретными именами атрибутов с нашего железа и версией firmware BMC.

Обработка таймаутов при firmware upload. На медленных out-of-band сетях (у одного клиента BMC-интерфейс изолирован и доступен через jump-хост с ограниченной полосой) модуль firmware upload падает по таймауту без retry. Стандартный async/poll через Ansible тут работает, но это неудобно - нужно оборачивать вручную. В issue это тоже упомянули.

Документация примеров. README содержит примеры для Vesnin, но все они написаны под одну конкретную версию firmware. У нас firmware на стенде была другой, и несколько переменных оказались deprecated. Не критично, но потратили время на поиск.

Как контрибьютим баг-репорты

Все три коллекции живут на GitHub под /community. Для community.yadro мы создали два issue: одно с подробной воспроизводимой последовательностью по проблеме с bios_config, второе - feature request на retry-механику для firmware upload.

В репозитории коллекции есть шаблон issue, который просит указать версию коллекции, версию Ansible, версию firmware BMC и вывод с ANSIBLE_DEBUG=1. Мы прошли по этому шаблону - авторы ответили в течение суток и подтвердили оба бага. Pull request от нас пока не открывали: хотим сначала увидеть, как авторы намерены решать проблему с атрибутами, прежде чем предлагать свой вариант fix.

Где это уместно

Коллекции находятся в состоянии community, не certified. Это значит нет поддержки от вендора, нет SLA на обновления, тестирование силами авторов и того, кто присылает баг-репорты. Для production-управления критичными настройками железа - нужно держать это в голове.

Для автоматизации inventory, мониторинга состояния, power management в рамках managed-сопровождения это уже применимо - с проверкой через check_mode и явным pin на версию коллекции. С bios_config пока аккуратно: доверяй, но верифицируй через прямой Redfish-запрос после применения.

Kraftway и Aquarius пока не тестировали - если на стендах окажется нужное железо, дадим знать.