Fixes to the networking documentation (#3527) (#3529)

(cherry picked from commit 02adbd3a6f)

Co-authored-by: Jayant Sogikar <jayantsogikar@gmail.com>
This commit is contained in:
patchback[bot]
2026-03-18 09:56:57 +00:00
committed by GitHub
parent 68d9cf7b42
commit 47fadcd524
6 changed files with 8 additions and 15 deletions

View File

@@ -211,7 +211,7 @@ The following sample shows the start of a custom cli_parser plugin:
""" Sample cli_parser plugin
"""
# Use the follow extension when loading a template
# Use the following extension when loading a template
DEFAULT_TEMPLATE_EXTENSION = "txt"
# Provide the contents of the template to the parse function
PROVIDE_TEMPLATE_CONTENTS = True
@@ -250,7 +250,7 @@ The following task uses this custom cli_parser plugin:
ansible.netcommon.cli_parse:
command: ls -l
parser:
name: my_organiztion.my_collection.custom_parser
name: my_organization.my_collection.custom_parser
To develop a custom plugin:
- Each cli_parser plugin requires a ``CliParser`` class.

View File

@@ -57,11 +57,6 @@ Modules in Ansible-maintained collections must support these state values. If yo
The states ``rendered``, ``gathered``, and ``parsed`` do not perform any change on the device.
.. seealso::
`Deep Dive on VLANs Resource Modules for Network Automation <https://www.ansible.com/blog/deep-dive-on-vlans-resource-modules-for-network-automation>`_
Walkthrough of how state values are implemented for VLANs.
Developing network and security resource modules
=================================================
@@ -88,7 +83,7 @@ The resource module builder has the following capabilities:
- Uses a defined model to scaffold a resource module directory layout and initial class files.
- Scaffolds either an Ansible role or a collection.
- Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring.
- Subsequent uses of the resource module builder will only replace the module argspec and file containing the module docstring.
- Allows you to store complex examples along side the model in the same directory.
- Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed.
- Generates working sample modules for both ``<network_os>_<resource>`` and ``<network_os>_facts``.

View File

@@ -33,7 +33,7 @@ Ensure that the table stays formatted correctly. That is:
Adding a platform-specific options section
==========================================
The platform- specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules. Name your new file ``platform_<name>.rst`` (for example, ``platform_myos.rst``). The platform name should match the module prefix. See `platform_eos.rst <https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/network/user_guide/platform_eos.rst>`_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section.
The platform-specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules. Name your new file ``platform_<name>.rst`` (for example, ``platform_myos.rst``). The platform name should match the module prefix. See `platform_eos.rst <https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/network/user_guide/platform_eos.rst>`_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section.
Your platform-specific section should include the following:

View File

@@ -217,7 +217,7 @@ Create the native template to match this output and store it as ``templates/fedo
result:
"{{ name }}":
name: "{{ name }}"
loopback: "{{ 'LOOPBACK' in stats.split(',') }}"
loopback: "{{ 'LOOPBACK' in properties.split(',') }}"
up: "{{ 'UP' in properties.split(',') }}"
carrier: "{{ not 'NO-CARRIER' in properties.split(',') }}"
broadcast: "{{ 'BROADCAST' in properties.split(',') }}"

View File

@@ -151,7 +151,7 @@ Ansible facts modules gather system information 'facts' that are available to th
Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ansplugin:`arista.eos.eos_facts <arista.eos.eos_facts#module>`, :ansplugin:`cisco.ios.ios_facts <cisco.ios.ios_facts#module>` and :ansplugin:`vyos.vyos.vyos_facts <vyos.vyos.vyos_facts#module>` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file.
Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ansplugin:`arista.eos.eos_facts <arista.eos.eos_facts#module>` and :ansplugin:`vyos.vyos.vyos_facts <vyos.vyos.vyos_facts#module>`. We can use the facts, such as ``ansible_net_version`` late on in the "Display some facts" task.
Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ansplugin:`arista.eos.eos_facts <arista.eos.eos_facts#module>` and :ansplugin:`vyos.vyos.vyos_facts <vyos.vyos.vyos_facts#module>`. We can use the facts, such as ``ansible_net_version`` later on in the "Display some facts" task.
To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`.
@@ -323,8 +323,6 @@ If `ansible-playbook` fails, please follow the debug steps in :ref:`network_debu
Example 2: simplifying playbooks with platform-independent modules
==================================================================
(This example originally appeared in the `Deep Dive on cli_command for Network Automation <https://www.ansible.com/blog/deep-dive-on-cli-command-for-network-automation>`_ blog post by Sean Cavanaugh -`@IPvSean <https://github.com/IPvSean>`_).
If you have two or more network platforms in your environment, you can use the platform-independent modules to simplify your playbooks. You can use platform-independent modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks.
.. note::
@@ -474,7 +472,7 @@ Note that when using variables from tasks in this way we use double quotes (``"`
Troubleshooting
===============
If you receive an connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`.
If you receive a connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`.
.. seealso::

View File

@@ -17,7 +17,7 @@ Ansible network automation errors generally fall into one of the following categ
:Authentication issues:
* Not correctly specifying credentials
* Remote device (network switch/router) not falling back to other other authentication methods
* Remote device (network switch/router) not falling back to other authentication methods
* SSH key issues
:Timeout issues:
* Can occur when trying to pull a large amount of data