Replaced test.ping with test.version

Result of issue #52277

Any where `test.ping` still exists in the docs was left
because of the context in those docs.

doc/ref/cli/salt-unity.rst

@@ -9,7 +9,7 @@ Synopsis
 
 .. code-block:: bash
 
-    salt-unity salt '*' test.ping
+    salt-unity salt '*' test.version
 
 Description
 ===========
@@ -35,4 +35,4 @@ See also
 :manpage:`salt-minion(1)`
 :manpage:`salt-run(1)`
 :manpage:`salt-ssh(1)`
-:manpage:`salt-syndic(1)`
+:manpage:`salt-syndic(1)`

doc/ref/cli/salt.rst

@@ -11,9 +11,9 @@ Synopsis
 
     salt -E '.*' [ options ] sys.doc cmd
 
-    salt -G 'os:Arch.*' [ options ] test.ping
+    salt -G 'os:Arch.*' [ options ] test.version
 
-    salt -C 'G@os:Arch.* and webserv* or G@kernel:FreeBSD' [ options ] test.ping
+    salt -C 'G@os:Arch.* and webserv* or G@kernel:FreeBSD' [ options ] test.version
 
 Description
 ===========

doc/ref/configuration/index.rst

@@ -199,28 +199,28 @@ Sending Commands
 ================
 
 Communication between the Master and a Minion may be verified by running
-the ``test.ping`` command:
+the ``test.version`` command:
 
 .. code-block:: bash
 
-   [root@master ~]# salt alpha test.ping
+   [root@master ~]# salt alpha test.version
    alpha:
-       True
+       2018.3.4
 
 Communication between the Master and all Minions may be tested in a
 similar way:
 
 .. code-block:: bash
 
-   [root@master ~]# salt '*' test.ping
+   [root@master ~]# salt '*' test.version
    alpha:
-       True
+       2018.3.4
    bravo:
-       True
+       2018.3.4
    charlie:
-       True
+       2018.3.4
    delta:
-       True
+       2018.3.4
 
 Each of the Minions should send a ``True`` response as shown above.
 

doc/ref/executors/index.rst

@@ -30,7 +30,7 @@ The same could be done by command line:
 
 .. code-block:: bash
 
-    salt -t 40 --module-executors='[splay, direct_call]' --executor-opts='{splaytime: 30}' '*' test.ping
+    salt -t 40 --module-executors='[splay, direct_call]' --executor-opts='{splaytime: 30}' '*' test.version
 
 And the same command called via netapi will look like this:
 
@@ -43,7 +43,7 @@ And the same command called via netapi will look like this:
         -d '[{
             "client": "local",
             "tgt": "*",
-            "fun": "test.ping",
+            "fun": "test.version",
             "module_executors": ["splay", "direct_call"],
             "executor_opts": {"splaytime": 10}
             }]'

doc/ref/peer.rst

@@ -107,11 +107,11 @@ comes with a number of functions to execute peer communication in different
 ways. Currently there are three functions in the publish module. These examples
 will show how to test the peer system via the salt-call command.
 
-To execute test.ping on all minions:
+To execute test.version on all minions:
 
 .. code-block:: bash
 
-    # salt-call publish.publish \* test.ping
+    # salt-call publish.publish \* test.version
 
 To execute the manage.up runner:
 
@@ -123,7 +123,7 @@ To match minions using other matchers, use ``tgt_type``:
 
 .. code-block:: bash
 
-    # salt-call publish.publish 'webserv* and not G@os:Ubuntu' test.ping tgt_type='compound'
+    # salt-call publish.publish 'webserv* and not G@os:Ubuntu' test.version tgt_type='compound'
 
 .. note::
     In pre-2017.7.0 releases, use ``expr_form`` instead of ``tgt_type``.

doc/ref/returners/index.rst

@@ -31,7 +31,7 @@ Specifying what returners to use is done when the command is invoked:
 
 .. code-block:: bash
 
-    salt '*' test.ping --return redis_return
+    salt '*' test.version --return redis_return
 
 This command will ensure that the redis_return returner is used.
 
@@ -39,10 +39,10 @@ It is also possible to specify multiple returners:
 
 .. code-block:: bash
 
