* nxos_mtu use :ref:`nxos_system <nxos_system_module>`'s ``system_mtu`` option or :ref:`nxos_interface <nxos_interface_module>` instead
* cl_interface_policy use :ref:`nclu <nclu_module>` instead
* cl_bridge use :ref:`nclu <nclu_module>` instead
* cl_img_install use :ref:`nclu <nclu_module>` instead
* cl_ports use :ref:`nclu <nclu_module>` instead
* cl_license use :ref:`nclu <nclu_module>` instead
* cl_interface use :ref:`nclu <nclu_module>` instead
* cl_bond use :ref:`nclu <nclu_module>` instead
* ec2_vpc use :ref:`ec2_vpc_net <ec2_vpc_net_module>` along with supporting modules :ref:`ec2_vpc_igw <ec2_vpc_igw_module>`, :ref:`ec2_vpc_route_table <ec2_vpc_route_table_module>`, :ref:`ec2_vpc_subnet <ec2_vpc_subnet_module>`, :ref:`ec2_vpc_dhcp_option <ec2_vpc_dhcp_option_module>`, :ref:`ec2_vpc_nat_gateway <ec2_vpc_nat_gateway_module>`, :ref:`ec2_vpc_nacl <ec2_vpc_nacl_module>` instead.
* ec2_ami_search use :ref:`ec2_ami_facts <ec2_ami_facts_module>` instead
* docker use :ref:`docker_container <docker_container_module>` and :ref:`docker_image <docker_image_module>` instead
* 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
* cl_interface_policy use :ref:`nclu <ansible_2_5:nclu_module>` instead
* cl_bridge use :ref:`nclu <ansible_2_5:nclu_module>` instead
* cl_img_install use :ref:`nclu <ansible_2_5:nclu_module>` instead
* cl_ports use :ref:`nclu <ansible_2_5:nclu_module>` instead
* cl_license use :ref:`nclu <ansible_2_5:nclu_module>` instead
* cl_interface use :ref:`nclu <ansible_2_5:nclu_module>` instead
* cl_bond use :ref:`nclu <ansible_2_5:nclu_module>` instead
* 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.
* ec2_ami_search use :ref:`ec2_ami_facts <ansible_2_5:ec2_ami_facts_module>` instead
* docker use :ref:`docker_container <ansible_2_5:docker_container_module>` and :ref:`docker_image <ansible_2_5:docker_image_module>` instead
..note::
@ -196,37 +196,37 @@ Deprecation notices
The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly.
* 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>`_.
* nxos_ip_interface use :ref:`nxos_l3_interface <nxos_l3_interface_module>` instead.
* nxos_portchannel use :ref:`nxos_linkagg <nxos_linkagg_module>` instead.
* nxos_switchport use :ref:`nxos_l2_interface <nxos_l2_interface_module>` instead.
* panos_security_policy use :ref:`panos_security_rule <panos_security_rule_module>` instead.
* panos_nat_policy use :ref:`panos_nat_rule <panos_nat_rule_module>` instead.
* vsphere_guest use :ref:`vmware_guest <vmware_guest_module>` instead.
* nxos_ip_interface use :ref:`nxos_l3_interface <ansible_2_5:nxos_l3_interface_module>` instead.
* nxos_portchannel use :ref:`nxos_linkagg <ansible_2_5:nxos_linkagg_module>` instead.
* nxos_switchport use :ref:`nxos_l2_interface <ansible_2_5:nxos_l2_interface_module>` instead.
* panos_security_policy use :ref:`panos_security_rule <ansible_2_5:panos_security_rule_module>` instead.
* panos_nat_policy use :ref:`panos_nat_rule <ansible_2_5:panos_nat_rule_module>` instead.
* vsphere_guest use :ref:`vmware_guest <ansible_2_5:vmware_guest_module>` instead.
Noteworthy module changes
-------------------------
* The :ref:`stat <stat_module>` and :ref:`win_stat <win_stat_module>` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``.
* 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``.
This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True``
and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is
desired.
* ``osx_say`` module was renamed into :ref:`say <say_module>`.
* ``osx_say`` module was renamed into :ref:`say <ansible_2_5:say_module>`.
* Several modules which could deal with symlinks had the default value of their ``follow`` option
changed as part of a feature to `standardize the behavior of follow
@ -114,7 +114,7 @@ Before the introduction of AnsiBallZ in Ansible 2.1, using ``__file__`` worked i
Ansible 2.8 will no longer create a temporary file for ``AnsibleModule``; instead it will read the file out of a zip file. This change should speed up module execution, but it does mean that starting with Ansible 2.8, referencing ``__file__`` will always fail in ``AnsibleModule``.
If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module <apt_module>`:
If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module <ansible_2_7:apt_module>`:
..code-block:: diff
@ -175,19 +175,19 @@ Deprecation notices
The following modules will be removed in Ansible 2.11. Please update your playbooks accordingly.
* ``na_cdot_aggregate`` use :ref:`na_ontap_aggregate <na_ontap_aggregate_module>` instead.
* ``na_cdot_license`` use :ref:`na_ontap_license <na_ontap_license_module>` instead.
* ``na_cdot_lun`` use :ref:`na_ontap_lun <na_ontap_lun_module>` instead.
* ``na_cdot_qtree`` use :ref:`na_ontap_qtree <na_ontap_qtree_module>` instead.
* ``na_cdot_svm`` use :ref:`na_ontap_svm <na_ontap_svm_module>` instead.
* ``na_cdot_user`` use :ref:`na_ontap_user <na_ontap_user_module>` instead.
* ``na_cdot_user_role`` use :ref:`na_ontap_user_role <na_ontap_user_role_module>` instead.
* ``na_cdot_volume`` use :ref:`na_ontap_volume <na_ontap_volume_module>` instead.
* ``sf_account_manager`` use :ref:`na_elementsw_account<na_elementsw_account_module>` instead.
* ``sf_check_connections`` use :ref:`na_elementsw_check_connections<na_elementsw_check_connections_module>` instead.
* ``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule<na_elementsw_snapshot_schedule_module>` instead.
* ``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group<na_elementsw_access_group_module>` instead.
* ``sf_volume_manager`` use :ref:`na_elementsw_volume<na_elementsw_volume_module>` instead.
* ``na_cdot_aggregate`` use :ref:`na_ontap_aggregate <ansible_2_7:na_ontap_aggregate_module>` instead.
* ``na_cdot_license`` use :ref:`na_ontap_license <ansible_2_7:na_ontap_license_module>` instead.
* ``na_cdot_lun`` use :ref:`na_ontap_lun <ansible_2_7:na_ontap_lun_module>` instead.
* ``na_cdot_qtree`` use :ref:`na_ontap_qtree <ansible_2_7:na_ontap_qtree_module>` instead.
* ``na_cdot_svm`` use :ref:`na_ontap_svm <ansible_2_7:na_ontap_svm_module>` instead.
* ``na_cdot_user`` use :ref:`na_ontap_user <ansible_2_7:na_ontap_user_module>` instead.
* ``na_cdot_user_role`` use :ref:`na_ontap_user_role <ansible_2_7:na_ontap_user_role_module>` instead.
* ``na_cdot_volume`` use :ref:`na_ontap_volume <ansible_2_7:na_ontap_volume_module>` instead.
* ``sf_account_manager`` use :ref:`na_elementsw_account<ansible_2_7:na_elementsw_account_module>` instead.
* ``sf_check_connections`` use :ref:`na_elementsw_check_connections<ansible_2_7:na_elementsw_check_connections_module>` instead.
* ``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule<ansible_2_7:na_elementsw_snapshot_schedule_module>` instead.
* ``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group<ansible_2_7:na_elementsw_access_group_module>` instead.
* ``sf_volume_manager`` use :ref:`na_elementsw_volume<ansible_2_7:na_elementsw_volume_module>` instead.
@ -389,17 +389,17 @@ The following modules will be removed in Ansible 2.12. Please update your playbo
* ``foreman`` use `foreman-ansible-modules <https://github.com/theforeman/foreman-ansible-modules>`_ instead.
* ``katello`` use `foreman-ansible-modules <https://github.com/theforeman/foreman-ansible-modules>`_ instead.
* ``github_hooks`` use :ref:`github_webhook <github_webhook_module>` and :ref:`github_webhook_facts <github_webhook_facts_module>` instead.
* ``digital_ocean`` use :ref:`digital_ocean_droplet <digital_ocean_droplet_module>` instead.
* ``gce`` use :ref:`gcp_compute_instance <gcp_compute_instance_module>` instead.
* ``gcspanner`` use :ref:`gcp_spanner_instance <gcp_spanner_instance_module>` and :ref:`gcp_spanner_database <gcp_spanner_database_module>` instead.
* ``gcdns_record`` use :ref:`gcp_dns_resource_record_set <gcp_dns_resource_record_set_module>` instead.
* ``gcdns_zone`` use :ref:`gcp_dns_managed_zone <gcp_dns_managed_zone_module>` instead.
* ``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule <gcp_compute_global_forwarding_rule_module>` or :ref:`gcp_compute_forwarding_rule <gcp_compute_forwarding_rule_module>` instead.
* ``gcp_healthcheck`` use :ref:`gcp_compute_health_check <gcp_compute_health_check_module>`, :ref:`gcp_compute_http_health_check <gcp_compute_http_health_check_module>`, or :ref:`gcp_compute_https_health_check <gcp_compute_https_health_check_module>` instead.
* ``gcp_backend_service`` use :ref:`gcp_compute_backend_service <gcp_compute_backend_service_module>` instead.
* ``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy <gcp_compute_target_http_proxy_module>` instead.
* ``gcp_url_map`` use :ref:`gcp_compute_url_map <gcp_compute_url_map_module>` instead.
* ``github_hooks`` use :ref:`github_webhook <ansible_2_8:github_webhook_module>` and :ref:`github_webhook_facts <ansible_2_8:github_webhook_facts_module>` instead.
* ``digital_ocean`` use :ref:`digital_ocean_droplet <ansible_2_8:digital_ocean_droplet_module>` instead.
* ``gce`` use :ref:`gcp_compute_instance <ansible_2_8:gcp_compute_instance_module>` instead.
* ``gcspanner`` use :ref:`gcp_spanner_instance <ansible_2_8:gcp_spanner_instance_module>` and :ref:`gcp_spanner_database <ansible_2_8:gcp_spanner_database_module>` instead.
* ``gcdns_record`` use :ref:`gcp_dns_resource_record_set <ansible_2_8:gcp_dns_resource_record_set_module>` instead.
* ``gcdns_zone`` use :ref:`gcp_dns_managed_zone <ansible_2_8:gcp_dns_managed_zone_module>` instead.
* ``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule <ansible_2_8:gcp_compute_global_forwarding_rule_module>` or :ref:`gcp_compute_forwarding_rule <ansible_2_8:gcp_compute_forwarding_rule_module>` instead.
* ``gcp_healthcheck`` use :ref:`gcp_compute_health_check <ansible_2_8:gcp_compute_health_check_module>`, :ref:`gcp_compute_http_health_check <ansible_2_8:gcp_compute_http_health_check_module>`, or :ref:`gcp_compute_https_health_check <ansible_2_8:gcp_compute_https_health_check_module>` instead.
* ``gcp_backend_service`` use :ref:`gcp_compute_backend_service <ansible_2_8:gcp_compute_backend_service_module>` instead.
* ``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy <ansible_2_8:gcp_compute_target_http_proxy_module>` instead.
* ``gcp_url_map`` use :ref:`gcp_compute_url_map <ansible_2_8:gcp_compute_url_map_module>` instead.
* ``panos`` use the `Palo Alto Networks Ansible Galaxy role <https://galaxy.ansible.com/PaloAltoNetworks/paloaltonetworks>`_ instead.
@ -453,7 +453,7 @@ Noteworthy module changes
* The ``docker_volume`` module has deprecated the returned fact ``docker_container``. The same value is
available as the returned variable ``volume``. The returned fact will be removed in Ansible 2.12.
* The ``docker_service`` module was renamed to :ref:`docker_compose <docker_compose_module>`.
* The ``docker_service`` module was renamed to :ref:`docker_compose <ansible_2_8:docker_compose_module>`.
* The renamed ``docker_compose`` module used to return one fact per service, named same as the service. A dictionary
of these facts is returned as the regular return value ``services``. The returned facts will be removed in
The Ansible ACI modules provide a user-friendly interface to managing your ACI environment using Ansible playbooks.
For instance ensuring that a specific tenant exists, is done using the following Ansible task using module :ref:`aci_tenant <aci_tenant_module>`:
For instance ensuring that a specific tenant exists, is done using the following Ansible task using the aci_tenant module:
..code-block:: yaml
@ -65,7 +65,7 @@ For instance ensuring that a specific tenant exists, is done using the following
description: Customer XYZ
state: present
A complete list of existing ACI modules is available for the latest stable release on the :ref:`list of network modules <network_modules>`. You can also view the `current development version <https://docs.ansible.com/ansible/devel/modules/list_of_network_modules.html#aci>`_.
A complete list of existing ACI modules is available on the content tab of the `ACI collection on Ansible Galaxy <https://galaxy.ansible.com/cisco/aci>`_.
If you want to learn how to write your own ACI modules to contribute, look at the :ref:`Developing Cisco ACI modules <aci_dev_guide>` section.
@ -99,7 +99,7 @@ Or query all objects.
state: query
register: all_tenants
After registering the return values of the :ref:`aci_tenant <aci_tenant_module>` task as shown above, you can access all tenant information from variable ``all_tenants``.
After registering the return values of the aci_tenant task as shown above, you can access all tenant information from variable ``all_tenants``.
Running on the controller locally
@ -443,17 +443,17 @@ Using ACI REST with Ansible
---------------------------
While already a lot of ACI modules exists in the Ansible distribution, and the most common actions can be performed with these existing modules, there's always something that may not be possible with off-the-shelf modules.
The :ref:`aci_rest <aci_rest_module>` module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly.
The aci_rest module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly.
Built-in idempotency
....................
Because the APIC REST API is intrinsically idempotent and can report whether a change was made, the :ref:`aci_rest <aci_rest_module>` module automatically inherits both capabilities and is a first-class solution for automating your ACI infrastructure. As a result, users that require more powerful low-level access to their ACI infrastructure don't have to give up on idempotency and don't have to guess whether a change was performed when using the :ref:`aci_rest <aci_rest_module>` module.
Because the APIC REST API is intrinsically idempotent and can report whether a change was made, the aci_rest module automatically inherits both capabilities and is a first-class solution for automating your ACI infrastructure. As a result, users that require more powerful low-level access to their ACI infrastructure don't have to give up on idempotency and don't have to guess whether a change was performed when using the aci_rest module.
Using the aci_rest module
.........................
The :ref:`aci_rest <aci_rest_module>` module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require the path to end with ``.json``.
The aci_rest module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require the path to end with ``.json``.
When you're making modifications, you can use the POST or DELETE methods, whereas doing just queries require the GET method.
@ -528,7 +528,7 @@ More information
................
Plenty of resources exist to learn about ACI's APIC REST interface, we recommend the links below:
- `The ACI collection on Ansible Galaxy <https://galaxy.ansible.com/cisco/aci>`_
- `APIC REST API Configuration Guide <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/rest_cfg/2_1_x/b_Cisco_APIC_REST_API_Configuration_Guide.html>`_ -- Detailed guide on how the APIC REST API is designed and used, incl. many examples
- `APIC Management Information Model reference <https://developer.cisco.com/docs/apic-mim-ref/>`_ -- Complete reference of the APIC object model
- `Cisco DevNet Learning Labs about ACI and REST <https://learninglabs.cisco.com/labs/tags/ACI,REST>`_
@ -591,7 +591,7 @@ APIC error messages
The following error messages may occur and this section can help you understand what exactly is going on and how to fix/avoid them.
APIC Error 122: unknown managed object class 'polUni'
In case you receive this error while you are certain your :ref:`aci_rest <aci_rest_module>` payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (e.g. the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload, which are easier to construct correctly and modify later.
In case you receive this error while you are certain your aci_rest payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (e.g. the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload, which are easier to construct correctly and modify later.
APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag
@ -606,7 +606,7 @@ The following error messages may occur and this section can help you understand
Known issues
------------
The :ref:`aci_rest <aci_rest_module>` module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of this module.
The aci_rest module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of this module.
All below issues either have been reported to the vendor, and most can simply be avoided.
@ -645,8 +645,8 @@ You will find our roadmap, an overview of open ACI issues and pull-requests, and
..seealso::
:ref:`List of ACI modules <aci_network_modules>`
A complete list of supported ACI modules.
`ACI collection on Ansible Galaxy <https://galaxy.ansible.com/cisco/aci>`_
View the content tab for a complete list of supported ACI modules.