776166, Вы сами не видите, что ваш новый вариант описания - зацикливается ?
vars:
db_name: "{{ db_name }}"
по вашему описанию "В дочерней роли на базе этой передаваемой переменной должна определяться внутренняя переменная, которая уже будет использоваться.", а вы как будто определяете снаружи ту самую внутреннюю переменную, что у вас ставится в role/vars. и в role/vars она ещё раз пытается переопределиться.
Как уже указал mureevms, во первых, у переменных есть приоритет
а во вторых, ansible при попытке получить значение в цикле пытается разрешить значения до финального.
типа
prev_value = value
while True:
value = resolve_variables(value)
if value == prev_value:
break
prev_value = value
Если вы сильно навертите с одинаковыми именами, будет бесконечный цикл (может это именно он - ваша неизвестная ошибка)
а если таки придёте к какому-то результату, не факт что из длинной цепочки переходов вы не получите нечто типа "странной комбинации из названия родительской роли, названия переменной"
вообще, повторюсь, переменные ролей лучше бы определять в defaults/ и имена давать в виде rolename_variable_name
в идеале role/vars/ нужен для того, чтобы на ходу что-то менять. например, в зависимости от ОС или каких-то других параметров системы, собираемых через facts.
хорошим тоном при этом все внутренние переменные писать как _variable_name, чтобы у вас меньше было соблазна эти переменные пытаться ставить снаружи.
по крайней мере в этом случае гораздо легче понять, откуда ноги растут у странных комбинаций
Вы б поподробнее написали что "не работает"
Что хотели, что получили.
Можно debug внутри роли добавить чтобы разобраться
А то в вашем тексте я определения pg_name не вижу.
Может вы просто запутались в своих db_name/pg_name
Евгений, вы утверждаете что у вас на vmware сеть 1.1.1.1/30
А ещё у вас "Есть выделенная (Vlan Routed) 2.2.2.112/29 для виртуалок"
так вот это Vlan Routed - делается (как я предполагаю) на каком-то свиче, в который воткнут как провод от провайдера, который даёт вам 2.2.2.2, так и ваша сеть 1.1.1.1
Vlan routed в моём понимании означает, что тот проводок, что идёт от провайдера вы запускаете, скажем, во vlan 10, а ваша собственная сеть живёт в vlan 20
и на порту, в который воткнут esxi, у вас стоит что-нибудь типа Access20, а надо trunk, то есть разрешить на порту все гуляющие в вашей сети vlan
в разных свичах это может называться по-разному
Евгений, Ничего не меняется :)
кроме того, что вам не нужно заводить дополнительный tcp/ip stack, stack создаётся сам под vMotion или другие vmkernel операции
Dewz, Ну я бы упростил до одного цикла и не повторялся с Get-ADUser,
вы всё что надо уже получаете на второй строчке, только зачем-то берёте из этого всего только логин, да ещё и через invoke-command, которая тут совершенно лишняя
Хотя, на самом деле мне непонятно откуда вообще берутся юзеры с неустановленными этими параметрами.
Может это всё надо делать прямо там, где они создаются ?
neme, Слишком абстрактный вопрос. На него можно дать только такой же абстрактный ответ.
Где-то в сети, где лежат эти документы, можно получить их список (всё тем же Invoke-WebRequest). полученный html отпарсить, Из полученного списка по каким-то критериям выбрать нужный, запросить....
Xibalba3, готовых не встречал
но основная идея в том, что надо
брать квоту, основанную на $mailbox.UseDatabaseQuotaDefaults
если истина - квота от базы, если нет - от юзера
$database.ProhibitSendQuota или $statistics.DatabaseProhibitSendQuota
против
$mailbox.ProhibitSendQuota
по вашему описанию "В дочерней роли на базе этой передаваемой переменной должна определяться внутренняя переменная, которая уже будет использоваться.", а вы как будто определяете снаружи ту самую внутреннюю переменную, что у вас ставится в role/vars. и в role/vars она ещё раз пытается переопределиться.
Как уже указал mureevms, во первых, у переменных есть приоритет
а во вторых, ansible при попытке получить значение в цикле пытается разрешить значения до финального.
типа
Если вы сильно навертите с одинаковыми именами, будет бесконечный цикл (может это именно он - ваша неизвестная ошибка)
а если таки придёте к какому-то результату, не факт что из длинной цепочки переходов вы не получите нечто типа "странной комбинации из названия родительской роли, названия переменной"
вообще, повторюсь, переменные ролей лучше бы определять в defaults/ и имена давать в виде rolename_variable_name
в идеале role/vars/ нужен для того, чтобы на ходу что-то менять. например, в зависимости от ОС или каких-то других параметров системы, собираемых через facts.
хорошим тоном при этом все внутренние переменные писать как _variable_name, чтобы у вас меньше было соблазна эти переменные пытаться ставить снаружи.
по крайней мере в этом случае гораздо легче понять, откуда ноги растут у странных комбинаций