Блог компании Southbridge
Системное администрирование
Серверное администрирование
DevOps
Комментарии 11
+2

Меж тем, локальные переменные (уровня task) для import_role переопределяют переменные для всей плей.


И это не баг. Это просто WTF, которое надо проглотить и радоваться.


Пример:


inventory:


host1: foo=1

play.yaml


- hosts: host1
  tasks:
    - debug: var=foo
    - import_role: name=somerole
      vars:
        foo: 2
    - import_role: name=somerole
      vars:
        foo: 3
    - debug: var=foo

(Внутри somerole такой же -debug: var=foo).


Догадайтесь, какие 4 числа будут выведены на экран? (Кандидаты из комбинации чисел 1, 2 и 3).

0
Все согласно доке:
docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

TASK [debug] *************************************************************************************************************************************************
ok: [localhost] => {
"foo": 1
}

TASK [somerole : debug] **************************************************************************************************************************************
ok: [localhost] => {
"foo": 2
}

TASK [somerole : debug] **************************************************************************************************************************************
ok: [localhost] => {
"foo": 3
}

TASK [debug] *************************************************************************************************************************************************
ok: [localhost] => {
"foo": 1
}


ansible --version
ansible 2.6.2
0
ansible --version
ansible 2.7.13

TASK [debug] *************************************************************************************************************************************************
ok: [localhost] => {
"foo": 3
}

TASK [somerole : debug] **************************************************************************************************************************************
ok: [localhost] => {
"foo": 2
}

TASK [somerole : debug] **************************************************************************************************************************************
ok: [localhost] => {
"foo": 3
}

TASK [debug] *************************************************************************************************************************************************
ok: [localhost] => {
"foo": 3
}


найс… что они там курят то?
0
замена статического импорта на динамический инклюд возвращает логику, но замедляет выполнение ;)
- hosts: host1
tasks:
- debug: var=foo
- include_role: name=somerole
vars:
foo: 2
- include_role: name=somerole
vars:
foo: 3
- debug: var=foo
+1

Дело не в том, как фиксить, а в том, что они сами себе противоречат.


Если vars выставляют переменные для всей плебуки, то почему одна роль получает два, а вторая три? А если она выставляет для "кусочка" (т.е. одно import_role), то почему она тогда затрагивает таски над import_role?


И так у них всегда.

0
Issue есть? можем там проголосовать чтобы быстрее отреагировали
+1

Так это репортить или нет?


Документация говорит, что это фича. Но я эту фичу не понимаю.


Since Ansible 2.7 variables defined in vars and defaults for the role are exposed at playbook parsing time. Due to this, these variables will be accessible to roles and tasks executed before the location of the import_role task.


https://docs.ansible.com/ansible/latest/modules/import_role_module.html


Т.е. если бы она в этом примере всем 3 сделала — я бы вздохнул и понял. (и всё равно приводил бы этот пример как идиотизм), но комбинация 3, 2, 3, 3 — это совершенно нелогично.


Баг или фича?

0
ну я думаю, что это все таки баг. В мозгах разработчика.

Потому что сначала при импорте ролей все переменные применяются и в итоге последнее значение записывается.
а потом при проигрывании опять для каждой роли применяются переменные…
и зачем они их применяют Джва раза — вот тут непонятное.

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

Не будут они это фиксить, иначе есть риск что у кого-нибудь сломаются плейбуки, отлаженные "с этим" багом.


К сожалению, ансибл похож на php — от рождения сломан во всех местах, и с каждым релизом яма все глубже, и можно только смириться. Выиграет фреймворк, кооторые сумеет заюзать модули ансибл, но будет иметь нормальную архитектуру и язык.

+1

Имхо есть шансы у Salt, особенно если появятся удобные средства модульного и интеграционного тестирования стейтов/формул. Да, есть плагин к kitchen — но это только интеграционное, и с multi-node там все грустно. И есть внутренняя система тестов — но если я правильно понимаю для тестирования своих стейтов их придется положить внутрь сальтовских исходников, что вообще за гранью...

+1
Я не использую import_role в том числе по таким причинам. Логичнее использовать конструкции вида include… — там все более предсказуемо.
Только полноправные пользователи могут оставлять комментарии., пожалуйста.