Руководство по переносу Ansible 2.8

В этом разделе рассматриваются изменения в поведении между Ansible 2.7 и Ansible 2.8.

Цель данного руководства – помочь в обновлении ваших playbook-ов, плагинов и других частей вашей инфраструктуры Ansible, чтобы они работали с этой версией Ansible.

Мы рекомендуем прочитать эту страницу вместе с Журналом изменений Ansible 2.8, чтобы понять, какие обновления вам могут потребоваться.

Этот документ входит в коллекцию по переносу. Полный список руководств по переносу можно найти в руководствах по переносу.

• Playbook

  • Факты распределения
  • Импорты как обработчики
  • Неопределенные значения Jinja
  • Преобразование параметров модуля в строку
  • Факты командной строки

  • Простые переменные в условных выражениях

    • Обновление ваших playbook-ов
    • Двойная интерполяция
    • Вложенные переменные
  • Сбор фактов

• Обнаружение интерпретатора Python

  • Повторное создание файла по умолчанию

• Командная строка

  • Запрос become
• Устаревшие элементы

• Модули

  • Удаленные модули
  • Уведомления об устаревании
  • Заметные изменения в модулях
• Плагины

• Перенос пользовательских скриптов

  • Класс отображения
• Сети

Playbook

Факты распределения

Информация, возвращаемая для группы фактов ansible_distribution_*, может быть немного изменена. Ansible 2.8 использует новую библиотеку back-end для получения информации о распределениях: nir0s/distro. Эта библиотека работает с Python 3.8 и исправляет многие ошибки, включая исправление названий релизов и версий.

Две чаще всего используемые в playbook-ах факта, ansible_distribution и ansible_distribution_major_version, не должны измениться. Если вы обнаружите изменение в этих фактах, пожалуйста, отправьте отчет об ошибке, чтобы мы могли разобраться с различием. Однако другие факты, такие как ansible_distribution_release и ansible_distribution_version, могут измениться по мере исправления ошибочной информации.

Импорты как обработчики

Начиная с версии 2.8, задача не может оповещать import_tasks или статический include, который указан в handlers.

Цель статического импорта – действовать как препроцессор, где импорт заменяется задачами, определёнными в импортируемом файле. При использовании импорта задача может оповестить любые из названных задач в импортируемом файле, но не само имя импорта.

Для достижения результатов оповещения одного имени, но запуска нескольких обработчиков, используйте include_tasks или listen Обработчики: выполнение операций при изменении.

Неопределенные значения Jinja

Начиная с версии 2.8, попытка доступа к атрибуту неопределённого значения в Jinja вернёт другое неопределённое значение, а не сразу выбросит ошибку. Это означает, что теперь вы можете просто использовать значение по умолчанию в вложенной структуре данных, когда вы не знаете, определены ли промежуточные значения.

В Ansible 2.8:

{{ foo.bar.baz | default('DEFAULT') }}

В Ansible 2.7 и более ранних версиях:

{{ ((foo | default({})).bar | default({})).baz | default('DEFAULT') }}

или:

{{ foo.bar.baz if (foo is defined and foo.bar is defined and foo.bar.baz is defined) else 'DEFAULT' }}

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

Начиная с версии 2.8, Ansible будет предупреждать, если модуль ожидает строку, но передано значение, не являющееся строкой, и автоматически преобразуется в строку. Это указывает на потенциальные проблемы, когда, например, yes или true (распознаваемое как истинное булево значение) будет преобразовано в строку 'True', или когда номер версии 1.10 (распознаваемое как число с плавающей точкой) будет преобразовано в '1.1'. Такие преобразования могут привести к неожиданному поведению в зависимости от контекста.

Это поведение можно изменить на ошибку или игнорирование, задав переменную окружения ANSIBLE_STRING_CONVERSION_ACTION или настройку string_conversion_action в разделе defaults файла конфигурации ansible.cfg.

Факты командной строки

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

Простые переменные в условных выражениях

