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

https://en.wikipedia.org/wiki/XY_problem

xyproblem.info

Sometimes I’ll even answer a user’s original question and then post a big write-up on why what they are trying to do is a bad idea. https://blog.mattbierner.com/10-years-stack-overflow-learnings/

Вы раскрывайте мысль что-ли

Вы раскрывайте мысль что-ли

1. Ты хочешь странного 2. Ансибл - не интерпретатор, хотя может почему-то таковым казаться. 3. Ещё раз: разберись с объектной моделью. Роль сама по себе - ничто. Хосты и некие их свойства, задаваемые через хостварс/групварс, наследуемые, перопредлеяемые и "сплющиваемые" перед запуском плейбука в словарь hostvars - всё.

Почему странного? Я хочу общие части кучи ролей вынести в одну.

Как выглядит первоначальная задача?

Она описана выше. Есть роли отдельных сайтов, у них есть большая общая часть

Она описана выше. Есть роли отдельных сайтов, у них есть большая общая часть

Вот эта общая часть и есть роль, а отличающиеся части - то, что нужно выносить в параметры этой роли.

Нет, это совершенно разные и никак не связанные наборы тасков

можно пример? очень сложно так обсуждать задачу без небольшой конкретики

Нет, это совершенно разные и никак не связанные наборы тасков

а по моему вопросу, я так понимаю, оптимального решения нет?

а по моему вопросу, я так понимаю, оптимального решения нет?

Поможет явная параметризация.

Поможет явная параметризация.

ужс, ну окей

Для одного сайта мне нужен Апач и пхп, для другого питон и монга, для третьего MySQL и перл. Но для каждого нужна одигаковая зависимость от nginx, конфиг для него, настройки мониторинга, статистики, ротации логов, доменов и т.д

С точки зрения "потом не стыдно показать кому-либо" - норм.

Коллеги, всем привет Снова я затупил со списками. Вопрос такоой: есть лист A B C D E , как бы его преобразовать в словарь, с интератором. то есть A:1 B:2 C:3 ну и тд?

Для одного сайта мне нужен Апач и пхп, для другого питон и монга, для третьего MySQL и перл. Но для каждого нужна одигаковая зависимость от nginx, конфиг для него, настройки мониторинга, статистики, ротации логов, доменов и т.д

Другой разговор. Здесь один сайт - один плей. А уже в плее вызываются нужные роли с нужными параметрами.

Другой разговор. Здесь один сайт - один плей. А уже в плее вызываются нужные роли с нужными параметрами.

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

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

В одном плейбуке может быть сколько угодно плеев.

А-а, вот это наверное правильное направление, спасибо

Коллеги, всем привет Снова я затупил со списками. Вопрос такоой: есть лист A B C D E , как бы его преобразовать в словарь, с интератором. то есть A:1 B:2 C:3 ну и тд?

Можно вместо словаря использовать расширенные переменные циклов: https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html?highlight=loops#extended-loop-variables И желательно лист сортировать перед передачей в loop.

Т.е. плей на сайт. Тогда, правда, другие общие вещи будут дублироваться. Когда Апач нужен нескольким сайтам

Т.е. плей на сайт. Тогда, правда, другие общие вещи будут дублироваться. Когда Апач нужен нескольким сайтам

Апач - роль. А в плее эта роль параметризуется.

Я не хочу её явно указывать. Мне нужен сайт, остальное меня не волнует. А он должен зависеть от всего что ему нужно.

При этом сайт с хостнеймом foo.org должен зависеть от апача с хостнеймом foo.org

В общем я понял идею - красиво не получится, придётся всё явно перечислять в отдельных плеях

Причём того что я хочу почти можно добиться через include_tasks, но там, понятно, не будет dependencies

Коллеги, всем привет Снова я затупил со списками. Вопрос такоой: есть лист A B C D E , как бы его преобразовать в словарь, с интератором. то есть A:1 B:2 C:3 ну и тд?

Если хочется jinja извращений - то есть ещё вариант: {{ dict(tlist|sort |zip(range(1,tlist|length+1)|list)) }}

