Merge branch '2018.3' into fix_choco_retcode

doc/Makefile

@@ -66,7 +66,7 @@ clean:
 
 # User-friendly check for sphinx-build
 check_sphinx-build:
-	@which $(SPHINXBUILD) >/dev/null 2>&1 || (echo "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)" >&2; false)
+	@which $(SPHINXBUILD) >/dev/null 2>&1 || (echo "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://www.sphinx-doc.org/en/master/)" >&2; false)
 
 html: check_sphinx-build translations
 	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html

doc/conf.py

@@ -131,6 +131,7 @@ def inner(fn, *iargs, **ikwargs):  # pylint: disable=unused-argument
     'tornado.ioloop',
     'tornado.iostream',
     'tornado.netutil',
+    'tornado.queues',
     'tornado.simple_httpclient',
     'tornado.stack_context',
     'tornado.web',

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/configuration/master.rst

@@ -5050,6 +5050,33 @@ This can be used to control logging levels more specifically. See also
 :conf_log:`log_granular_levels`.
 
 
+.. conf_master:: log_rotate_max_bytes
+
+``log_rotate_max_bytes``
+------------------------
+
+Default:  ``0``
+
+The maximum number of bytes a single log file may contain before it is rotated.
+A value of 0 disables this feature. Currently only supported on Windows. On
+other platforms, use an external tool such as 'logrotate' to manage log files.
+:conf_log:`log_rotate_max_bytes`
+
+
+.. conf_master:: log_rotate_backup_count
+
+``log_rotate_backup_count``
+---------------------------
+
+Default:  ``0``
+
+The number of backup files to keep when rotating log files. Only used if
+:conf_master:`log_rotate_max_bytes` is greater than 0. Currently only supported
+on Windows. On other platforms, use an external tool such as 'logrotate' to
+manage log files.
+:conf_log:`log_rotate_backup_count`
+
+
 .. _node-groups:
 
 Node Groups

doc/ref/configuration/minion.rst

@@ -2940,6 +2940,34 @@ Default: ``{}``
 This can be used to control logging levels more specifically. See also
 :conf_log:`log_granular_levels`.
 
+
+.. conf_minion:: log_rotate_max_bytes
+
+``log_rotate_max_bytes``
+------------------------
+
+Default:  ``0``
+
+The maximum number of bytes a single log file may contain before it is rotated.
+A value of 0 disables this feature. Currently only supported on Windows. On
+other platforms, use an external tool such as 'logrotate' to manage log files.
+:conf_log:`log_rotate_max_bytes`
+
+
+.. conf_minion:: log_rotate_backup_count
+
+``log_rotate_backup_count``
+---------------------------
+
+Default:  ``0``
+
+The number of backup files to keep when rotating log files. Only used if
+:conf_minion:`log_rotate_max_bytes` is greater than 0. Currently only supported
+on Windows. On other platforms, use an external tool such as 'logrotate' to
+manage log files.
+:conf_log:`log_rotate_backup_count`
+
+
 .. conf_minion:: zmq_monitor
 
 ``zmq_monitor``

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

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