В Ansible 2.7 и ранее переменные верхнего уровня иногда обрабатывали строковые булевы значения, как булевы. Это приводило к несогласованному поведению в условных тестах, построенных на переменных верхнего уровня, определённых как строки. Ansible 2.8 начал изменять это поведение. Например, если вы установили две такие условия:

tasks:
  - include_tasks: teardown.yml
    when: teardown

  - include_tasks: provision.yml
    when: not teardown

основанные на переменной, которую вы определили как строку (с кавычками вокруг неё):

• В Ansible 2.7 и ранее, два условия выше оценивались как True и False соответственно, если teardown: 'true'
• В Ansible 2.7 и ранее, оба условия оценивались как False, если teardown: 'false'
• В Ansible 2.8 и более поздних версиях, у вас есть возможность отключить простые переменные в условных выражениях, поэтому when: teardown всегда оценивается как True и when: not teardown всегда оценивается как False, когда teardown — непустая строка (включая 'true' или 'false')

В конечном итоге, when: 'string' всегда оценивается как True, и when: not 'string' всегда оценивается как False, если 'string' не пустая, даже если значение 'string' само выглядит как булево. Для пользователей с playbook-ами, которые зависят от старого поведения, мы добавили настройку конфигурации, сохраняющую его. Вы можете использовать переменную окружения ANSIBLE_CONDITIONAL_BARE_VARS или conditional_bare_variables в разделе defaults файла конфигурации ansible.cfg, чтобы выбрать желаемое поведение на контрольном узле. По умолчанию установлено значение true, которое сохраняет старое поведение. Установите значение конфигурации или переменной окружения на false, чтобы начать использовать новый вариант.

Обновление ваших playbook-ов

Чтобы подготовить ваши playbook-ы к новому поведению, вам необходимо обновить ваши условные выражения, чтобы они принимали только булевы значения. Для переменных вы можете использовать фильтр bool для оценки строки 'false' как False:

vars:
  teardown: 'false'

tasks:
  - include_tasks: teardown.yml
    when: teardown | bool

  - include_tasks: provision.yml
    when: not teardown | bool

В качестве альтернативы, вы можете повторно определить свои переменные как булевы значения (без кавычек) вместо строк:

vars:
  teardown: false

tasks:
  - include_tasks: teardown.yml
    when: teardown

  - include_tasks: provision.yml
    when: not teardown

Для словарей и списков используйте фильтр length для оценки наличия словаря или списка как True:

- debug:
  when: my_list | length > 0

- debug:
  when: my_dictionary | length > 0

Не используйте фильтр bool со списками или словарями. Если вы используете bool со списком или словарем, Ansible всегда будет оценивать его как False.

Двойная интерполяция

Настройка conditional_bare_variables также влияет на переменные, установленные на основе других переменных. Старое поведение неожиданно выполняло двойную интерполяцию этих переменных. Например:

vars:
  double_interpolated: 'bare_variable'
  bare_variable: false

tasks:
  - debug:
    when: double_interpolated

• В Ansible 2.7 и ранее, when: double_interpolated оценивалось как значение bare_variable, в этом случае, False. Если переменная bare_variable не определена, условное выражение не выполняется.
• В Ansible 2.8 и более поздних версиях, с отключёнными простыми переменными, Ansible оценивает double_interpolated как строку 'bare_variable', что является True.

Для двойной интерполяции значений переменных используйте фигурные скобки:

vars:
  double_interpolated: "{{ other_variable }}"
  other_variable: false

Вложенные переменные

Настройка conditional_bare_variables не влияет на вложенные переменные. Любое строковое значение, назначенное подключаемому ключу, уже учитывается и не обрабатывается как булево. Если complex_variable['subkey'] — непустая строка, то when: complex_variable['subkey'] всегда True и when: not complex_variable['subkey'] всегда False. Если вы хотите, чтобы строковый подключаемый ключ, например, complex_variable['subkey'], оценивался как булево, вы должны использовать фильтр bool.

Сбор фактов

