debug: msg: "{{file_check | to_nice_yaml }}"

Так же валится с 'dict object' has no attribute 'stat'

Посмотри что file_check

debug: msg: "{{file_check | to_nice_yaml }}"

А почему не debug: var: file_check ?

А почему не debug: var: file_check ?

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

Подскажите как правильно проверять сущестование файла - stat: path: "{{ file }}" register: file_check - include: lala.yml when: file_check is defined and file_check.stat.exists == True Если файла нет, то file.stat.exist выдает ошибку

file_check вы итак записываете в прошлом таске, нкт необходимости проверять его объявление, можно просто file_check.stat.exists | bool

И дальше таск должен исполниться, если есть

when: file_check.stat.exists | bool

Подскажите как правильно проверять сущестование файла - stat: path: "{{ file }}" register: file_check - include: lala.yml when: file_check is defined and file_check.stat.exists == True Если файла нет, то file.stat.exist выдает ошибку

Какую ошибку?

Так же валится с 'dict object' has no attribute 'stat'

Это

Это

Ты содержимое посмотрел?

Еще нет

Это

А переменная, которую вы в path подставляете, существует вообще?

А переменная, которую вы в path подставляете, существует вообще?

То есть файл по ней? Не всегда. Может быть, может не быть

То есть файл по ней? Не всегда. Может быть, может не быть

Не, файл понятно. А сама переменная точно задана?

Да

Тогда никакой неопределенности быть не может

У вас права есть на тот путь, который вы проверяете?

Да, конечно

Выведите дебаг выхлопа

А, не

Стоп

Минутку

Да, покажите выхлоп

Что-то странное у вас. Такого быть не должно

Вообще нет ансибла в репах :)

Забавно. Учитывая, что один из redhat экзаменов почти полностью про ансибл

Минутку

У вас опечатка, вы проверяете file, а таском выше register: file_check

У вас опечатка, вы проверяете file, а таском выше register: file_check

При чем тут это. В переменной file хранится путь к файлу, а в file_check результат проверки

При чем тут это. В переменной file хранится путь к файлу, а в file_check результат проверки

В исходном сообщении не вижу объявления переменной.

file_check is defined неправильное условие

Почему?

В исходном сообщении не вижу объявления переменной.

а зачем оно?

Почему?

Даже если файла нет, то оно будет defined

Условие правильное, а смысла в нём нет

Выведите дебаг выхлопа

Кажется я понял. - stat: path: "{{ file }}" register: file_check здесь я не дописал when: ..... И как раз там стоит еще одна проверка, и переменная file_check как раз и не создается в этот момент

Если смысла нет, то оно неправильное, имхо

Кажется я понял. - stat: path: "{{ file }}" register: file_check здесь я не дописал when: ..... И как раз там стоит еще одна проверка, и переменная file_check как раз и не создается в этот момент

А, ну вот и ответ

У вас просто не вызывается модуль stat и не создается переменная

Надо полный код приводить

Я ожидал, что он должен закончить проверку на моменте с defined

Надо полный код приводить

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

Ну и локализовал)

Спасибо всем за наводящие вопросы

var is defined - проверка на то, что такая переменная объявлена вообще, верно?

Парни, у меня из j2 собирается json. Как можно валидировать этот json? Структуру. Просто если невалидный json заедет на таргет хост то я уеду в глухие леса в мешке

var is defined - проверка на то, что такая переменная объявлена вообще, верно?

Да, при этом она может быть пустой

Парни, у меня из j2 собирается json. Как можно валидировать этот json? Структуру. Просто если невалидный json заедет на таргет хост то я уеду в глухие леса в мешке

Постарайтесь не темплейтить джсон это будет больно

Лучше возьмите jsonnet

Если таки никак делаете словарь и разворачивайте через {{my_dict | to_json}}

Спасибо, есть пища для размышления

Постарайтесь не темплейтить джсон это будет больно

Вы быстро утомитесь делать comma control

Я вот утомился https://code.getnoc.com/noc/noc/blob/master/templates/ddash/dash_mo.j2

Всем првет. Немного не понимаю один момент. Запускаю плейбук: ansible-playbook develop.yml --extra-vars "{'app': {'tag': '0.1.0'}}" -t test На выходе получаю: FAILED! => {"msg": "'dict object' has no attribute 'data_dir'"} Запускаю без --extra-vars и все отрабатывает нормально. Куда копать?

