Fixes to the networking documentation (#3527)

docs/docsite/rst/network/dev_guide/developing_plugins_network.rst

@@ -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.

docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst

@@ -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``.

docs/docsite/rst/network/dev_guide/documenting_modules_network.rst

@@ -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:
 

docs/docsite/rst/network/user_guide/cli_parsing.rst

@@ -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(',') }}"

docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst

@@ -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::
 

docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst

@@ -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