В Ansible 2.8 неявная задача «Сбор фактов» в playbook-е была изменена, чтобы подчиняться тегам playbook-а. До версии 2.8 задача «Сбор фактов» игнорировала теги playbook-а и теги, предоставленные через командную строку, и всегда выполнялась как задача.

Изменение поведения затрагивает следующий пример playbook-а.

- name: Configure Webservers
  hosts: webserver
  tags:
    - webserver
  tasks:
    - name: Install nginx
      package:
        name: nginx
      tags:
        - nginx

В Ansible 2.8, если вы предоставите --tags nginx, неявная задача «Сбор фактов» будет пропущена, так как задача теперь наследует тег webserver вместо always.

Если теги уровня playbook-а не установлены, задаче «Сбор фактов» будет присвоен тег always, и она фактически будет соответствовать предыдущему поведению.

Вы можете добиться аналогичного результата, как в версии до 2.8, используя явную задачу gather_facts в вашем списке задач tasks.

- name: Configure Webservers
  hosts: webserver
  gather_facts: false
  tags:
    - webserver
  tasks:
    - name: Gathering Facts
      gather_facts:
      tags:
        - always

    - name: Install nginx
      package:
        name: nginx
      tags:
        - nginx

Обнаружение интерпретатора Python

В Ansible 2.7 и ранее Ansible по умолчанию использовал /usr/bin/python в качестве настройки для ansible_python_interpreter. Если вы запускали Ansible на системе, где Python установлен с другим именем или в другом пути, ваши плейбуки завершались ошибкой /usr/bin/python: bad interpreter: No such file or directory, если вы не задавали ansible_python_interpreter правильное значение для этой системы или не добавляли интерпретатор Python и необходимые зависимости в usr/bin/python.

Начиная с Ansible 2.8, Ansible ищет правильный путь и имя исполняемого файла для Python на каждой целевой системе, сначала в таблице поиска по умолчанию интерпретаторов Python для распространённых дистрибутивов, затем в упорядоченном списке возможных имён/путей интерпретатора Python.

Рискованно полагаться на интерпретатор Python, выбранный из списка по умолчанию, потому что интерпретатор может измениться при последующих запусках. Если интерпретатор из верхних позиций списка по умолчанию устанавливается (например, как побочный эффект установки других пакетов), ваш исходный интерпретатор и его зависимости больше не будут использоваться. По этой причине Ansible предупреждает вас, когда он использует интерпретатор Python, обнаруженный из списка по умолчанию. Если вы видите это предупреждение, лучше всего явно задать ansible_python_interpreter путь к правильному интерпретатору для этих целевых систем.

Вы по-прежнему можете задать ansible_python_interpreter определённый путь на любом уровне переменных (как переменные хоста, в файлах vars, в плейбуках и т. д.). Если вы предпочитаете использовать поведение обнаружения интерпретатора Python, используйте одно из четырёх новых значений для ansible_python_interpreter, представленных в Ansible 2.8:

В Ansible 2.12 Ansible переключится на значение по умолчанию от auto_legacy к auto. Разница в поведении заключается в том, что auto_legacy использует /usr/bin/python, если он присутствует, и переходит к обнаруженному Python, если он отсутствует. auto всегда использует обнаруженный Python, независимо от того, существует ли /usr/bin/python. Настройка auto_legacy обеспечивает совместимость с предыдущими версиями Ansible, которые всегда по умолчанию использовали /usr/bin/python.

Если вы установили Python и зависимости (boto и т. д.) в /usr/bin/python в качестве обходного решения на дистрибутивах с другим интерпретатором Python по умолчанию (например, Ubuntu 16.04+, RHEL8, Fedora 23+), у вас есть два варианта:

1. Переместите существующие зависимости в интерпретатор Python по умолчанию для каждой платформы/дистрибутива/версии.
2. Используйте auto_legacy. Эта настройка позволяет Ansible находить и использовать обходной Python на хостах, на которых он есть, а также находить правильный интерпретатор Python по умолчанию на новых хостах. Но помните, что значение по умолчанию изменится через 4 релиза.

Значение по умолчанию для повторной попытки создания файла

