Невозможно распечатать ansible_failed_task.name в блоке восстановления

Question

Ниже приведен фрагмент кода, который извлекает список локальных зон и пытается войти в спасательный блок, если какая-либо из локальных зон не находится в состоянии RUNNING.

Но аварийно-спасательный блок не работает, при «Проверьте, находятся ли зоны в рабочем состоянии»

Ожидается отправка электронного письма с именем задачи. Но это хорошо работает с другими неудачными задачами. Может кто-нибудь, пожалуйста, руководство?

Не удалось! => {"msg": "Задача включает в себя параметр с неопределенной переменной. Ошибка была следующей: 'item' не определен \ n \ nОшибка, по-видимому, находится в /etc/ansible/playbooks/misc/test1404.yml ' : строка 23, столбец 9, но может \ n находиться в другом месте файла, в зависимости от точной синтаксической проблемы. \ n \ nВредной строкой является: \ n \ n rescue: \ n - name: отправка электронного письма из Ansible узел контроллера \ n ^ здесь \ n "}

    - '{{ host }}'
  tasks:
   - block:
      - name: Retrieve list of local zones
        shell: /usr/sbin/zoneadm list | grep -v global   
        register: lzones      
        tags: 
          - local_zone_list
      - debug:
           msg: "{{ item }}"
        with_items: "{{lzones.stdout_lines}}"

      - name: Check if the zones are in running state
        shell: /usr/sbin/zoneadm list | grep -v global | grep "{{ item }}" | awk '{print$3}'
        register: status
        with_items: "{{lzones.stdout_lines}}"
        failed_when: status.stdout.find('running') == -1


        < few other tasks>

     rescue:
      - name: Sending an e-mail from Ansible controller node
        mail:
            host: localhost
            port: 25
            to: xyz@abc.com
            subject: Reboot Failed
            body: Reboot FAILED at TASK - {{ ansible_failed_task.name }} with ERROR {{ ansible_failed_result }}
        delegate_to: localhost

Answer 1

Ну, это была совершенно захватывающая кроличья нора.

Потому что в ansible шаблоны jinja2 визуализируются рекурсивно , когда он пытается чтобы обработать сообщение с ошибкой, которое содержит шаблон с ошибкой, он пытается повторно обработать шаблон с ошибкой снова , повторно вызывая ошибку

Это, кажется, влияет на вас включением переменная ansible_failed_task, поскольку - необъяснимо - кажется, что безопасно включать ansible_failed_result в тело

Как я могу лучше сказать, экспериментируя с ansible 2.9. 6, нужно определить, можно ли безопасно вывести переменную аромата a*_task перед тем, как дотронуться до нее, потому что я не смог найти ни одной комбинации | string или |regex_replace или всего, что позволяло бы jinja2 прикоснуться к этой переменной, если она содержит фиктивную ссылку на переменную:

  - block:
    - debug:
        msg: this explodes {{ nope_not_a_var }}

    rescue:
    - set_fact:
        is_undefined_error: '{{ "undefined variable" in ansible_failed_result.msg }}'

    - name: variable is unsafe version
      debug:
        msg: >-
          failed task action has an undefined variable in the task,
          so we cannot show you the task, but here is the result: {{ ansible_failed_result }}
      when: is_undefined_error

    - name: variable is safe to output version
      debug:
        msg: Reboot FAILED at TASK - {{ ansible_failed_task.name }} with ERROR {{ ansible_failed_result }}
      when: not is_undefined_error

Может быть безопасным встроить этот тест "..." in ansible_failed_result.msg в строки when: напрямую, но так как ( должен ) проду Поскольку оба раза один и тот же ответ, нет действительно веской причины оценивать его дважды

---

Мне кажется, что это ошибка ansible, но у меня нет эмоциональной энергии, чтобы ее устранить. с их сообществом - однако, я призываю вас сообщить об ошибке с ними