В defaults простая конструкция: app: tag: latest

У меня выше похожая проблема была

--extra_vars я обычно @path/to/yml делаю

Такое ощущение что он слепить не может

У меня выше похожая проблема была

Я на старом банке рабочей такие конструкции запускал на изи. Сейчас пересел на новый пк, установил последний ansible из pip и понеслось.

У меня выше похожая проблема была

И как порешал?

Ну у меня переменная действительно не создавалась. Вернее она была defined, но внутри не было того, на что я проверял

Такое ощущение что он слепить не может

но вот без --extra_vars норм лепит.

но вот без --extra_vars норм лепит.

Возможно где-то в коде или варсах оно определяется сложным образом, или через set_fact, а extra-vars это поведение ломает. Я бы по коду порылся для начала.

Лучше возьмите jsonnet

https://github.com/stoned/ansible-jsonnet-lookup/blob/master/lookup_plugins/jsonnet.py

ого

Возможно где-то в коде или варсах оно определяется сложным образом, или через set_fact, а extra-vars это поведение ломает. Я бы по коду порылся для начала.

Не, там все проще намного. Вообще странно видет себя ansible. У меня переменные в group_vars приоритетней чем --extra_vars сейчас выходят)

Не, там все проще намного. Вообще странно видет себя ansible. У меня переменные в group_vars приоритетней чем --extra_vars сейчас выходят)

Этого не может быть. Скорее всего, вы что-то путаете

Этого не может быть. Скорее всего, вы что-то путаете

Возможно, завтра перепроверю еще раз. Просто раньше эти же плейбуки работали как надо, а сейчас очень аномально себя ведут при использовании --extra_vars

Возможно, завтра перепроверю еще раз. Просто раньше эти же плейбуки работали как надо, а сейчас очень аномально себя ведут при использовании --extra_vars

Может инсталляция ансибл?

Может инсталляция ансибл?

А что с ней может быть не так? Кстати раньше запускал на Fedora, сейчас с MacOS

А что с ней может быть не так? Кстати раньше запускал на Fedora, сейчас с MacOS

Апдейты, плагины и т.п, если чистая инсталляция и не насилованная годами, то не думаю что в ней тогда проблема

А что с ней может быть не так? Кстати раньше запускал на Fedora, сейчас с MacOS

на маке могут быть особенности там где используются системные утилиты и модули типа архив. Версия питона раньше моглать быть 3, а теперь 2 или наоборот

ansible/ansible tagged: v2.9.0rc5 Link: https://github.com/ansible/ansible/releases/tag/v2.9.0rc5 Release notes: New release v2.9.0rc5

[root@gate named]# nslookup -q=A www.ansible.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: www.ansible.com canonical name = 330046g46.secure0032.hubspot.net. 330046g46.secure0032.hubspot.net canonical name = 330046.group46.sites.hubspot.net. 330046.group46.sites.hubspot.net canonical name = group46.sites.hscoscdn40.net. Name: group46.sites.hscoscdn40.net Address: 104.17.113.180 Name: group46.sites.hscoscdn40.net Address: 104.17.114.180 Name: group46.sites.hscoscdn40.net Address: 104.17.115.180 Name: group46.sites.hscoscdn40.net Address: 104.17.112.180 Name: group46.sites.hscoscdn40.net Address: 104.17.116.180 [root@gate named]# nslookup -q=A ansible.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: ansible.com Address: 104.24.16.59 Name: ansible.com Address: 104.24.17.59

Их там ломанули что ли?

Или это cloudflare балуется?

Это cdn же

кто бы знал как меня бесит поведение to_yaml.

кто бы знал как меня бесит поведение to_yaml.

Примерно догадываюсь )

"Фиксить не будем, это валидное поведение" ))

"Фиксить не будем, это валидное поведение" ))

А что там?

на маке могут быть особенности там где используются системные утилиты и модули типа архив. Версия питона раньше моглать быть 3, а теперь 2 или наоборот

Тоже были связанные с этим проблемы. Решил при помощи ansible_python_interpreter=/usr/bin/python3, после этого только некоторые модули стали работать корректно

Качнул для ознакомления роль с galaxy, там в названиях переменных двойное подчеркивание, типа apcupsd__service_environment подскажите, это зачем так? В доке не нашел...