В Ansible 2.8, retry_files_enabled теперь по умолчанию равно False, а не True. Поведение можно изменить на предыдущую версию, отредактировав файл по умолчанию ansible.cfg и установив значение на True.

Командная строка

Запрос на повышение привилегий

Начиная с версии 2.8, Ansible по умолчанию будет использовать слово BECOME, чтобы запросить у вас пароль для повышения привилегий (привилегии sudo на системах Unix или режим enable на сетевых устройствах):

По умолчанию в Ansible 2.8:

ansible-playbook --become --ask-become-pass site.yml
BECOME password:

Если вы хотите, чтобы запрос отображал конкретное значение become_method, которое вы используете, вместо абстрактного значения BECOME, установите AGNOSTIC_BECOME_PROMPT на False в вашей конфигурации Ansible.

По умолчанию в Ansible 2.7 или с AGNOSTIC_BECOME_PROMPT=False в Ansible 2.8:

ansible-playbook --become --ask-become-pass site.yml
SUDO password:

Устаревшее

• Установка каталога async с помощью ANSIBLE_ASYNC_DIR в качестве ключа среды задачи/плейбука устарела и будет удалена в Ansible 2.12. Вы можете достичь того же результата, установив ansible_async_dir в качестве переменной, как:

  - name: run task with custom async directory
    command: sleep 5
    async: 10
    vars:
      ansible_async_dir: /tmp/.ansible_async
  

• Разработчики плагинов, которым нужен объект FactCache, должны знать о двух устаревших функциях:

  1. Класс FactCache переместился из ansible.plugins.cache.FactCache в ansible.vars.fact_cache.FactCache. Это связано с тем, что FactCache не является частью API плагина кэширования, и разработчики плагинов кэширования не должны его наследоваться. FactCache всё ещё доступен из своего старого расположения, но при использовании оттуда будет выведено предупреждение об устаревании. Старое расположение будет удалено в Ansible 2.12.
  2. Метод FactCache.update() был преобразован для соответствия API словарей. Теперь он принимает словарь в качестве единственного аргумента и обновляет себя элементами словаря. Предыдущий API, в котором update() принимал ключ и значение, теперь будет вызывать предупреждение об устаревании и будет удален в версии 2.12. Если вам нужно старое поведение, переключитесь на FactCache.first_order_merge().
• Поддержка кэширования на основе файлов через self.cache устарела и будет удалена в Ansible 2.12. Если вы поддерживаете плагин инвентаризации, обновите его, чтобы использовать self._cache в качестве словаря. Подробности реализации см. в руководстве разработчика по плагинам инвентаризации.

• Прямой импорт плагинов кэширования устарел и будет удален в Ansible 2.12. Используйте plugin_loader, чтобы прямые параметры, переменные среды и другие способы конфигурации могли быть согласованы с помощью системы конфигурации, а не констант.

  from ansible.plugins.loader import cache_loader
  cache = cache_loader.get('redis', **kwargs)
  

Модули

Основные изменения в популярных модулях описаны здесь

Обёртка exec, которая выполняет модули PowerShell, была изменена, чтобы установить $ErrorActionPreference = "Stop" глобально. Это может означать, что пользовательские модули могут завершиться ошибкой, если они неявно полагались на это поведение. Чтобы вернуть старое поведение, добавьте $ErrorActionPreference = "Continue" в начало модуля. Это изменение было сделано для восстановления прежнего поведения EAP, которое случайно было удалено в предыдущей версии, и чтобы модули стали более устойчивыми к ошибкам, которые могут возникнуть при выполнении.

