всем привет Хочу насписать условие сравнения when: var1 is defined "" var1 == {{ ansible_hostname }}" - name: "templates copy " template: src: "{{item.src}}" dest: "{{item.dest}}" mode: "0664" backup: yes with_items: - { src: "12312.yml", dest: "{{ dest_dir }}12312.yml" } when: - var1 is defined - var1 == "{{ ansible_hostname }}" не работает финт ушами ansible_hostname, как можно обойти?

я видел там параметр checksum, но не совсем понимаю как его применить при сравнении

Согласен. Тогда как решение, можно сделать следующим образом: выделяете три таски в отдельный файлик update.yml: - name: get sha1 checksum stat: path: "{{ home_dir }}/repos/{{ item.id }}.zip" checksum_algorithm: sha1 with_items: - "{{ engines.components }}" register: local_sha - name: Read sha1 of defined engines on artifactory uri: url: "{{engines.url}}/{{item.group_id}}/{{item.id}}/{{item.version}}/{{item.id}}-{{item.version}}.zip.sha1" return_content: yes validate_certs: no with_items: "{{ engines.components }}" register: remote_sha - name: Download if new get_url: url: "{{engines.url}}/{{item.group_id}}/{{item.id}}/{{item.version}}/{{item.id}}-{{item.version}}.zip" dest: "/etc/{{item.id}}-{{item.version}}.zip" when: local_sha.stat.checksum != remote_sha.content а потом инклюдиде этот файл в цикле в основном плейбуке: - name: update components include_tasks: update.yml loop: "{{ engines.components }}”

Да элементарно. Берете чексумму с соурс ресурса (или откуда вы их там берете) и передаете в качестве аргумента модулю get_url

какой аргумент? есть checksum, но там: If a checksum is passed to this parameter, the digest of the destination file will be calculated after it is downloaded to ensure its integrity

Приветствую всех. Есть кто использует ansible для управления сетевыми железками? В частности ACL. Интересно на сколько это целесообразно и удобно?

У меня странный вопрос. Я пишу модуль ip_link, который может интерфейс создать, а может сделать up. У меня была идея иметь общий параметр state: [present/absent/up/down], где up/down пордразумевают present. Но при этом я точно не хочу "создавать" eth1 если его нет и мне сказали state:up. Но хочу создавать условный veth1. Выглядит как противоречие. Я могу up/down вынести как отдельный параметр (link_state), либо же оставить параметр state в present/absent/up/down, но добавить create: true/false. Оба меня не очень радуют. Как бы мне это противоречие разрешить?

У меня странный вопрос. Я пишу модуль ip_link, который может интерфейс создать, а может сделать up. У меня была идея иметь общий параметр state: [present/absent/up/down], где up/down пордразумевают present. Но при этом я точно не хочу "создавать" eth1 если его нет и мне сказали state:up. Но хочу создавать условный veth1. Выглядит как противоречие. Я могу up/down вынести как отдельный параметр (link_state), либо же оставить параметр state в present/absent/up/down, но добавить create: true/false. Оба меня не очень радуют. Как бы мне это противоречие разрешить?

ИМХО чтобы создать veth1, нужно так и указать veth1, а не додумывать, чего там хочется запускающему при наборе ключей. Соответственно, если eth1 нет, то выдавать ошибку, или каким-то еще ключиком задавать чтобы при отсутствии интерфейса создавать виртуальный.

@Lambot, ты не понял проблемы. Я могу сделать линк с типом veth (и назвать его eth0), но пользователь будет несколько растерян, потому что он ожидал, что ему железный eth0 поднимут. (т.е. так делать не надо).

@Lambot, ты не понял проблемы. Я могу сделать линк с типом veth (и назвать его eth0), но пользователь будет несколько растерян, потому что он ожидал, что ему железный eth0 поднимут. (т.е. так делать не надо).

Но не будет ли это слишком RTFM/WTF?

Т.е. варианты: - state: present/absent/up/down, а создание контролируется наличием type. Если интерфейса в системе нет, type нет, а требуют up - ломаться. - state: present/absent/none, link_state=up/down/none. Если none - не создавать, а только учитывать link_state.

есть немножко, но ансиблом сеть не ковыряю, жалко )

Главная проблема с state=present в том, что ошибка "нужен ещё и параметр type" будет только в runtime, потому что ansible не даёт зависимых параметров в описании параметров модуля. Там можно только type указать, required и choice.

А что этого нет в https://docs.ansible.com/ansible/latest/dev_guide/developing_program_flow_modules.html#argument-spec ?

Очень подходящая.

В принципе, в ансибле общепринято, что state - это present/absent. Это не выглядит как wtf для читающего. Для пишущего может быть чуть-чуть не очевидно, что создание задаётся через state. С другой стороны, я не вижу неоднозначности или wtf с state: present. Заодно можно потребовать, что если state: present, то должна быть вся информация, чтобы его (интерфейс) создать.

контрпримеры: systemd: name=service, masked=true daemon_reload=true, apt: update_cache=true

Полез за контр-примерами. Есть rmnet, который ethernet и физический интерфейс, но который можно создать и удалить. ip link add link DEVICE name NAME type rmnet mux_id MUXID