Merge forward 2019.3 to develop

.gitignore

@@ -2,7 +2,7 @@
 /src
 *.py[co]
 pkg/arch/*.tar.xz
-*.sw[pon]
+*.sw[a-p]
 doc/_build
 dist
 MANIFEST
@@ -85,6 +85,9 @@ tests/unit/templates/roots
 # Pycharm
 .idea
 
+# VS Code
+.vscode
+
 # Ignore the log directory created by tests
 /logs
 tests/integration/cloud/providers/logs

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,30 +199,31 @@ 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.
+Each of the Minions should send a ``2018.3.4`` response as shown above, 
+or any other salt version installed.
 
 What's Next?
 ============

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,18 +31,18 @@ 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.
 
 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,15 +344,15 @@ 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.
 
 .. 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

@@ -328,7 +328,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

@@ -108,7 +108,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

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

doc/topics/cloud/config.rst

@@ -28,9 +28,9 @@ Minion Configuration
 ====================
 
 The default minion configuration is set up in this file. Minions created by
-salt-cloud derive their configuration from this file.  Almost all parameters
-found in :ref:`Configuring the Salt Minion <configuration-salt-minion>` can
-be used here.
+salt-cloud derive their configuration from this file. Almost all parameters
+found in :ref:`Configuring the Salt Minion <configuration-salt-minion>` can be
+used here.
 
 .. code-block:: yaml
 
@@ -44,7 +44,7 @@ and its listening port, if the port is not set to the default.
 Similar to most other settings, Minion configuration settings are inherited
 across configuration files. For example, the master setting might be contained
 in the main ``cloud`` configuration file as demonstrated above, but additional
-settings can be placed in the provider or profile:
+settings can be placed in the provider, profile or map configuration files:
 
 .. code-block:: yaml
 

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

@@ -202,7 +202,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
 
 Bulk Deployments
 ----------------
@@ -251,7 +251,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.