Опять же, еще один юзкейс из опыта. Есть та же

роль настройки некого приложения, оперирующая неким набором начальных данных. Используется эта роль на разные проектах разными командами и работает в существенно разном окружении. В одном случае роли на вход нужны данные, получаемые из одного хранилища секретов, скажем, а в другом проекте - из совсем другого. Проекты друг о друге не знают почти ничего и общей кодовой базы почти не имеют (кроме некоторых универсальных ролей). Как прикажете реализовать ваш подход с зависимостями в этом случае?

Никак, зависимостями тут не решишь. Надо хранить факты, в которых описано состояние. Ну или проводить декомпозицию на более мелкие рольки.

Никакие факты не помогут в конкретном случае. Условно говоря, нам нужно сделать ряд запросов по API в определенное приложение и получить оттуда набор неких данных, которые потом и скармливаются универсальной роли, которая отвечает за конфигурацию. Хранить эти факты нигде не нужно, они короткоживущие и привязанные к конкретной сессии сценария.

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

Вот ещё источник для вдохновения (но я не со всем там согласен) https://docs.debops.org/en/stable-3.0/dep/dep-0002.html

Вот! Собака зарыта в антипаттерне "универсальная роль".

Всякое бывает. Иногда наоборот - мы делали роль, которая покрывает максимальное число существенно разных сценариев использования и имеет кучу ветвлений. Ее поддерживать может быть проще, чем 100500 отдельных ролей, которые делают по сути одну и ту же вещь

Лукап? 🤔

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

Ну, ты про секретменеджеры упоминал, и там обычно лукап. Но да, имхо депенденси тоже зло Явное > неявного

Нормальный, кто ж спорит. Этот набор данных записывается в структуру (факт). Если вторая роль этот факт явным образом не находит -- то падает с визгом. Всё по бест практис))

Тут нет антипаттерна. Это, собственно, и есть основной юзкейс для роли, которая сделана для максимального переиспользвания

Даже в программировании переиспользование с универсальностью не коррелируют (или коррелируют отрицательно). Юникс-утилиты минимально универсальны и максимально переиспользуемы.

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

Это не так. В современном линуксе куча дублирующего функционала даже в самых базовых инструментах

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

так никто и не говорит, что весь современный линукс -- юниксвеен.

Не очень понятно, что для вас тут «явным образом». И чем вариант с конкретным кодом, который задает динамически входные параметры, не явный.

Этого юниксвея не было по сути никогда. Это красивая идея, но на практике реализуется все чуть иначе

В coreutils не слишком много универсального или дублирующегося функционала

Oh, really?

Явным образом означает то, что все возможные входные параметры описаны в argument_specs и, тем самым, проверяются на наличие/отсутствие/корректность (типы, например) до начала выполнения всех тасков роли.

И как их описание поможет в случае, если если их указать неправильно?

В смысле как поможет? Роль упадёт с жалобой на некорретные входные параметры. Т.е. именно то, что и нужно. Никакого непредвиденного поведения.

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

каким образом первая роль задаёт параметры для второй? Вторая роль напрямую читает переменную, которую сформировала первая?

В смысле - каким образом? Делает set_fact и задает нужный набор переменных, грубо говоря. Эти переменные уже используются второй ролью как входные параметры.

Т.е. вся суть спора в том, что вы передаёте переменную, а я бы записал данные в файлик. И мой подход применим в вашем случае, если заменить прямую передачу переменной (при обязательном помещении ролей поочередно в один плей) записью структуры данных в факт. Всё верно?

Верно. Просто в конкретных случаях запись в файл даже не нужна - это лишний шаг и дополнительная сущность, требующая для роли дополнительных прав, например, и знания конкретных условий применения и условий окружения. Я могу написать роль, которая будет лукапить данные и задавать динамические параметры для почти любой роли. А для записи в файл мне нужно будет знать путь, иметь соответствующие права на эту запись в произвольной инфраструктуре и еще знать - под какими учетными данными и с какими правами записывать файл.

Для передачи данных между ролями в ансибле есть стандартизованное место -- /etc/ansible/facts.d. В остальном -- не вижу смысла продолжать, всё уже обсудили. В целом, вы подтвердили общую применимость моих подходов :-)

Это место, которое используется, как стандартный источник фактов для ансибла. Это никак не означает, что в произвольном окружении этот путь вообще существует и доступен произвольному пользователю для записи

Что за место такое, в котором нельзя создать вышеуказанный путь?! Даже в самом маленьком контейнере есть /etc

/etc есть, а вот запись туда кому-то кроме рута доступна далеко не всегда. И права на создание директорий тоже есть далеко не всегда. В том же контейнере файловая система может быть вообще read-only

Ваши паттерны использования ансибла отличаются от общепринятых (обычно всегда можно сделать become; если нельзя -- присвойте этому каталогу нужные права заранее, когда можно). А на r/o ансибл вообще нет смысла запускать, что ему там делать, если r/o.

Рутовая система r/o, пользовательская - доступна для записи. Пакер тот же, например, так работает в ряде сценариев

Да нормально тут все. На любую ситуацию и пример, можно будет ответить ну это есть и вот это не надо. В целом же подход абсолютно нормальный. То, что люди творят порой лютую дичь, не означает, что это дичь для них :)