Cotea: программный контроль исполнения Ansible

Спасибо за отзыв. Cotea расширяет возможности Ansible, добавляя новые функции, а не просто копирует то, что уже есть. Инструмент позволяет управлять исполнением Ansible прямо из программы на Python, таким образом, можно проверять и регулировать процесс после каждого таска, используя все возможности Python. В сравнении с этим, команда ansible-playbook - 'черный ящик', без возможности вмешательства в процесс.

Также благодаря cotea и gocotea, существенно проще встраивать Ansible в программы на Python и Golang, потому что не нужно запускать внешние команды через exec, что часто может быть неудобно и неэффективно.

не проще ли написать просто дополнительный модуль/плагин для ансибла

Не всегда у разработчиков есть время на это. Иногда им просто нужно быстро обработать результат (например, просто stdout) от предыдущего таска и двигаться дальше. Cotea дает возможность легко обрабатывать эти данные с помощью Python, а не ограничиваться возможностями Ansible.

Ансиблом и так можно управлять из программы на Python с помощью нативного API.

Вынужден Вас расстроить, но без cotea этого делать нельзя)
Нет Python API, позволяющего запускать конкретный таск либо плей, добавлять новый таск или Ansible-переменную по ходу выполнения и тд (всё то, что предоставляет cotea).
Если Вы про страничку Python API документации Ansible, то там плейбук запускается разом, как и при запуске Ansible из командной строки. То есть, возможности контроля между тасками не предоставляется. Также там сказано, что это API для внутреннего использования и external use is not supported by Ansible. И далее приводится ссылка на ansible-runner, который упоминался в статье (он также не предоставляет возможности программного итерирования по таскам).

Не очень понятно, на чем именно экономится время и в каком месте?

Разработка Ansible модуля - это куда более общая задача, требущая бОльшего времени разработки, чем, к примеру, парсинг строки в конкретной ситуации. При написании playbook-ов, разработчики обычно выкручиваются, используя существующий функционал Ansible, т.к. это всё равно быстрее написания и отладки собственного модуля. Cotea же предлагает выкручиваться, используя всё богатсво Python;)

Там просто пример с иллюстрацией. Все возможности там есть, если смотреть на код.

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

Этих возможностей там нет)))
Их не было 1.5 года во время разработки cotea и их нет и сейчас. Напомню, что речь идёт о специальных интерфейсах для внешнего использования, по типу запустить плей, таск, добавить переменную. Подобных интерфейсов вы там не найдете, их всё равно необходимо было бы писать вручную, и их код содержал бы кучу манипуляций внутренними объектами Ansible, в не совсем естественном для них ключе. Именно поэтому было принято решение встраиваться в Ansible декораторами (для чего мы провели немало времени в изучении исходного кода Ansible, ссылку на репозиторий которого Вы любезно предоставили).
Ну а если Вы вдруг знаете это заветное место в репозитории, которое никак не задокументировано и где объявлены те самые интерфейсы, то мы конечно же будем рады ссылкам.

При чем тут парсинг строки?

В чем преимущество велосипеда в виде cotea по сравнению с написанием собственного модуля? Можно более конкретный пример увидеть?

Возьмём пример, описанный в статье. Нам нужно было понимать, запущен ли уже конкретный podman контейнер. Модуля для podman в той версии Ansible на тот момент не существовало. Для решение же задачи достаточно распарсить stdout команды podman ps.
В этой ситуации, разработчик плейбука может написать свой модуль для podman или просто распарсить вывод podman ps и пойти дальше. Очевидно, второй вариант быстрее, да и к тому же, официальный модуль для podman рано или поздно появиться.
И в случае со вторым вариантом, cotea позволяет решать такие задачи "в питоне", а не "в ансибле".

 Речь о написании обвязки типа той же cotea. 

Мы разрабатывали cotea по ряду причин, в числе которых контроль исполнения (итерирование по таскам), встраивание в другие системы (нужно было вызывать Ansible из Go) и возможности отладки. Реализованное API можно использовать, к примеру (и у нас есть это в планах), для создания полноценного отладчика Ansible в виде плагина к IDE, чего нельзя было сделать с штатным отладчиком Ansible, т.к. у него нет API и реализован он также с помощью декораторов. Пример с обработкой результатов таска - это лишь один из use case-ов.