-    salt '*' test.ping --return mongo_return,redis_return,cassandra_return
+    salt '*' test.version --return mongo_return,redis_return,cassandra_return
 
 In this scenario all three returners will be called and the data from the
-test.ping command will be sent out to the three named returners.
+test.version command will be sent out to the three named returners.
 
 Writing a Returner
 ==================
@@ -61,13 +61,13 @@ Other optional functions can be included to add support for
 ``returner``
     The ``returner`` function must accept a single argument. The argument
     contains return data from the called minion function. If the minion
-    function ``test.ping`` is called, the value of the argument will be a
+    function ``test.version`` is called, the value of the argument will be a
     dictionary. Run the following command from a Salt master to get a sample
     of the dictionary:
 
 .. code-block:: bash
 
-    salt-call --local --metadata test.ping --out=pprint
+    salt-call --local --metadata test.version --out=pprint
 
 .. code-block:: python
 
@@ -246,12 +246,12 @@ Sample:
            "master_minion": {
                "fun_args": [],
                "jid": "20150330121011408195",
-               "return": true,
+               "return": "2018.3.4",
                "retcode": 0,
                "success": true,
                "cmd": "_return",
                "_stamp": "2015-03-30T12:10:12.708663",
-               "fun": "test.ping",
+               "fun": "test.version",
                "id": "master_minion"
            }
        }
@@ -267,9 +267,9 @@ Sample:
 
    {
        "local": {
-           "minion1": "test.ping",
-           "minion3": "test.ping",
-           "minion2": "test.ping"
+           "minion1": "test.version",
+           "minion3": "test.version",
+           "minion2": "test.version"
        }
    }
 
@@ -344,7 +344,7 @@ Testing the Returner
 The ``returner``, ``prep_jid``, ``save_load``, ``get_load``, and
 ``event_return`` functions can be tested by configuring the
 :conf_master:`master_job_cache` and `Event Returners`_ in the master config
-file and submitting a job to ``test.ping`` each minion from the master.
+file and submitting a job to ``test.version`` each minion from the master.
 
 Once you have successfully exercised the Master Job Cache functions, test the
 External Job Cache functions using the ``ret`` execution module.
@@ -352,7 +352,7 @@ External Job Cache functions using the ``ret`` execution module.
 .. code-block:: bash
 
     salt-call ret.get_jids cassandra_cql --output=json
-    salt-call ret.get_fun cassandra_cql test.ping --output=json
+    salt-call ret.get_fun cassandra_cql test.version --output=json
     salt-call ret.get_minions cassandra_cql --output=json
     salt-call ret.get_jid cassandra_cql 20150330121011408195 --output=json
 

doc/ref/runners/index.rst