• Версия 2.8.14 Ansible изменила режим по умолчанию для задач, основанных на файлах, на 0o600 & ~umask, когда пользователь не указал параметр mode для задач, основанных на файлах. Это было сделано в ответ на отчёт о CVE, который мы пересмотрели. В результате изменение mode было отменено в версии 2.8.15, и mode теперь по умолчанию будет равно 0o666 & ~umask, как и в предыдущих версиях Ansible.
• Если вы изменили какие-либо задачи, чтобы указать менее жёсткие разрешения при использовании 2.8.14, эти изменения будут излишними (но не нанесут вреда) в версии 2.8.15.
• Чтобы избежать проблемы, описанной в CVE-2020-1736, укажите параметр mode во всех задачах, основанных на файлах, которые его принимают.
• dnf и yum - начиная с версии 2.8.15, модуль dnf (и действие yum, когда оно использует dnf) теперь правильно проверяет подписи GPG пакетов (CVE-2020-14365). Если вы видите ошибку, такую как Failed to validate GPG signature for [package name], убедитесь, что вы импортировали правильный ключ GPG для репозитория DNF и/или пакета, который вы используете. Один из способов сделать это – с помощью модуля rpm_key. Хотя мы не рекомендуем это делать, в некоторых случаях может потребоваться отключить проверку GPG. Это можно сделать, добавив явно disable_gpg_check: yes в свою задачу dnf или yum.

Удаленные модули

Следующие модули больше не существуют:

• ec2_remote_facts
• azure
• cs_nic
• netscaler
• win_msi

Устаревшие уведомления

Следующие модули будут удалены в Ansible 2.12. Пожалуйста, обновите свои плейбуки соответственно.

• foreman используйте foreman-ansible-modules вместо.
• katello используйте foreman-ansible-modules вместо.
• github_hooks используйте github_webhook и github_webhook_facts вместо.
• digital_ocean используйте digital_ocean_droplet вместо.
• gce используйте gcp_compute_instance вместо.
• gcspanner используйте gcp_spanner_instance и gcp_spanner_database вместо.
• gcdns_record используйте gcp_dns_resource_record_set вместо.
• gcdns_zone используйте gcp_dns_managed_zone вместо.
• gcp_forwarding_rule используйте gcp_compute_global_forwarding_rule или gcp_compute_forwarding_rule вместо.
• gcp_healthcheck используйте gcp_compute_health_check, gcp_compute_http_health_check или gcp_compute_https_health_check вместо.
• gcp_backend_service используйте gcp_compute_backend_service вместо.
• gcp_target_proxy используйте gcp_compute_target_http_proxy вместо.
• gcp_url_map используйте gcp_compute_url_map вместо.
• panos используйте роль Palo Alto Networks Ansible Galaxy role вместо.

Важные изменения в модулях

• Модули foreman и katello устарели и заменены на набор модулей, разбитых по сущностям для лучшей идемпотентности.
• Замена модулей foreman и katello официально входит в состав Foreman Community и там поддерживается.
• Модуль tower_credential изначально требовал, чтобы ssh_key_data указывал путь к файлу ssh_key_file. Для работы, аналогично Tower/AWX, ssh_key_data теперь содержит содержимое файла. Предыдущее поведение можно получить с помощью lookup('file', '/path/to/file').
• Модуль win_scheduled_task убрал поддержку указания повторения триггера в виде списка, и этот формат будет удален в Ansible 2.12. Вместо этого укажите повторение в виде словаря.
• Модуль win_feature удалил устаревший параметр возврата restart_needed. Используйте вместо него стандартное значение reboot_required.
• Модуль win_package удалил устаревшие параметры возврата restart_required и exit_code. Используйте вместо них стандартные значения reboot_required и rc.
• Модуль win_get_url удалил устаревший словарь возврата win_get_url. Значения возвращаются напрямую.
• Модуль win_get_url удалил устаревший параметр skip_certificate_validation. Используйте вместо него стандартный параметр validate_certs.
• Модуль vmware_local_role_facts теперь возвращает список словарей вместо словаря словарей для информации о ролях.
• Если docker_network или docker_volume вызывались с diff: yes, check_mode: yes или debug: yes, возвращалось значение diff типа list. Для корректного вывода различий это было изменено на тип dict; исходное list возвращается как diff.differences.
• Модуль na_ontap_cluster_peer заменил строковые параметры source_intercluster_lif и dest_intercluster_lif на списковые параметры source_intercluster_lifs и dest_intercluster_lifs.
• Модуль modprobe теперь обнаруживает встроенные ядра. Ранее попытка удалить (с помощью state: absent) встроенный модуль ядра завершалась без сообщения об ошибке, потому что modprobe не определял модуль как present. Теперь modprobe завершится ошибкой, если модуль ядра является встроенным, и state: absent (с сообщением об ошибке из бинарника modprobe, например, modprobe: ERROR: Module nfs is builtin.), и он завершится без отчета о изменениях, если state: present. Любые playbook'и, использующие changed_when: no для маскировки этого нюанса, могут безопасно удалить эту обходную технологию. Чтобы получить предыдущее поведение при применении state: absent к встроенному модулю ядра, используйте failed_when: false или ignore_errors: true в вашем playbook'е.
• Модуль digital_ocean устарел в пользу модулей, не требующих внешних зависимостей. Это обеспечивает большую гибкость и лучшую поддержку модулей.
• Модуль docker_container устарел с возвращаемым фактом docker_container. То же значение доступно как возвращаемая переменная container. Возвращаемый факт будет удален в Ansible 2.12.
• Модуль docker_network устарел с возвращаемым фактом docker_container. То же значение доступно как возвращаемая переменная network. Возвращаемый факт будет удален в Ansible 2.12.
• Модуль docker_volume устарел с возвращаемым фактом docker_container. То же значение доступно как возвращаемая переменная volume. Возвращаемый факт будет удален в Ansible 2.12.
• Модуль docker_service переименован в docker_compose.
• Переименованный модуль docker_compose возвращал один факт на сервис, названный так же, как и сервис. Словарь этих фактов возвращается как обычное возвращаемое значение services. Возвращаемые факты будут удалены в Ansible 2.12.

