Merge branch 'develop' into cron_perjob

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

@@ -5101,6 +5101,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

@@ -3103,6 +3103,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/topics/beacons/index.rst

@@ -322,7 +322,7 @@ the minion. The ``beacon`` function therefore cannot block and should be as
 lightweight as possible. The ``beacon`` also must return a list of dicts, each
 dict in the list will be translated into an event on the master.
 
-Beacons may also choose to implement a ``__validate__`` function which
+Beacons may also choose to implement a ``validate`` function which
 takes the beacon configuration as an argument and ensures that it
 is valid prior to continuing. This function is called automatically
 by the Salt loader when a beacon is loaded.

doc/topics/development/contributing.rst

@@ -121,7 +121,8 @@ Fork a Repo Guide_>`_ and is well worth reading.
     .. note::
 
         If your change fixes a bug or implements a feature already filed in the
-        `issue tracker <GitHub issue tracker>`_, be sure to reference the issue
+        `issue tracker`_, be sure to
+	`reference the issue <https://help.github.com/en/articles/closing-issues-using-keywords>`_
         number in the commit message body.
 
     .. code-block:: bash
@@ -562,7 +563,7 @@ Script, see the Bootstrap Script's `Contributing Guidelines`_.
 
 .. _`saltstack/salt`: https://github.com/saltstack/salt
 .. _`GitHub Fork a Repo Guide`: https://help.github.com/articles/fork-a-repo
-.. _`GitHub issue tracker`: https://github.com/saltstack/salt/issues
+.. _`issue tracker`: https://github.com/saltstack/salt/issues
 .. _`Fork saltstack/salt`: https://github.com/saltstack/salt/fork
 .. _'Git resources`: https://help.github.com/articles/good-resources-for-learning-git-and-github/
 .. _`Closing issues via commit message`: https://help.github.com/articles/closing-issues-via-commit-messages

doc/topics/development/conventions/documentation.rst

@@ -13,7 +13,7 @@ broadly, most of the narrative documentation is contained within the
 :blob:`doc` subdirectory and most of the reference and API documentation is
 written inline with Salt's Python code and extracted using a Sphinx extension.
 
-.. _`Sphinx`: http://sphinx-doc.org/
+.. _`Sphinx`: https://www.sphinx-doc.org/en/master/
 
 
 .. _docs-style:
@@ -187,7 +187,7 @@ Link to :ref:`glossary entries <glossary>` using the `term role`_. A
 cross-reference should be added the first time a Salt-specific term is used in
 a document.
 
-.. _`term role`: http://sphinx-doc.org/markup/inline.html#role-term
+.. _`term role`: https://www.sphinx-doc.org/en/master/glossary.html#term-role
 
 .. code-block:: restructuredtext
 
@@ -206,7 +206,7 @@ occasionally useful to manually add items to the index.
 One method is to use the `index directive`_ above the document or section that
 should appear in the index.
 
-.. _`index directive`: http://sphinx-doc.org/markup/misc.html#directive-index
+.. _`index directive`: https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html?highlight=index%20directive#index-generating-markup
 
 .. code-block:: restructuredtext
 
@@ -217,7 +217,7 @@ Another method is to use the `index role`_ inline with the text that should
 appear in the index. The index entry is created and the target text is left
 otherwise intact.
 
-.. _`index role`: http://sphinx-doc.org/markup/misc.html#role-index
+.. _`index role`: http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#role-index
 
 .. code-block:: restructuredtext
 
@@ -252,7 +252,7 @@ to survive document renames or movement.
 
 Note, the ``:doc:`` role should *not* be used to link documents together.
 
-.. _`ref role`: http://sphinx-doc.org/markup/inline.html#role-ref
+.. _`ref role`: https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-ref
 
 
 .. _docs-ref-modules:

doc/topics/development/hacking.rst

@@ -283,7 +283,9 @@ Change to salt documentation directory, then:
   :strong:`text`.
 - The docs then are built within the :strong:`docs/_build/` folder. To update
   the docs after making changes, run ``make`` again.