Если хочется jinja извращений - то есть ещё вариант: {{ dict(tlist|sort |zip(range(1,tlist|length+1)|list)) }}

спасиьбо. Получилось чуть проще. 🙂 но ты навел на мысль

Для одного сайта мне нужен Апач и пхп, для другого питон и монга, для третьего MySQL и перл. Но для каждого нужна одигаковая зависимость от nginx, конфиг для него, настройки мониторинга, статистики, ротации логов, доменов и т.д

Ты перечисляешь наборы отдельных ролей.

В одном плейбуке может быть сколько угодно плеев.

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

Ты перечисляешь наборы отдельных ролей.

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

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

Роли вообще ничего не должны знать

В этом суть ролей

Я бы может и поверил, если бы не было dependencies, include и import

Я бы может и поверил, если бы не было dependencies, include и import

include и import - это для тасков больше

больше - не больше, есть конкретоно include_role и import_role

dependencies через meta есть, но это стрельба по ногам

больше - не больше, есть конкретоно include_role и import_role

Это конструкции плейбука

нет, это модули

нет, это модули

Я в курсе, кэп

Я о том, что их имеет смысл применять только на уровне плейбука

Роли должны быть независимыми для переносимости

Как только их обвешиваешь зависимостями - переносимость ролей теряется и получается просто большой монструозный плейбук под видом роли

Это не стрельба по ногам, это то как в моём понимании должно работать описание конфигурации. В соотстветствии с базовыми принципами DRY и SSOT

Это не стрельба по ногам, это то как в моём понимании должно работать описание конфигурации. В соотстветствии с базовыми принципами DRY и SSOT

В соответствии с базовыми принципами ты просто перечисляешь явно нужные роли в плейбуке - и все

Роли должны быть независимыми для переносимости

Если сайту нужен nginx - это факт от которого никак не уйти, и на переносимость он никак не влияет. Если его не указать в роли, значит только то что его нужно будет указать в другом месте. И там его можно будет забыть

Если сайту нужен nginx - это факт от которого никак не уйти, и на переносимость он никак не влияет. Если его не указать в роли, значит только то что его нужно будет указать в другом месте. И там его можно будет забыть

nginx ставится отдельной ролью

В соответствии с базовыми принципами ты просто перечисляешь явно нужные роли в плейбуке - и все

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

nginx ставится отдельной ролью

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

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

Никакое это не нарушение

Это как раз то, для чего и нужны роли

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

А это выстрел в ногу

Потому что в другой роли у тебя неявная зависимость

> Никакое это не нарушение Т.е. повторение это не повторение > А это выстрел в ногу Пошли на второй круг?

Потому что в другой роли у тебя неявная зависимость

В какой другой роли, от чего зависимость?

В какой другой роли, от чего зависимость?

Выше вы писали

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

По явной зависимости внутри роли. Не требуя явного указания в плейбуке.

> Никакое это не нарушение Т.е. повторение это не повторение > А это выстрел в ногу Пошли на второй круг?

Вам в любом случае нужно будет вызвать эту роль и указать это. Явно или неявно - без разницы

По явной зависимости внутри роли. Не требуя явного указания в плейбуке.

Явное лучше неявного

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

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

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

Что значит - «точно известно что ее нужна зависимость»?

Это и значит. Роль не имеет смысла и не может работать без другой роли.

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

Если зависимость внутри роли - это неявная зависимость

Нет, это явная зависимость

Это и значит. Роль не имеет смысла и не может работать без другой роли.

Тогда это не роль

И что это тогда, интересно?

И как вы определяете роль?

Это какой-то код, который вы по недоразумению считаете ролью

И как вы определяете роль?

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

Ну с моим определением это совпадает.

Роль как сущность никаких неявных зависимостей внутри себя содержать не должна

Иначе переносимость идёт лесом

Я уже написал почему это не так.

Я уже написал почему это не так.

Что не так?

Что не должна содержать зависимостей и это как-то влияет на переносимость.