• The docker_swarm_service module no longer sets a defaults for the following options:

  • user. Раньше значением по умолчанию было root.
  • update_delay. Раньше значением по умолчанию было 10.
  • update_parallelism. Раньше значением по умолчанию было 1.

• vmware_vm_facts возвращал словарь словарей с фактами виртуальной машины. Ansible 2.8 и выше возвращает список словарей с фактами виртуальной машины. Пожалуйста, обратитесь к документации модуля vmware_vm_facts для примера.
• Модуль vmware_guest_snapshot возвращал results. С Ansible 2.8 и выше results является зарезервированным ключевым словом, поэтому он заменён на snapshot_results. Пожалуйста, обратитесь к документации модуля vmware_guest_snapshots для примера.
• Модули panos устарели и рекомендуется использовать роле Ansible Galaxy Palo Alto Networks Ansible Galaxy роль. Вклад в роль можно сделать здесь.
• Модуль ipa_user изначально всегда отправлял password в FreeIPA независимо от того, было ли изменено пароль. Теперь модуль отправляет password только если update_password установлено в значение always, которое является значением по умолчанию.
• Модуль win_psexec устарел с необъявленным параметром extra_opts. Он будет удален в Ansible 2.10.
• Модуль win_nssm устарел с параметрами: * dependencies, использовать dependencies из win_service вместо него * start_mode, использовать start_mode из win_service вместо него * user, использовать username из win_service вместо него * password, использовать password из win_service вместо него. Эти параметры будут удалены в Ansible 2.12.
• Модуль win_nssm также устарел с значениями start, stop и restart параметра status. Вы должны использовать модуль win_service для управления состоянием запуска сервиса. Это будет удалено в Ansible 2.12.
• Параметр модуля status для win_nssm изменил значение по умолчанию на present. Раньше значением по умолчанию было start. В результате, сервис больше не запускается по умолчанию после создания с помощью win_nssm, и вам следует использовать модуль win_service для его запуска, если это необходимо.
• Параметр модуля app_parameters для win_nssm устарел; используйте argument вместо него. Это будет удалено в Ansible 2.12.
• Параметр модуля app_parameters_free_form для win_nssm стал алиасом для нового параметра arguments.
• Модуль win_dsc теперь проверяет входные параметры для ресурса DSC. В предыдущих версиях недействительные параметры игнорировались, но теперь это не так.
• Модуль openssl_pkcs12 теперь перегенерирует файл pkcs12, если есть различия между файлом на диске и параметрами, переданными модулю.