-- The docs use `reStructuredText <http://sphinx-doc.org/rest.html>`_ for markup.
+- The docs use `reStructuredText
+  <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html>`_
+  for markup.
   See a live demo at http://rst.ninjs.org/.
 - The help information on each module or state is culled from the python code
   that runs for that piece. Find them in ``salt/modules/`` or ``salt/states/``.

doc/topics/proxyminion/index.rst

@@ -188,7 +188,7 @@ The key thing to remember is the left-most section of the diagram.  Salt's
 nature is to have a minion connect to a master, then the master may control
 the minion.  However, for proxy minions, the target device cannot run a minion.
 
-After the proxy minion is started and initiates its connection to the 'dumb'
+After the proxy minion is started and initiates its connection to the
 device, it connects back to the salt-master and for all intents and purposes
 looks like just another minion to the Salt master.
 
@@ -220,23 +220,23 @@ based on the diagram above:
 .. code-block:: yaml
 
     base:
-      dumbdevice1:
-        - dumbdevice1
-      dumbdevice2:
-        - dumbdevice2
-      dumbdevice3:
-        - dumbdevice3
-      dumbdevice4:
-        - dumbdevice4
-      dumbdevice5:
-        - dumbdevice5
-      dumbdevice6:
-        - dumbdevice6
-      dumbdevice7:
-        - dumbdevice7
-
-
-``/srv/pillar/dumbdevice1.sls``
+      net-device1:
+        - net-device1
+      net-device2:
+        - net-device2
+      net-device3:
+        - net-device3
+      i2c-device4:
+        - i2c-device4
+      i2c-device5:
+        - i2c-device5
+      433wireless-device6:
+        - 433wireless-device6
+      smsgate-device7:
+        - device7
+
+
+``/srv/pillar/net-device1.sls``
 
 .. code-block:: yaml
 
@@ -247,7 +247,7 @@ based on the diagram above:
       passwd: letmein
 
 
-``/srv/pillar/dumbdevice2.sls``
+``/srv/pillar/net-device2.sls``
 
 .. code-block:: yaml
 
@@ -258,7 +258,7 @@ based on the diagram above:
       passwd: letmein
 
 
-``/srv/pillar/dumbdevice3.sls``
+``/srv/pillar/net-device3.sls``
 
 .. code-block:: yaml
 
@@ -269,7 +269,7 @@ based on the diagram above:
       passwd: letmein
 
 
-``/srv/pillar/dumbdevice4.sls``
+``/srv/pillar/i2c-device4.sls``
 
 .. code-block:: yaml
 
@@ -278,7 +278,7 @@ based on the diagram above:
       i2c_address: 1
 
 
-``/srv/pillar/dumbdevice5.sls``
+``/srv/pillar/i2c-device5.sls``
 
 .. code-block:: yaml
 
@@ -287,15 +287,15 @@ based on the diagram above:
         i2c_address: 2
 
 
-``/srv/pillar/dumbdevice6.sls``
+``/srv/pillar/433wireless-device6.sls``
 
 .. code-block:: yaml
 
       proxy:
         proxytype: 433mhz_wireless
 
 
-``/srv/pillar/dumbdevice7.sls``
+``/srv/pillar/smsgate-device7.sls``
 
 .. code-block:: yaml
 
@@ -309,18 +309,18 @@ the type of device that the proxy-minion is managing.
 
 In the above example
 
-- dumbdevices 1, 2, and 3 are network switches that have a management
+- net-devices 1, 2, and 3 are network switches that have a management
   interface available at a particular IP address.
 
-- dumbdevices 4 and 5 are very low-level devices controlled over an i2c bus.
+- i2c-devices 4 and 5 are very low-level devices controlled over an i2c bus.
   In this case the devices are physically connected to machine
   'minioncontroller2', and are addressable on the i2c bus at their respective
   i2c addresses.
 
-- dumbdevice6 is a 433 MHz wireless transmitter, also physically connected to
+- 433wireless-device6 is a 433 MHz wireless transmitter, also physically connected to
   minioncontroller2
 
-- dumbdevice7 is an SMS gateway connected to machine minioncontroller3 via a
+- smsgate-device7 is an SMS gateway connected to machine minioncontroller3 via a
   serial port.
 
 Because of the way pillar works, each of the salt-proxy processes that fork off the