From 41c066eff950f07f31d29ec5528debc217591538 Mon Sep 17 00:00:00 2001 From: John R Barker Date: Wed, 28 Feb 2018 15:54:58 +0000 Subject: [PATCH] Fix broken links (#36864) --- docs/docsite/rst/porting_guides/porting_guide_2.5.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst index deadc9b0f6..fc686be7b3 100644 --- a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst +++ b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst @@ -20,12 +20,12 @@ Playbook Dynamic includes and attribute inheritance ------------------------------------------ -In Ansible version 2.4, the concept of dynamic includes (``include_tasks``) versus static imports (``import_tasks``) was introduced to clearly define the differences in how ``include`` works between dynamic and static includes. +In Ansible version 2.4, the concept of dynamic includes (``include_tasks``) versus static imports (``import_tasks``) was introduced to clearly define the differences in how ``include`` works between dynamic and static includes. All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a static ``import_*`` would be inherited by the tasks within. -This 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. +This 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. To 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. @@ -128,8 +128,8 @@ The following modules no longer exist: * :ref:`cl_license ` use :ref:`nclu ` instead * :ref:`cl_interface ` use :ref:`nclu ` instead * :ref:`cl_bond ` use :ref:`nclu ` instead -* :ref:`ec2_vpc ` use :ref:`ec2_vpc_net ` along with supporting modules :ref:`ec2_vpc_igw `, :ref:`ec2_vpc_route_table `, :ref:`ec2_vpc_subnet `, :ref:`ec2_vpc_dhcp_options `, :ref:`ec2_vpc_nat_gateway `, :ref:`ec2_vpc_nacl ` instead. -* :ref:`ec2_ami_search ` instead +* :ref:`ec2_vpc ` use :ref:`ec2_vpc_net ` along with supporting modules :ref:`ec2_vpc_igw `, :ref:`ec2_vpc_route_table `, :ref:`ec2_vpc_subnet `, :ref:`ec2_vpc_dhcp_options `, :ref:`ec2_vpc_nat_gateway `, :ref:`ec2_vpc_nacl ` instead. +* :ref:`ec2_ami_search ` use :ref:`ec2_ami_facts ` instead * :ref:`docker ` use :ref:`docker_container ` and :ref:`docker_image ` instead Deprecation notices @@ -245,7 +245,7 @@ the standard Ansible infrastructure for controlling connections should be used. Developers: Shared Module Utilities Moved ----------------------------------------- -Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``. +Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``. * Platform-independent utilities are found in ``ansible.module_utils.network.common``