1.. _porting_2.5_guide: 2 3************************* 4Ansible 2.5 Porting Guide 5************************* 6 7This section discusses the behavioral changes between Ansible 2.4 and Ansible 2.5. 8 9It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. 10 11We suggest you read this page along with `Ansible Changelog for 2.5 <https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst>`_ to understand what updates you may need to make. 12 13This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`. 14 15.. contents:: Topics 16 17Playbook 18======== 19 20Dynamic includes and attribute inheritance 21------------------------------------------ 22 23In Ansible version 2.4, the concept of dynamic includes (``include_tasks``), as opposed to static imports (``import_tasks``), was introduced to clearly define the differences in how ``include`` works between dynamic and static includes. 24 25All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a 26static ``import_*`` would be inherited by the tasks within. 27 28This separation was only partially implemented in Ansible version 2.4. As of Ansible version 2.5, this work is complete and the separation now behaves as designed; attributes applied to an ``include_*`` task will not be inherited by the tasks within. 29 30To achieve an outcome similar to how Ansible worked prior to version 2.5, playbooks should use an explicit application of the attribute on the needed tasks, or use blocks to apply the attribute to many tasks. Another option is to use a static ``import_*`` when possible instead of a dynamic task. 31 32**OLD** In Ansible 2.4: 33 34.. code-block:: yaml 35 36 - include_tasks: "{{ ansible_distribution }}.yml" 37 tags: 38 - distro_include 39 40Included file: 41 42.. code-block:: yaml 43 44 - block: 45 - debug: 46 msg: "In included file" 47 48 - apt: 49 name: nginx 50 state: latest 51 52**NEW** In Ansible 2.5: 53 54Including task: 55 56.. code-block:: yaml 57 58 - include_tasks: "{{ ansible_distribution }}.yml" 59 tags: 60 - distro_include 61 62Included file: 63 64.. code-block:: yaml 65 66 - block: 67 - debug: 68 msg: "In included file" 69 70 - apt: 71 name: nginx 72 state: latest 73 tags: 74 - distro_include 75 76The relevant change in those examples is, that in Ansible 2.5, the included file defines the tag ``distro_include`` again. The tag is not inherited automatically. 77 78Fixed handling of keywords and inline variables 79----------------------------------------------- 80 81We made several fixes to how we handle keywords and 'inline variables', to avoid conflating the two. Unfortunately these changes mean you must specify whether `name` is a keyword or a variable when calling roles. If you have playbooks that look like this:: 82 83 roles: 84 - { role: myrole, name: Justin, othervar: othervalue, become: True} 85 86You will run into errors because Ansible reads name in this context as a keyword. Beginning in 2.5, if you want to use a variable name that is also a keyword, you must explicitly declare it as a variable for the role:: 87 88 roles: 89 - { role: myrole, vars: {name: Justin, othervar: othervalue}, become: True} 90 91 92For a full list of keywords see :ref:`playbook_keywords`. 93 94Migrating from with_X to loop 95----------------------------- 96 97.. include:: ../user_guide/shared_snippets/with2loop.txt 98 99 100Deprecated 101========== 102 103Jinja tests used as filters 104--------------------------- 105 106Using Ansible-provided jinja tests as filters will be removed in Ansible 2.9. 107 108Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while jinja tests are referenced as ``variable is test_name``. 109 110Jinja tests are used for comparisons, while filters are used for data manipulation and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used. 111 112As of Ansible 2.5, using an Ansible provided jinja test with filter syntax, will display a deprecation error. 113 114**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this: 115 116.. code-block:: yaml 117 118 when: 119 - result | failed 120 - not result | success 121 122**NEW** In Ansible 2.5 it should be changed to look like this: 123 124.. code-block:: yaml 125 126 when: 127 - result is failed 128 - results is not successful 129 130In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests. These new tests make more sense grammatically with the jinja test syntax, such as the new ``successful`` test which aliases ``success``. 131 132.. code-block:: yaml 133 134 when: result is successful 135 136See :ref:`playbooks_tests` for more information. 137 138Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py <https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py>`_. 139 140Ansible fact namespacing 141------------------------ 142 143Ansible facts, which have historically been written to names like ``ansible_*`` 144in the main facts namespace, have been placed in their own new namespace, 145``ansible_facts.*`` For example, the fact ``ansible_distribution`` is now best 146queried through the variable structure ``ansible_facts.distribution``. 147 148A new configuration variable, ``inject_facts_as_vars``, has been added to 149ansible.cfg. Its default setting, 'True', keeps the 2.4 behavior of facts 150variables being set in the old ``ansible_*`` locations (while also writing them 151to the new namespace). This variable is expected to be set to 'False' in a 152future release. When ``inject_facts_as_vars`` is set to False, you must 153refer to ansible_facts through the new ``ansible_facts.*`` namespace. 154 155Modules 156======= 157 158Major changes in popular modules are detailed here. 159 160github_release 161-------------- 162 163In Ansible versions 2.4 and older, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module reported state as ``skipped``. 164In Ansible version 2.5 and later, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module now reports state as ``changed``. 165 166 167Modules removed 168--------------- 169 170The following modules no longer exist: 171 172* nxos_mtu use :ref:`nxos_system <ansible_2_5:nxos_system_module>`'s ``system_mtu`` option or :ref:`nxos_interface <ansible_2_5:nxos_interface_module>` instead 173* cl_interface_policy use :ref:`nclu <ansible_2_5:nclu_module>` instead 174* cl_bridge use :ref:`nclu <ansible_2_5:nclu_module>` instead 175* cl_img_install use :ref:`nclu <ansible_2_5:nclu_module>` instead 176* cl_ports use :ref:`nclu <ansible_2_5:nclu_module>` instead 177* cl_license use :ref:`nclu <ansible_2_5:nclu_module>` instead 178* cl_interface use :ref:`nclu <ansible_2_5:nclu_module>` instead 179* cl_bond use :ref:`nclu <ansible_2_5:nclu_module>` instead 180* ec2_vpc use :ref:`ec2_vpc_net <ansible_2_5:ec2_vpc_net_module>` along with supporting modules :ref:`ec2_vpc_igw <ansible_2_5:ec2_vpc_igw_module>`, :ref:`ec2_vpc_route_table <ansible_2_5:ec2_vpc_route_table_module>`, :ref:`ec2_vpc_subnet <ansible_2_5:ec2_vpc_subnet_module>`, :ref:`ec2_vpc_dhcp_option <ansible_2_5:ec2_vpc_dhcp_option_module>`, :ref:`ec2_vpc_nat_gateway <ansible_2_5:ec2_vpc_nat_gateway_module>`, :ref:`ec2_vpc_nacl <ansible_2_5:ec2_vpc_nacl_module>` instead. 181* ec2_ami_search use :ref:`ec2_ami_facts <ansible_2_5:ec2_ami_facts_module>` instead 182* docker use :ref:`docker_container <ansible_2_5:docker_container_module>` and :ref:`docker_image <ansible_2_5:docker_image_module>` instead 183 184.. note:: 185 186 These modules may no longer have documentation in the current release. Please see the 187 `Ansible 2.4 module documentation 188 <https://docs.ansible.com/ansible/2.4/list_of_all_modules.html>`_ if you need 189 to know how they worked for porting your playbooks. 190 191 192 193Deprecation notices 194------------------- 195 196The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly. 197 198* Apstra's ``aos_*`` modules are deprecated as they do not work with AOS 2.1 or higher. See new modules at `https://github.com/apstra <https://github.com/apstra>`_. 199* nxos_ip_interface use :ref:`nxos_l3_interface <ansible_2_5:nxos_l3_interface_module>` instead. 200* nxos_portchannel use :ref:`nxos_linkagg <ansible_2_5:nxos_linkagg_module>` instead. 201* nxos_switchport use :ref:`nxos_l2_interface <ansible_2_5:nxos_l2_interface_module>` instead. 202* panos_security_policy use :ref:`panos_security_rule <ansible_2_5:panos_security_rule_module>` instead. 203* panos_nat_policy use :ref:`panos_nat_rule <ansible_2_5:panos_nat_rule_module>` instead. 204* vsphere_guest use :ref:`vmware_guest <ansible_2_5:vmware_guest_module>` instead. 205 206Noteworthy module changes 207------------------------- 208 209* The :ref:`stat <ansible_2_5:stat_module>` and :ref:`win_stat <ansible_2_5:win_stat_module>` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``. 210 211This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True`` 212and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is 213desired. 214 215* ``osx_say`` module was renamed into :ref:`say <ansible_2_5:say_module>`. 216* Several modules which could deal with symlinks had the default value of their ``follow`` option 217 changed as part of a feature to `standardize the behavior of follow 218 <https://github.com/ansible/proposals/issues/69>`_: 219 220 * The :ref:`file module <ansible_2_5:file_module>` changed from ``follow=False`` to ``follow=True`` because 221 its purpose is to modify the attributes of a file and most systems do not allow attributes to be 222 applied to symlinks, only to real files. 223 * The :ref:`replace module <ansible_2_5:replace_module>` had its ``follow`` parameter removed because it 224 inherently modifies the content of an existing file so it makes no sense to operate on the link 225 itself. 226 * The :ref:`blockinfile module <ansible_2_5:blockinfile_module>` had its ``follow`` parameter removed because 227 it inherently modifies the content of an existing file so it makes no sense to operate on the 228 link itself. 229 * In Ansible-2.5.3, the :ref:`template module <ansible_2_5:template_module>` became more strict about its 230 ``src`` file being proper utf-8. Previously, non-utf8 contents in a template module src file 231 would result in a mangled output file (the non-utf8 characters would be replaced with a unicode 232 replacement character). Now, on Python2, the module will error out with the message, "Template 233 source files must be utf-8 encoded". On Python3, the module will first attempt to pass the 234 non-utf8 characters through verbatim and fail if that does not succeed. 235 236Plugins 237======= 238 239As a developer, you can now use 'doc fragments' for common configuration options on plugin types that support the new plugin configuration system. 240 241Inventory 242--------- 243 244Inventory plugins have been fine tuned, and we have started to add some common features: 245 246* The ability to use a cache plugin to avoid costly API/DB queries is disabled by default. 247 If using inventory scripts, some may already support a cache, but it is outside of Ansible's knowledge and control. 248 Moving to the internal cache will allow you to use Ansible's existing cache refresh/invalidation mechanisms. 249 250* A new 'auto' plugin, enabled by default, that can automatically detect the correct plugin to use IF that plugin is using our 'common YAML configuration format'. 251 The previous host_list, script, yaml and ini plugins still work as they did, the auto plugin is now the last one we attempt to use. 252 If you had customized the enabled plugins you should revise the setting to include the new auto plugin. 253 254Shell 255----- 256 257Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables. 258 259For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``. 260 261Another new setting is ``admin_users`` which allows you to specify a list of users to be considered 'administrators'. Previously this was hardcoded to ``root``. It now it defaults to ``[root, toor, admin]``. This information is used when choosing between your ``remote_temp`` and ``system_temps`` directory. 262 263For a full list, check the shell plugin you are using, the default shell plugin is ``sh``. 264 265Those that had to work around the global configuration limitations can now migrate to a per host/group settings, 266but also note that the new defaults might conflict with existing usage if the assumptions don't correlate to your environment. 267 268Filter 269------ 270 271The lookup plugin API now throws an error if a non-iterable value is returned from a plugin. Previously, numbers or 272other non-iterable types returned by a plugin were accepted without error or warning. This change was made because plugins should always return a list. Please note that plugins that return strings and other non-list iterable values will not throw an error, but may cause unpredictable behavior. If you have a custom lookup plugin that does not return a list, you should modify it to wrap the return values in a list. 273 274Lookup 275------- 276 277A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup <lookup_plugins>` page for more details. 278 279 280Porting custom scripts 281====================== 282 283No notable changes. 284 285Network 286======= 287 288Expanding documentation 289----------------------- 290 291We're expanding the network documentation. There's new content and a :ref:`new Ansible Network landing page<network_guide>`. We will continue to build the network-related documentation moving forward. 292 293Top-level connection arguments will be removed in 2.9 294----------------------------------------------------- 295 296Top-level connection arguments like ``username``, ``host``, and ``password`` are deprecated and will be removed in version 2.9. 297 298**OLD** In Ansible < 2.4 299 300.. code-block:: yaml 301 302 - name: example of using top-level options for connection properties 303 ios_command: 304 commands: show version 305 host: "{{ inventory_hostname }}" 306 username: cisco 307 password: cisco 308 authorize: yes 309 auth_pass: cisco 310 311The deprecation warnings reflect this schedule. The task above, run in Ansible 2.5, will result in: 312 313.. code-block:: yaml 314 315 [DEPRECATION WARNING]: Param 'username' is deprecated. See the module docs for more information. This feature will be removed in version 316 2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. 317 [DEPRECATION WARNING]: Param 'password' is deprecated. See the module docs for more information. This feature will be removed in version 318 2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. 319 [DEPRECATION WARNING]: Param 'host' is deprecated. See the module docs for more information. This feature will be removed in version 2.9. 320 Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. 321 322We recommend using the new connection types ``network_cli`` and ``netconf`` (see below), using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules<become_network>` guide and the :ref:`platform documentation<platform_options>`. 323 324Adding persistent connection types ``network_cli`` and ``netconf`` 325------------------------------------------------------------------ 326 327Ansible 2.5 introduces two top-level persistent connection types, ``network_cli`` and ``netconf``. With ``connection: local``, each task passed the connection parameters, which had to be stored in your playbooks. With ``network_cli`` and ``netconf`` the playbook passes the connection parameters once, so you can pass them at the command line if you prefer. We recommend you use ``network_cli`` and ``netconf`` whenever possible. 328Note that eAPI and NX-API still require ``local`` connections with ``provider`` dictionaries. See the :ref:`platform documentation<platform_options>` for more information. Unless you need a ``local`` connection, update your playbooks to use ``network_cli`` or ``netconf`` and to specify your connection variables with standard Ansible connection variables: 329 330**OLD** In Ansible 2.4 331 332.. code-block:: yaml 333 334 --- 335 vars: 336 cli: 337 host: "{{ inventory_hostname }}" 338 username: operator 339 password: secret 340 transport: cli 341 342 tasks: 343 - nxos_config: 344 src: config.j2 345 provider: "{{ cli }}" 346 username: admin 347 password: admin 348 349**NEW** In Ansible 2.5 350 351.. code-block:: ini 352 353 [nxos:vars] 354 ansible_connection=network_cli 355 ansible_network_os=nxos 356 ansible_user=operator 357 ansible_password=secret 358 359.. code-block:: yaml 360 361 tasks: 362 - nxos_config: 363 src: config.j2 364 365Using a provider dictionary with either ``network_cli`` or ``netconf`` will result in a warning. 366 367 368Developers: Shared Module Utilities Moved 369----------------------------------------- 370 371Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``. 372 373* Platform-independent utilities are found in ``ansible.module_utils.network.common`` 374 375* Platform-specific utilities are found in ``ansible.module_utils.network.{{ platform }}`` 376 377If your module uses shared module utilities, you must update all references. For example, change: 378 379**OLD** In Ansible 2.4 380 381.. code-block:: python 382 383 from ansible.module_utils.vyos import get_config, load_config 384 385**NEW** In Ansible 2.5 386 387.. code-block:: python 388 389 from ansible.module_utils.network.vyos.vyos import get_config, load_config 390 391 392See the module utilities developer guide see :ref:`developing_module_utilities` for more information. 393