@@ -122,6 +122,6 @@ responding to Salt calls could look like this:
         Print a list of all of the minions that are up
         '''
         client = salt.client.LocalClient(__opts__['conf_file'])
-        minions = client.cmd('*', 'test.ping', timeout=1)
+        minions = client.cmd('*', 'test.version', timeout=1)
         for minion in sorted(minions):
             print minion

doc/topics/blackout/index.rst

@@ -22,5 +22,5 @@ allowed during blackout. This is configured with the special pillar key
 .. code-block:: yaml
 
     minion_blackout_whitelist:
-      - test.ping
-      - pillar.get
+     - test.version
+     - pillar.get

doc/topics/cloud/aws.rst

@@ -324,7 +324,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    # salt 'ami.example.com' test.ping
+    # salt 'ami.example.com' test.version
 
 
 Required Settings

doc/topics/cloud/azure.rst

@@ -120,7 +120,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    salt newinstance test.ping
+    salt newinstance test.version
 
 
 Profile Options

doc/topics/cloud/azurearm.rst

@@ -121,7 +121,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    salt newinstance test.ping
+    salt newinstance test.version
 
 
 Profile Options

doc/topics/cloud/deploy.rst

@@ -123,7 +123,7 @@ Post-Deploy Commands
 Once a minion has been deployed, it has the option to run a salt command.
 Normally, this would be the :py:func:`state.apply <salt.modules.state.apply_>`,
 which would finish provisioning the VM. Another common option (for testing) is
-to use :py:func:`test.ping <salt.modules.test.ping>`. This is configured in the
+to use :py:func:`test.version <salt.modules.test.version>`. This is configured in the
 main cloud config file:
 
 .. code-block:: yaml

doc/topics/cloud/gce.rst

@@ -170,7 +170,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    salt gce-instance test.ping
+    salt gce-instance test.version
 
 
 GCE Specific Settings

doc/topics/cloud/libvirt.rst

@@ -84,7 +84,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    # salt my-centos7-clone test.ping
+    # salt my-centos7-clone test.version
 
 
 Required Settings

doc/topics/cloud/linode.rst

@@ -62,7 +62,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    salt linode-instance test.ping
+    salt linode-instance test.version
 
 
 Listing Sizes

doc/topics/cloud/opennebula.rst

@@ -96,7 +96,7 @@ Once the instance has been created with salt-minion installed, connectivity to i
 
 .. code-block:: bash
 
-    salt my-new-vm test.ping
+    salt my-new-vm test.version
 
 OpenNebula uses an image --> template --> virtual machine paradigm where the template draws on the image, or disk,
 and virtual machines are created from templates. Because of this, there is no need to define a ``size`` in the cloud

doc/topics/cloud/parallels.rst

@@ -91,7 +91,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    # salt myubuntu test.ping
+    # salt myubuntu test.version
 
 
 Required Settings

doc/topics/cloud/proxmox.rst

@@ -91,7 +91,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    # salt myubuntu test.ping
+    # salt myubuntu test.version
 
 
 Required Settings

doc/topics/cloud/saltify.rst

@@ -195,7 +195,7 @@ Connectivity to the new "Salted" instances can now be verified with Salt:
 
 .. code-block:: bash
 
-    salt 'my-instance-*' test.ping
+    salt 'my-instance-*' test.version
 
 Credential Verification
 =======================
@@ -203,7 +203,7 @@ Credential Verification
 Because the Saltify driver does not actually create VM's, unlike other
 salt-cloud drivers, it has special behaviour when the ``deploy`` option is set
 to ``False``. When the cloud configuration specifies ``deploy: False``, the
-Saltify driver will attept to authenticate to the target node(s) and return
+Saltify driver will attempt to authenticate to the target node(s) and return
 ``True`` for each one that succeeds. This can be useful to verify ports,
 protocols, services and credentials are correctly configured before a live
 deployment.

doc/topics/cloud/softlayer.rst

@@ -221,9 +221,9 @@ with its short hostname, ``my-vm``):
     Rejected Keys:
     #
     #
-    # salt my-vm.example.com test.ping
+    # salt my-vm.example.com test.version
     my-vm.example.com:
-        True
+        2018.3.4
     #
     #
     # salt-cloud -d my-vm.example.com
@@ -334,7 +334,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    # salt 'myserver.example.com' test.ping
+    # salt 'myserver.example.com' test.version
 
 Dedicated Host
 ~~~~~~~~~~~~~~

doc/topics/cloud/vagrant.rst

@@ -119,7 +119,7 @@ to it can be verified with Salt:
 
 .. code-block:: bash
 
-    salt my-id test.ping
+    salt my-id test.version
 
 .. _host provisioning example:
 

doc/topics/cloud/vexxhost.rst

@@ -111,7 +111,7 @@ the following command:
 
 .. code-block:: bash
 
-    # salt vh_instance1 test.ping
+    # salt vh_instance1 test.version
 
 You can now continue to provision new instances and they will all automatically
 be set up as minions of the master you've defined in the configuration file.

doc/topics/cloud/xen.rst

@@ -160,7 +160,7 @@ it can be verified with Salt:
 
 .. code-block:: bash
 
-    salt xenvm02 test.ping
+    salt xenvm02 test.version
 
 
 Listing Sizes

doc/topics/development/architecture.rst

@@ -109,7 +109,7 @@ against the command target.
 The typical lifecycle of a salt job from the perspective of the master
 might be as follows:
 
-1) A command is issued on the CLI. For example, 'salt my_minion test.ping'.
+1) A command is issued on the CLI. For example, 'salt my_minion test.version'.
 
 2) The 'salt' command uses LocalClient to generate a request to the salt master
    by connecting to the ReqServer on TCP:4506 and issuing the job.

doc/topics/development/hacking.rst

@@ -160,7 +160,7 @@ installation is working:
     salt-minion -c ./etc/salt -d
     salt-key -c ./etc/salt -L
     salt-key -c ./etc/salt -A
-    salt -c ./etc/salt '*' test.ping
+    salt -c ./etc/salt '*' test.version
 
 Running the master and minion in debug mode can be helpful when developing. To
 do this, add ``-l debug`` to the calls to ``salt-master`` and ``salt-minion``.

doc/topics/eauth/access_control.rst

@@ -67,7 +67,7 @@ other minions based on standard targets (all matchers are supported except the c
     external_auth:
       pam:
         dave:
-          - test.ping
+          - test.version
           - mongo\*:
             - network.*
           - log\*:
@@ -78,7 +78,7 @@ other minions based on standard targets (all matchers are supported except the c
         steve:
           - .*
 
-The above allows for all minions to be hit by test.ping by dave, and adds a
+The above allows for all minions to be hit by test.version by dave, and adds a
 few functions that dave can execute on other minions. It also allows steve
 unrestricted access to salt commands.
 

doc/topics/eauth/index.rst

@@ -180,7 +180,7 @@ any user on the same system as the master with the ``-a`` option:
 
 .. code-block:: bash
 
-    $ salt -a pam web\* test.ping
+    $ salt -a pam web\* test.version
 
 The system will ask the user for the credentials required by the
 authentication system and then publish the command.
@@ -198,7 +198,7 @@ adding a ``-T`` option when authenticating:
 
 .. code-block:: bash
 
-    $ salt -T -a pam web\* test.ping
+    $ salt -T -a pam web\* test.version
 
 Now a token will be created that has an expiration of 12 hours (by default).
 This token is stored in a file named ``salt_token`` in the active user's home

doc/topics/event/master_events.rst

@@ -69,7 +69,7 @@ Job events
         ``G@os_family:RedHat``, etc.
     :var tgt_type: The type of targeting used: ``glob``, ``grain``,
         ``compound``, etc.
-    :var fun: The function to run on minions: ``test.ping``,
+    :var fun: The function to run on minions: ``test.version``,
         ``network.interfaces``, etc.
     :var arg: A list of arguments to pass to the function that will be
         called.
@@ -85,7 +85,7 @@ Job events
     :var id: The minion ID.
     :var jid: The job ID.
     :var retcode: The return code for the job.
-    :var fun: The function the minion ran. E.g., ``test.ping``.
+    :var fun: The function the minion ran. E.g., ``test.version``.
     :var return: The data returned from the execution module.
 
 .. salt:event:: salt/job/<JID>/prog/<MID>/<RUN NUM>

doc/topics/installation/index.rst

@@ -25,12 +25,12 @@ The general installation process is as follows:
 4. Accept the Salt :ref:`minion keys <using-salt-key>` after the Salt minion
    connects.
 
-After this, you should be able to run a simple command and receive returns from
+After this, you should be able to run a simple command and receive salt version returns from
 all connected Salt minions.
 
 .. code-block:: bash
 
-    salt '*' test.ping
+    salt '*' test.version
 
 Quick Install
 -------------

doc/topics/installation/windows.rst

@@ -516,7 +516,7 @@ Testing the Salt minion
 
     .. code-block:: bash
 
-        sudo salt '*' test.ping
+        sudo salt '*' test.version
 
 You should get the following response: ``{'your minion hostname': True}``
 

doc/topics/proxyminion/demo.rst

@@ -98,7 +98,7 @@ the 'url' key above should say ``url: http://127.0.0.1:8000``
 
 .. code-block:: bash
 
-    salt p8000 test.ping
+    salt p8000 test.version
 
 8. The REST service implements a degenerately simple pkg and service provider as
    well as a small set of grains.  To "install" a package, use a standard

doc/topics/ssh/index.rst

@@ -127,7 +127,7 @@ command:
 
 .. code-block:: bash
 
-    salt-ssh '*' test.ping
+    salt-ssh '*' test.version
 
 Commands with ``salt-ssh`` follow the same syntax as the ``salt`` command.
 
@@ -217,8 +217,8 @@ YAML contents:
       ssh_wipe: True
 
 Instead of having to call
-``salt-ssh --config-dir=path/to/config/dir --max-procs=30 --wipe \* test.ping`` you
-can call ``salt-ssh \* test.ping``.
+``salt-ssh --config-dir=path/to/config/dir --max-procs=30 --wipe \* test.version`` you
+can call ``salt-ssh \* test.version``.
 
 Boolean-style options should be specified in their YAML representation.
 

doc/topics/targeting/batch.rst

@@ -9,11 +9,11 @@ supported.
 
 .. code-block:: bash
 
-    salt '*' -b 10 test.ping
+    salt '*' -b 10 test.version
 
     salt -G 'os:RedHat' --batch-size 25% apache.signal restart
 
-This will only run test.ping on 10 of the targeted minions at a time and then
+This will only run test.version on 10 of the targeted minions at a time and then
 restart apache on 25% of the minions matching ``os:RedHat`` at a time and work
 through them all until the task is complete. This makes jobs like rolling web
 server restarts behind a load balancer or doing maintenance on BSD firewalls

doc/topics/targeting/compound.rst

@@ -31,7 +31,7 @@ matches the :mod:`regular expression <python2:re>` ``web-dc1-srv.*``:
 
 .. code-block:: bash
 
-    salt -C 'webserv* and G@os:Debian or E@web-dc1-srv.*' test.ping
+    salt -C 'webserv* and G@os:Debian or E@web-dc1-srv.*' test.version
 
 That same example expressed in a :term:`top file` looks like the following:
 
@@ -48,20 +48,20 @@ Excluding a minion based on its ID is also possible:
 
 .. code-block:: bash
 
-    salt -C 'not web-dc1-srv' test.ping
+    salt -C 'not web-dc1-srv' test.version
 
 Versions prior to 2015.8.0 a leading ``not`` was not supported in compound
 matches. Instead, something like the following was required:
 
 .. code-block:: bash
 
-    salt -C '* and not G@kernel:Darwin' test.ping
+    salt -C '* and not G@kernel:Darwin' test.version
 
 Excluding a minion based on its ID was also possible:
 
 .. code-block:: bash
 
-    salt -C '* and not web-dc1-srv' test.ping
+    salt -C '* and not web-dc1-srv' test.version
 
 Precedence Matching
 -------------------
@@ -70,7 +70,7 @@ Matchers can be grouped together with parentheses to explicitly declare preceden
 
 .. code-block:: bash
 
-    salt -C '( ms-1 or G@id:ms-3 ) and G@id:ms-3' test.ping
+    salt -C '( ms-1 or G@id:ms-3 ) and G@id:ms-3' test.version
 
 .. note::
 

doc/topics/targeting/globbing.rst

@@ -31,39 +31,39 @@ Match all minions:
 
 .. code-block:: bash
 
-    salt '*' test.ping
+    salt '*' test.version
 
 Match all minions in the example.net domain or any of the example domains:
 
 .. code-block:: bash
 
-    salt '*.example.net' test.ping
-    salt '*.example.*' test.ping
+    salt '*.example.net' test.version
+    salt '*.example.*' test.version
 
 Match all the ``webN`` minions in the example.net domain (``web1.example.net``,
 ``web2.example.net`` … ``webN.example.net``):
 
 .. code-block:: bash
 
-    salt 'web?.example.net' test.ping
+    salt 'web?.example.net' test.version
 
 Match the ``web1`` through ``web5`` minions:
 
 .. code-block:: bash
 
-    salt 'web[1-5]' test.ping
+    salt 'web[1-5]' test.version
 
 Match the ``web1`` and ``web3`` minions:
 
 .. code-block:: bash
 
-    salt 'web[1,3]' test.ping
+    salt 'web[1,3]' test.version
 
 Match the ``web-x``, ``web-y``, and ``web-z`` minions:
 
 .. code-block:: bash
 
-    salt 'web-[x-z]' test.ping
+    salt 'web-[x-z]' test.version
 
 .. note::
 
@@ -81,7 +81,7 @@ Match both ``web1-prod`` and ``web1-devel`` minions:
 
 .. code-block:: bash
 
-    salt -E 'web1-(prod|devel)' test.ping
+    salt -E 'web1-(prod|devel)' test.version
 
 When using regular expressions in a State's :term:`top file`, you must specify
 the matcher as the first option. The following example executes the contents of
@@ -102,4 +102,4 @@ At the most basic level, you can specify a flat list of minion IDs:
 
 .. code-block:: bash
 
-    salt -L 'web1,web2,web3' test.ping
+    salt -L 'web1,web2,web3' test.version

doc/topics/targeting/grains.rst

@@ -10,7 +10,7 @@ For example, the following matches all CentOS minions:
 
 .. code-block:: bash
 
-    salt -G 'os:CentOS' test.ping
+    salt -G 'os:CentOS' test.version
 
 Match all minions with 64-bit CPUs, and return number of CPU cores for each
 matching minion:

doc/topics/targeting/index.rst

@@ -37,7 +37,7 @@ the target is the grain key followed by a glob expression: "os:Arch*".
 
 .. code-block:: bash
 
-    salt -G 'os:Fedora' test.ping
+    salt -G 'os:Fedora' test.version
 
 Will return True from all of the minions running Fedora.
 
@@ -62,7 +62,7 @@ This is well defined with an example:
 
 .. code-block:: bash
 
-    salt -C 'G@os:Debian and webser* or E@db.*' test.ping
+    salt -C 'G@os:Debian and webser* or E@db.*' test.version
 
 In this example any minion who's id starts with ``webser`` and is running
 Debian, or any minion who's id starts with db will be matched.

doc/topics/targeting/ipcidr.rst

@@ -9,14 +9,14 @@ notation).
 
 .. code-block:: bash
 
-    salt -S 192.168.40.20 test.ping
-    salt -S 2001:db8::/64 test.ping
+    salt -S 192.168.40.20 test.version
+    salt -S 2001:db8::/64 test.version
 
 Ipcidr matching can also be used in compound matches
 
 .. code-block:: bash
 
-    salt -C 'S@10.0.0.0/24 and G@os:Debian' test.ping
+    salt -C 'S@10.0.0.0/24 and G@os:Debian' test.version
 
 It is also possible to use in both pillar and state-matching
 

doc/topics/targeting/nodegroups.rst

@@ -57,7 +57,7 @@ To match a nodegroup on the CLI, use the ``-N`` command-line option:
 
 .. code-block:: bash
 
-    salt -N group1 test.ping
+    salt -N group1 test.version
 
 .. note::
 

doc/topics/targeting/pillar.rst

@@ -21,7 +21,7 @@ Example:
 
 .. code-block:: bash
 
-    salt -I 'somekey:specialvalue' test.ping
+    salt -I 'somekey:specialvalue' test.version
 
 Like with :ref:`Grains <targeting-grains>`, it is possible to use globbing
 as well as match nested values in Pillar, by adding colons for each level that
@@ -31,4 +31,4 @@ is being traversed. The below example would match minions with a pillar named
 
 .. code-block:: bash
 
-    salt -I 'foo:bar:baz*' test.ping
+    salt -I 'foo:bar:baz*' test.version

doc/topics/targeting/range.rst

@@ -72,11 +72,11 @@ One might target host1 through host100 in the test.com domain with Salt as follo
 
 .. code-block:: bash
 
-    salt --range %test:CLUSTER test.ping
+    salt --range %test:CLUSTER test.version
 
 
 The following salt command would target three hosts: ``frontend``, ``backend``, and ``mysql``:
 
 .. code-block:: bash
 
-    salt --range %test:APPS test.ping
+    salt --range %test:APPS test.version

doc/topics/thorium/index.rst

@@ -285,12 +285,12 @@ event bus, and returns ``True`` if that event's tag matches. For example:
         run_remote_ex:
           local.cmd:
             - tgt: '*'
-            - func: test.ping
+            - func: test.version
             - require:
               - check: salt/foo/*/bar
 
 This formula will look for an event whose tag is ``salt/foo/<anything>/bar`` and
-if it comes in, issue a ``test.ping`` to all minions.
+if it comes in, issue a ``test.version`` to all minions.
 
 
 Register Persistence

doc/topics/topology/syndic.rst

@@ -131,15 +131,15 @@ On the Master node:
     Unaccepted Keys:
     Rejected Keys:
 
-    # salt '*' test.ping
+    # salt '*' test.version
     minion_1:
-        True
+        2018.3.4
     minion_2:
-        True
+        2018.3.4
     minion_4:
-        True
+        2018.3.4
     minion_3:
-        True
+        2018.3.4
 
 Topology
 ========

doc/topics/tutorials/cloud_controller.rst

@@ -277,7 +277,7 @@ This command will return data about all of the hypervisors and respective
 virtual machines.
 
 Now that the new VM is booted it should have contacted the Salt Master, a
-``test.ping`` will reveal if the new VM is running.
+``test.version`` will reveal if the new VM is running.
 
 
 QEMU copy on write support

doc/topics/tutorials/docker_sls.rst

@@ -81,7 +81,7 @@ simple `salt-call` command:
 
 .. code-block:: bash
 
-    salt-call --local dockerng.call test test.ping
+    salt-call --local dockerng.call test test.version
     salt-call --local dockerng.call test network.interfaces
     salt-call --local dockerng.call test disk.usage
     salt-call --local dockerng.call test pkg.list_pkgs

doc/topics/tutorials/esxi_proxy_minion.rst

@@ -227,9 +227,10 @@ This allows you to use any number of potential fallback passwords.
 
     This scenario is especially true, and even slower, when the proxy
     minion first starts. If the correct password is not the first password
-    on the list, it may take up to a minute for ``test.ping`` to respond
-    with a ``True`` result. Once the initial authorization is complete, the
-    responses for commands will be a little faster.
+    on the list, it may take up to a minute for ``test.version`` to respond
+    with salt's version installed (Example: ``2018.3.4``. Once the initial 
+    authorization is complete, the responses for commands will be a little 
+    faster.
 
     To avoid these longer waiting periods, SaltStack recommends moving the
     correct password to the top of the list and restarting the proxy minion
@@ -366,7 +367,7 @@ proxy processes!
 
 .. code-block:: bash
 
-    # salt 'esxi-*' test.ping
+    # salt 'esxi-*' test.version
     esxi-1:
         True
     esxi-3:
@@ -377,7 +378,7 @@ Executing Commands
 ==================
 
 Now that you've configured your Proxy Minions and have them responding successfully
-to a ``test.ping``, we can start executing commands against the ESXi hosts via Salt.
+to a ``test.version``, we can start executing commands against the ESXi hosts via Salt.
 
 It's important to understand how this particular proxy works, and there are a couple
 of important pieces to be aware of in order to start running remote execution and

doc/topics/tutorials/firewall.rst

@@ -231,5 +231,5 @@ be set on the Master:
     needs to communicate with the listening network socket of
     ``salt-master`` on the *loopback* interface. Without this you will
     see no outgoing Salt traffic from the master, even for a simple
-    ``salt '*' test.ping``, because the ``salt`` client never reached
+    ``salt '*' test.version``, because the ``salt`` client never reached
     the ``salt-master`` to tell it to carry out the execution.

doc/topics/tutorials/modules.rst

@@ -27,14 +27,14 @@ following function. The default filter is a glob on the minion id. For example:
 
 .. code-block:: bash
 
-    salt '*' test.ping
-    salt '*.example.org' test.ping
+    salt '*' test.version
+    salt '*.example.org' test.version
 
 Targets can be based on minion system information using the Grains system:
 
 .. code-block:: bash
 
-    salt -G 'os:Ubuntu' test.ping
+    salt -G 'os:Ubuntu' test.version
 
 .. seealso:: :ref:`Grains system <targeting-grains>`
 
@@ -42,19 +42,19 @@ Targets can be filtered by regular expression:
 
 .. code-block:: bash
 
-    salt -E 'virtmach[0-9]' test.ping
+    salt -E 'virtmach[0-9]' test.version
 
 Targets can be explicitly specified in a list:
 
 .. code-block:: bash
 
-    salt -L 'foo,bar,baz,quo' test.ping
+    salt -L 'foo,bar,baz,quo' test.version
 
 Or Multiple target types can be combined in one command:
 
 .. code-block:: bash
 
-    salt -C 'G@os:Ubuntu and webser* or E@database.*' test.ping
+    salt -C 'G@os:Ubuntu and webser* or E@database.*' test.version
 
 
 function
@@ -74,7 +74,7 @@ Show all currently available minions:
 
 .. code-block:: bash
 
-    salt '*' test.ping
+    salt '*' test.version
 
 Run an arbitrary shell command:
 
@@ -99,4 +99,4 @@ Optional, keyword arguments are also supported:
 
     salt '*' pip.install salt timeout=5 upgrade=True
 
-They are always in the form of ``kwarg=argument``.
+They are always in the form of ``kwarg=argument``.

doc/topics/tutorials/multimaster_pki.rst

@@ -238,7 +238,7 @@ The minion will connect to the first master from its master list
     [DEBUG   ] Decrypting the current master AES key
 
 
-A test.ping on the master the minion is currently connected to should be run to
+A test.version on the master the minion is currently connected to should be run to
 test connectivity.
 
 If successful, that master should be turned off. A firewall-rule denying the

doc/topics/tutorials/walkthrough.rst

@@ -238,16 +238,16 @@ start with looks like this:
 
 .. code-block:: bash
 
-    salt '*' test.ping
+    salt '*' test.version
 
 The ``*`` is the target, which specifies all minions.
 
-``test.ping`` tells the minion to run the :py:func:`test.ping
-<salt.modules.test.ping>` function.
+``test.version`` tells the minion to run the :py:func:`test.version
+<salt.modules.test.version>` function.
 
-In the case of ``test.ping``, ``test`` refers to a :ref:`execution module
-<writing-execution-modules>`.  ``ping`` refers to the :py:func:`ping
-<salt.modules.test.ping>` function contained in the aforementioned ``test``
+In the case of ``test.version``, ``test`` refers to a :ref:`execution module
+<writing-execution-modules>`.  ``version`` refers to the :py:func:`version
+<salt.modules.test.version>` function contained in the aforementioned ``test``
 module.
 
 .. note::
@@ -257,12 +257,10 @@ module.
     services.
 
 The result of running this command will be the master instructing all of the
-minions to execute :py:func:`test.ping <salt.modules.test.ping>` in parallel
-and return the result.
-
-This is not an actual ICMP ping, but rather a simple function which returns ``True``.
-Using :py:func:`test.ping <salt.modules.test.ping>` is a good way of confirming that a minion is
-connected.
+minions to execute :py:func:`test.version <salt.modules.test.version>` in parallel
+and return the result. Using :py:func:`test.version <salt.modules.test.version>` 
+is a good way of confirming that a minion is connected, and reaffirm to the user 
+the salt version(s) they have installed on the minions.
 
 .. note::
 
@@ -271,7 +269,7 @@ connected.
     well by using the :conf_minion:`id` parameter.
 
 Of course, there are hundreds of other modules that can be called just as
-``test.ping`` can.  For example, the following would return disk usage on all
+``test.version`` can.  For example, the following would return disk usage on all
 targeted minions:
 
 .. code-block:: bash
@@ -591,7 +589,7 @@ This formula can be referenced via the following command:
 
 .. note::
     :py:func:`state.apply <salt.modules.state.apply_>` is just another remote
-    execution function, just like :py:func:`test.ping <salt.modules.test.ping>`
+    execution function, just like :py:func:`test.version <salt.modules.test.version>`
     or :py:func:`disk.usage <salt.modules.disk.usage>`. It simply takes the
     name of an SLS file as an argument.
 

doc/topics/tutorials/walkthrough_macosx.rst

@@ -412,9 +412,9 @@ following:
 
 .. code-block:: bash
 
-    sudo salt '*' test.ping
+    sudo salt '*' test.version
 
-You should see your minion answering the ping. It's now time to do some
+You should see your minion answering with its salt version. It's now time to do some
 configuration.