Но для какой-то конкретной роли нет смысла использовать default и vars

Ну и да, там вон говорят дока есть.

Но для какой-то конкретной роли нет смысла использовать default и vars

Для какой-то, возможно, и есть. Разный смысл же

?

У меня бывает, что и то и то есть

А зачем?

Вот ровно за тем

Два одной и той же переменной смысла правда нет.

Если есть в vars, то из defaults уже точно не заполнится

Но иногда что-то надо и в defaults положить

У меня другой вопрос, зачем в vars класть?

defaults Чаще всего для обеспечения обратной совместимости.

Ну, кстати, да

У меня другой вопрос, зачем в vars класть?

Как так зачем? Чтобы переменную установить. Рассчитать специфичную несколько раз повторяемую в роли переменную, которая вычисляется из контекста

а почему в defaults ее неположить?

Они отличаются только приоритетом

а почему в defaults ее неположить?

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

Они отличаются только приоритетом

Только между ними внешний контекст

Только между ними внешний контекст

Вот это я не понял

Что будет, если в контексте уже установлена такая переменная раньше, в другой роли?

Ну, ты можешь поставить переменную, которая выше vars по приоритету

И тоже все сломать

Ну, ты можешь поставить переменную, которая выше vars по приоритету

А вот этого я не понял

:-)

vars перезапишет значения, если они раньше выставлены были

нет

Иди доку читай и пробуй

http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Но да, сложно вызвать случайно :-)

Иди доку читай и пробуй

Грубо :-)

Консоль только

Ну и про коннекшен

Таким образом нет такого места в плейбуке, которое круче vars

исторически переменные роли хранились в vars. В версии 1.3 добавили defaults. С тех пор и осталось два каталога с одинаковой функцией: http://devdocs.io/ansible/playbooks_roles

исторически переменные роли хранились в vars. В версии 1.3 добавили defaults. С тех пор и осталось два каталога с одинаковой функцией: http://devdocs.io/ansible/playbooks_roles

Она не одинаковая

согласен, не одинаковая - приоритет разный

Таким образом нет такого места в плейбуке, которое круче vars

А в 2 похоже и консоль не поможет

согласен, не одинаковая - приоритет разный

Они просто на двух концах пищевой цепи

Грубо :-)

Нет. Честно

?

Нет. Честно

Ты подрузамеваешь, что я не читал доку, но я ее читал и знаю, что есть переменные, приоритет которых выше, чем role vars

Ты подрузамеваешь, что я не читал доку, но я ее читал и знаю, что есть переменные, приоритет которых выше, чем role vars

Какие?

role and include vars block vars (only for tasks in block) task vars (only for the task) extra vars (always win precedence)

Блок и таск внутри роли

Да, консоль, но это вне плейбука

Таким образом снаружи роли внутри плейбука ничего такого нет.

Те ничто во внешнем yml не может перетереть vars

extra vars это вообще жесткий хак, который очень много всего может сломать, если им такие переменные выставлять:)

Его приоритет собственно и нужен чтобы внедриться внутрь какой-нибудь роли и нахачить поведение

Ты подрузамеваешь, что я не читал доку, но я ее читал и знаю, что есть переменные, приоритет которых выше, чем role vars

Чо молчим

Детей ужином кормлю, извини

А мои гуляют

roles: - role: test var1: 'outside'

Вот так можно, но явно надо вызвать

cat roles/test/tasks/main.yml - name: debug debug: var: var1

cat roles/test/vars/main.yml var1: inside

TASK [test : debug] ************************************************************ ok: [localhost] => { "var1": "outside" }

roles: - role: test var1: 'outside'

Чот я сомневаюсь... Хотя, оно же типа тоже role var...

пацаны, допишите линтер а ?

пацаны, допишите линтер а ?

Шта?

дефолты в этом смысле гораздо проще испортить, я с тобою согласен

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

Чот я сомневаюсь... Хотя, оно же типа тоже role var...

Я толтко что прогнал :-)

и не ругается. а вы тут такие бестпрактисы описываете

ansible-playbook --version ansible-playbook 2.1.1.0

дефолты в этом смысле гораздо проще испортить, я с тобою согласен

Так там просто наоборот, их не надо портить, они дефолты:)

ERROR: S client not available

Я имею в виду, случайно

https://github.com/willthames/ansible-lint

вот этот вот

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

Сейчас дотренирую нейросеть и выложи в паблик

Вообще, там не линтер нужен. Ансиблу как и js реинкарнация только поможет

а то я как лох {{ blabla | default(10) }}

- include_vars: "{{ ansible_os_family }}.yml"

Мало использоваемый случай

Но полезен

- include_vars: "{{ ansible_os_family }}.yml"

Только 2+

Вообще, там не линтер нужен. Ансиблу как и js реинкарнация только поможет

я думаю его гибкость является не только сильной стороной :-)

Мало использоваемый случай

совсем не мало

совсем не мало

Ну у нас тоже нет

Сделаешь средство пожеще, и им пользоваться невозможно будет - шаг вправо, шаг влево - нифига не работает

Просто у других мало видел

Я шефом пользовался пару лет

Ансибл просто великолепен

Люди, что уходили с папета на шеф, говорили, что шеф - великолепен

Сольта только не видел, но, видать, уже и не увижу

Люди, что уходили с папета на шеф, говорили, что шеф - великолепен

транзитивность отношений под вопросом

Ansible - нестабильное говно, но это лучшее, что у нас есть

Ты не видел другого нестабильного говна :-)

Ansible - нестабильное говно, но это лучшее, что у нас есть

Он легок в понимании по этому норм

Да, он гораздо проще для старта, чем все остальное

Ты не видел другого нестабильного говна :-)

Ой... Чего я только не видел

Я не хочу этого знать ;-)

Ansible - нестабильное говно, но это лучшее, что у нас есть

+1

Да, он гораздо проще для старта, чем все остальное

не сильно проще чем солт например

не сильно проще чем солт например

Правда?

ну у меня проблем не возникло ни с тем ни с этим

только вот в солте нихуя модулей нету