@ -182,15 +182,9 @@ When creating a new module there are a few things to keep in mind:
- Use the full cmdlet name instead of aliases, e.g. ``Remove-Item`` over ``rm``
- Use the full cmdlet name instead of aliases, e.g. ``Remove-Item`` over ``rm``
- Use named parameters with cmdlets, e.g. ``Remove-Item -Path C:\temp`` over ``Remove-Item C:\temp``
- Use named parameters with cmdlets, e.g. ``Remove-Item -Path C:\temp`` over ``Remove-Item C:\temp``
A very basic powershell module `win_environment <https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_environment.ps1>`_ is included below. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met.
A very basic Powershell module `win_environment <https://github.com/ansible-collections/ansible.windows/blob/master/plugins/modules/win_environment.ps1>`_ incorporates best practices for Powershell modules. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met.
A slightly more advanced module is `win_uri <https://github.com/ansible-collections/ansible.windows/blob/master/plugins/modules/win_uri.ps1>`_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions.
A slightly more advanced module is `win_uri <https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_uri.ps1>`_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions.
As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument
As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument
spec. The following options can be set at the root level of the argument spec:
spec. The following options can be set at the root level of the argument spec:
Links on this page may not point to the most recent versions of plugins. In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide <https://github.com/ansible-collections/general/blob/master/README.rst>`_.
Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface
Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface
for Ansible to execute tasks on those network devices.
for Ansible to execute tasks on those network devices.
@ -37,14 +41,7 @@ Plugins are self-documenting. Each plugin should document its configuration opti
Plugin list
Plugin list
-----------
-----------
You can use ``ansible-doc -t cliconf -l`` to see the list of available plugins.
These plugins have migrated to a collection. Updates on where to find and how to use them will be coming soon.
Use ``ansible-doc -t cliconf <plugin name>`` to see detailed documentation and examples.
Links on this page may not point to the most recent versions of plugins. In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide <https://github.com/ansible-collections/general/blob/master/README.rst>`_.
Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the
Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the
device.
device.
@ -58,15 +62,7 @@ See the full working example at https://github.com/network-automation/httpapi.
Plugin List
Plugin List
-----------
-----------
You can use ``ansible-doc -t httpapi -l`` to see the list of available plugins.
These plugins have migrated to a collection. Updates on where to find and how to use them will be coming soon.
Use ``ansible-doc -t httpapi <plugin name>`` to see detailed documentation and examples.
Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface
..warning::
for Ansible to execute tasks on those network devices.
Links on this page may not point to the most recent versions of plugins. In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide <https://github.com/ansible-collections/general/blob/master/README.rst>`_.
Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices.
These plugins generally correspond one-to-one to network device platforms. The appropriate netconf plugin will
These plugins generally correspond one-to-one to network device platforms. The appropriate netconf plugin will
thus be automatically loaded based on the ``ansible_network_os`` variable. If the platform supports standard
thus be automatically loaded based on the ``ansible_network_os`` variable. If the platform supports standard
@ -42,14 +45,7 @@ Plugins are self-documenting. Each plugin should document its configuration opti
Plugin list
Plugin list
-----------
-----------
You can use ``ansible-doc -t netconf -l`` to see the list of available plugins.
These plugins have migrated to a collection. Updates on where to find and how to use them will be coming soon.
Use ``ansible-doc -t netconf <plugin name>`` to see detailed documentation and examples.
Links on this page may not point to the most recent versions of modules. In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy <https://galaxy.ansible.com>`_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide <https://github.com/ansible-collections/general/blob/master/README.rst>`_. We expect the 2.10 Porting Guide to change frequently up to the 2.10 release. Follow the conversations about collections on our various :ref:`communication` channels for the latest information on the status of the ``devel`` branch.
This section discusses the behavioral changes between Ansible 2.9 and Ansible 2.10.
This section discusses the behavioral changes between Ansible 2.9 and Ansible 2.10.
It 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.
It 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.
@ -39,6 +43,9 @@ Deprecated
Modules
Modules
=======
=======
..warning::
Links on this page may not point to the most recent versions of modules. We will update them when we can.
Modules removed
Modules removed
---------------
---------------
@ -53,9 +60,8 @@ Deprecation notices
The following modules will be removed in Ansible 2.14. Please update your playbooks accordingly.
The following modules will be removed in Ansible 2.14. Please update your playbooks accordingly.
* ldap_attr use :ref:`ldap_attrs <ldap_attrs_module>` instead.
* ldap_attr use ldap_attrs instead.
* vyos_static_route use :ref:`vyos_static_routes <vyos_static_routes_module>` instead.
* vyos_static_route use vyos_static_routes instead.
The following functionality will be removed in Ansible 2.14. Please update update your playbooks accordingly.
The following functionality will be removed in Ansible 2.14. Please update update your playbooks accordingly.
@ -95,7 +101,7 @@ The following functionality will change in Ansible 2.14. Please update update yo
The following modules will be removed in Ansible 2.14. Please update your playbooks accordingly.
The following modules will be removed in Ansible 2.14. Please update your playbooks accordingly.
* ``vmware_dns_config`` use :ref:`vmware_host_dns <vmware_host_dns_module>` instead.
* ``vmware_dns_config`` use vmware_host_dns instead.