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

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

Он предназначен для помощи в обновлении ваших playbooks, плагинов и других частей вашей инфраструктуры Ansible, чтобы они работали с этой версией Ansible.

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

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

• Playbook
  • Факты о дистрибутивах
  • Импорты как обработчики
  • Неопределенные значения Jinja
  • Преобразование параметров модуля в строку
  • Факты командной строки
  • Простые переменные в условных выражениях
    • Обновление ваших playbooks
    • Двойная интерполяция
    • Вложенные переменные
  • Сбор фактов
• Обнаружение интерпретатора Python
  • Повторное создание файла по умолчанию
• Командная строка
  • Подсказки Become
• Устаревшее
• Модули
  • Удаленные модули
  • Уведомления об устаревании
  • Заметные изменения в модулях
• Плагины
• Перенос пользовательских скриптов
  • Класс отображения
• Сети

Playbook

Факты о дистрибутивах

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

Две чаще всего используемые в playbooks факта, 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') }}

or

{{ 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' само по себе выглядит как булево. Для пользователей с playbooks, зависящих от старого поведения, мы добавили настройку конфигурации, которая сохраняет её. Вы можете использовать переменную среды ANSIBLE_CONDITIONAL_BARE_VARS или conditional_bare_variables в разделе defaults раздела ansible.cfg, чтобы выбрать желаемое поведение на контрольном узле. Значение по умолчанию — true, что сохраняет старое поведение. Установите значение конфигурации или переменной среды на false, чтобы начать использовать новый параметр.

Обновление ваших playbooks

Чтобы подготовить ваши playbooks к новому поведению, необходимо обновить ваши условные операторы, чтобы они принимали только булевы значения. Для переменных вы можете использовать фильтр 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 неявная задача «Сбор фактов» в play была изменена на соблюдение тегов play. До версии 2.8 задача «Сбор фактов» игнорировала теги play и теги, переданные через командную строку, и всегда выполнялась в задаче.

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

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

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

Если теги уровня play не заданы, задаче «Сбор фактов» будет присвоен тег 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 был установлен с другим именем или другим путем, ваши playbook'ы завершались ошибкой /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, в playbook'ах и т. д.). Если вы предпочитаете использовать поведение обнаружения интерпретатора Python, используйте одно из четырёх новых значений для ansible_python_interpreter, введённых в Ansible 2.8:

Начиная с Ansible 2.12, Ansible будет по умолчанию использовать обнаруженный интерпретатор 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:

Устаревшее

• Опция модуля params в ldap_attr и ldap_entry устарела с коротким циклом (будет удалена в Ansible-2.10) из-за обхода обычной обработки опций Ansible. В частности, если опция bind_pw установлена с помощью params, значение опции может быть помещено в файл журнала или отображено в stdout.

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

  - name: run task with custom async directory
    command: sleep 5
    async: 10
    vars:
      ansible_aync_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 во всех задачах на основе файлов, которые его принимают.

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

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

• ec2_remote_facts
• azure
• cs_nic
• netscaler
• win_msi

Предупреждения об устаревании

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

• 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 вместо.

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

• Проблема безопасности Установка bind_pw с опцией params для модулей ldap_entry и ldap_attr запрещена. Если bind_pw было установлено с params, значение могло попасть в лог-файл или выведено на стандартный вывод. Установите bind_pw напрямую, используя опции модулей.
• Модули foreman и katello устарели и заменены на набор модулей, разбитых по сущностям с учётом идемпотентности.
• Замена модулей foreman и katello официально входит в состав и поддерживается сообществом Foreman.
• Модуль 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. Любые плейбуки, использующие changed_when: no для маскировки этого поведения, могут безопасно удалить это обходное решение. Чтобы получить предыдущее поведение при применении state: absent к встроенному модулю ядра, используйте failed_when: false или ignore_errors: true в вашем плейбуке.
• Модуль 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 устарели в пользу использования ролей Palo Alto Networks Ansible Galaxy role. Вклад в роль можно внести здесь.
• Модуль ipa_user изначально всегда отправлял password в FreeIPA независимо от того, было ли изменено пароль. Теперь модуль отправляет только password, если update_password установлено в значение always, которое является значением по умолчанию.
• Модуль win_psexec устарел недокументированную опцию модуля extra_opts. Она будет удалена в Ansible 2.10.
• Модуль win_nssm устарел следующие опции в пользу использования модуля win_service для настройки сервиса после установки с помощью win_nssm: * dependencies, используйте dependencies модуля win_service * start_mode, используйте start_mode модуля win_service * user, используйте username модуля win_service * user, используйте username модуля 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 и с тех пор не оказывал влияния на модуль.