Плагины

• Ansible больше не использует по умолчанию плагин соединения paramiko при использовании macOS в качестве управляющего узла. Ansible теперь по умолчанию использует плагин соединения ssh на управляющем узле macOS. Поскольку ssh поддерживает сохранение соединения между задачами и выполнением плейбуков, он работает лучше, чем paramiko. Если вы используете аутентификацию по паролю, вам потребуется установить sshpass при использовании плагина соединения ssh. Или вы можете явно установить тип соединения на paramiko, чтобы сохранить поведение до версии 2.8 на macOS.
• Плагины соединения были стандартизированы, чтобы разрешить использование переменных ansible_<conn-type>_user и ansible_<conn-type>_password. Переменные, такие как ansible_<conn-type>_pass и ansible_<conn-type>_username, обрабатываются с более низким приоритетом, чем стандартизированные имена, и могут быть устаревшими в будущем. В общем случае следует использовать переменные ansible_user и ansible_password, если нет причины использовать переменные, специфичные для соединения.
• Плагин оболочки powershell теперь использует async_dir для определения асинхронного пути к файлу результатов, и значение по умолчанию изменилось на %USERPROFILE%\.ansible_async. Чтобы контролировать этот путь, теперь нужно установить переменную ansible_async_dir или значение async_dir в разделе powershell файла конфигурации ini.
• Порядок включенных плагинов инвентаризации (INVENTORY_ENABLED) был обновлён, auto теперь стоит перед yaml и ini.

• Атрибут _options, являющийся закрытым, был удален из класса CallbackBase плагинов обратной связи. Если плагин стороннего разработчика обратной связи требует доступа к аргументам командной строки, вместо попытки использования self._options используйте код, подобный следующему:

  from ansible import context
  [...]
  tags = context.CLIARGS['tags']
  

  context.CLIARGS — это словарь только для чтения, поэтому обычные методы извлечения значений из словаря, такие как CLIARGS.get('tags') и CLIARGS['tags'], работают как ожидается, но вы не сможете изменить аргументы командной строки.

• Теперь сводка плейбука учитывает задачи ignored и rescued, а также задачи ok, changed, unreachable, failed и skipped благодаря двум дополнительным счётчикам статистики в плагине обратной связи default. Задачи, которые завершились неудачно и имеют установленное значение ignore_errors: yes, отображаются как ignored. Задачи, завершившиеся неудачно, а затем выполнившие раздел аварийного восстановления, отображаются как rescued. Обратите внимание, что задачи rescued больше не считаются failed, как в Ansible 2.7 (и ранее).
• Плагин обратной связи osx_say был переименован в say.
• Плагины инвентаризации теперь поддерживают кэширование через плагины кэша. Чтобы начать использовать плагин кэша со своей инвентаризацией, см. раздел о кэшировании в руководстве по инвентаризации. Чтобы адаптировать пользовательский плагин кэша для совместимости с инвентаризацией, см. руководство разработчика по плагинам кэша.

Перенос пользовательских скриптов

Класс отображения

Начиная с Ansible 2.8, класс Display теперь является «синглтоном». Вместо использования __main__.display каждый файл должен импортировать и инициализировать ansible.utils.display.Display самостоятельно.

СТАРЫЙ В Ansible 2.7 (и ранее) для доступа к объекту display использовалось следующее:

try:
    from __main__ import display
except ImportError:
    from ansible.utils.display import Display
    display = Display()

НОВЫЙ В Ansible 2.8 следует использовать следующее:

from ansible.utils.display import Display
display = Display()

Сеть

• Модули eos_config, ios_config и nxos_config удалили устаревшие параметры save и force, используйте параметр save_when для воспроизведения их функциональности.
• Модуль nxos_vrf_af удалил параметр safi. Этот параметр был устаревшим в Ansible 2.4 и с тех пор не влиял на модуль.