щас будет 500раз по кругу

Давайте без этого нытья, пожалуйста.

А какой из авторов роли виноват? Который сделал register или который в var написал?

а какие не простые? GUID генерить для префикса?

а какие не простые? GUID генерить для префикса?

мне нравится. action: module '{{ v_2b5faf3a_3492_11eb_8f76-c3ea7e595ed2 }}' args: '{{ v_373b2866_3492_11eb_95de_d3c2cb1b42d3 }}' register: '{{ v_3d9171fc_3492_11eb_a6ce_33816f354bd6 }}' loop: ' {{ v_56691086_3492_11eb_8926_771b6adf7ba5 }}'

Который использует в роли переменную вида user

Т.е. у нас есть два варианта: 1) Потребовать ото всех использовать только сложные имена 2) Не создавать условия при которых такие проблемы возникают.

Не нужно доводить до абсурда.

мне нравится. action: module '{{ v_2b5faf3a_3492_11eb_8f76-c3ea7e595ed2 }}' args: '{{ v_373b2866_3492_11eb_95de_d3c2cb1b42d3 }}' register: '{{ v_3d9171fc_3492_11eb_a6ce_33816f354bd6 }}' loop: ' {{ v_56691086_3492_11eb_8926_771b6adf7ba5 }}'

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

сделать на этом профайлере линтер и падать

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

Невозможно, include'ы и перменные с именами переменных всё сломают.

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

ты не сдавайся. нужно "просто" поработать ещё чуток

Эм, задача остановки полнорекурсивных функций не разрешима.

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

Невозможно, include'ы и перменные с именами переменных всё сломают.

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

Хочешь смешную ансибл-байку? Роль clickhouse'а (которая AlexeySetevoi/ansible-clickhouse) одно время грузила переменные динамически по имени дистрибутива. И был файл Ubuntu.yaml, а в переменной было значение ubuntu. В зависимости от ОС контроллера оно либо работало, либо нет. Потому что у макоси регистронезависимая файловая система, а у линукса - зависимая.

Динамические имена переменных - зло. Именно по такой причине.

Хочешь смешную ансибл-байку? Роль clickhouse'а (которая AlexeySetevoi/ansible-clickhouse) одно время грузила переменные динамически по имени дистрибутива. И был файл Ubuntu.yaml, а в переменной было значение ubuntu. В зависимости от ОС контроллера оно либо работало, либо нет. Потому что у макоси регистронезависимая файловая система, а у линукса - зависимая.

И что эта байка должна нам сказать? Что автор роли плохо продумал работу с регистрами переменных?

И что эта байка должна нам сказать? Что автор роли плохо продумал работу с регистрами переменных?

Это всего лишь частный случай от общей динамики (include'ов). В целом, как только мы получаем тьюринг-полный язык, анализировать его становится невозможно. Особенно, в контексте jinja.

что есть еще один корнеркейс который надо предусмотреть в линтере же

Ты не можешь линтером заглядывать в переменные. Оно инклюдило как include_vars: {{ ansible_что-то_distro }}

Ты не можешь линтером заглядывать в переменные. Оно инклюдило как include_vars: {{ ansible_что-то_distro }}

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

смотря каким линтером. но поинт понятен да. опять же и снова профайлер на стейдже

Профайлер на стейджинге просто не выполнит все case'ы. Статический анализ языка, в котором можно сделать template файла, а потом его же include, невозможен.

Профайлер на стейджинге просто не выполнит все case'ы. Статический анализ языка, в котором можно сделать template файла, а потом его же include, невозможен.

Еще раз. Твой исходный пойнт о том, что если у тебя попадутся одинаковые служебные переменные в разных ролях, то все сразу сломается - невалиден. Потому что роли не выполняются одновременно.

find . -type f|xargs --verbose cat cat ./play.yaml ./role2/tasks/main.yaml ./role1/vars/main.yaml ./role1/tasks/main.yaml --- - hosts: localhost gather_facts: false roles: - role1 - role2 --- - set_fact: foo: fact - debug: var=foo --- foo: 1 --- - debug: var=foo

В зависимости от порядка role1/role2 в play поведение role1 меняется.

Как именно оно меняется?

проще просто перестать требовать reusable role, признать, что они имеют смысл только в рамках плейбуки и тестировать плейбуки. Линтеры это хорошо, но культ ролей при никудышном механизме interface enforcing - это просто трата времени и нервов.

не проще. проще придерживаться префиксов. это проще.

да, это как обычно требует name convention. где его не требуют ?

А потом у тебя есть роль clickhouse и роль clickhouse_user. В clickhouse есть перменная clickhouse_user_main, а в clickhouse_user есть переменная clickhouse_user_main, и значат они разное.

Не совсем понял. Вот у меня в vars у роли вычисляется переменная user. Хорошая такая роль, с 100500 инклюдами, которая поддерживает windows 12.04 и macos 6, а так же freebsd buster. Человек, пищущий плейбуку берёт роль и радуется - как хорошо всё работает. А потом он устанавливает ещё одну роль, в которой написано: - name: get user register: userбум. Сломалось. Не там, где ожидалось. Кто виноват? Никто. Кто это жрёт? автор плейбуки.

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

А потом у тебя есть роль clickhouse и роль clickhouse_user. В clickhouse есть перменная clickhouse_user_main, а в clickhouse_user есть переменная clickhouse_user_main, и значат они разное. Простите за повтор.

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

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

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

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

Вместо того, чтобы реализовать приватные переменные внутри (как у всех языков программирования), сделали глобальный namespace образца zx-basic. Это последний язык программирования, в котором в go sub в подпрограмме нельзя было иметь приватных перменных.

фиг знает :) в ролях может и нет а в плейбуках есть

Вот только Ansible - это не язык программирования

Вот только Ansible - это не язык программирования

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

У меня плейбуки не перегружены хренью, там только запуск ролей и максимум, что я добавлял, это env и set_fact с when для сложной логике

это всё зависит от масштаба же. пока оно работает — оно работает. но когда нет оно печально.

Поговорка, что Ансибл - это не язык программирования, это не его достоинство, а суммаризация его свойств. Он настолько плох в программировании, что "не надо программировать на Ансибле".

200 машин и оно работает и работает как часы

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

я наступал в нейминг. мне было больно но не горело так как у @amarao