Merge branch 'develop' into pr/jinja_line_statements

.github/stale.yml

@@ -1,8 +1,8 @@
 # Probot Stale configuration file
 
 # Number of days of inactivity before an issue becomes stale
-# 1275 is approximately 3 years and 6 months
-daysUntilStale: 1275
+# 1175 is approximately 3 years and 2 months
+daysUntilStale: 1175
 
 # Number of days of inactivity before a stale issue is closed
 daysUntilClose: 7

conf/master

@@ -91,6 +91,10 @@
 # Set the default outputter used by the salt command. The default is "nested".
 #output: nested
 
+# To set a list of additional directories to search for salt outputters, set the
+# outputter_dirs option.
+#outputter_dirs: []
+
 # Set the default output file used by the salt command. Default is to output
 # to the CLI and not to a file. Functions the same way as the "--out-file"
 # CLI option, only sets this to a single file for all salt commands.
@@ -99,6 +103,9 @@
 # Return minions that timeout when running commands like test.ping
 #show_timeout: True
 
+# Tell the client to display the jid when a job is published.
+#show_jid: False
+
 # By default, output is colored. To disable colored output, set the color value
 # to False.
 #color: True
@@ -414,6 +421,20 @@
 # will cause minion to throw an exception and drop the message.
 # sign_pub_messages: False
 
+# Signature verification on messages published from minions
+# This requires that minions cryptographically sign the messages they
+# publish to the master.  If minions are not signing, then log this information
+# at loglevel 'INFO' and drop the message without acting on it.
+# require_minion_sign_messages: False
+
+# The below will drop messages when their signatures do not validate.
+# Note that when this option is False but `require_minion_sign_messages` is True
+# minions MUST sign their messages but the validity of their signatures
+# is ignored.
+# These two config options exist so a Salt infrastructure can be moved
+# to signing minion messages gradually.
+# drop_messages_signature_fail: False
+
 # Use TLS/SSL encrypted connection between master and minion.
 # Can be set to a dictionary containing keyword arguments corresponding to Python's
 # 'ssl.wrap_socket' method.
@@ -440,6 +461,27 @@
 # - /etc/salt/roster.d
 # - /opt/salt/some/more/rosters
 
+# The ssh password to log in with.
+#ssh_passwd: ''
+
+#The target system's ssh port number.
+#ssh_port: 22
+
+# Comma-separated list of ports to scan.
+#ssh_scan_ports: 22
+
+# Scanning socket timeout for salt-ssh.
+#ssh_scan_timeout: 0.01
+
+# Boolean to run command via sudo.
+#ssh_sudo: False
+
+# Number of seconds to wait for a response when establishing an SSH connection.
+#ssh_timeout: 60
+
+# The user to log in as.
+#ssh_user: root
+
 # The log file of the salt-ssh command:
 #ssh_log_file: /var/log/salt/ssh
 
@@ -453,6 +495,18 @@
 # authentication with minions
 #ssh_use_home_key: False
 
+# Set this to True to default salt-ssh to run with ``-o IdentitiesOnly=yes``.
+# This option is intended for situations where the ssh-agent offers many
+# different identities and allows ssh to ignore those identities and use the
+# only one specified in options.
+#ssh_identities_only: False
+
+# List-only nodegroups for salt-ssh. Each group must be formed as either a
+# comma-separated list, or a YAML list. This option is useful to group minions
+# into easy-to-target groups when using salt-ssh. These groups can then be
+# targeted with the normal -N argument to salt-ssh.
+#ssh_list_nodegroups: {}
+
 #####    Master Module Management    #####
 ##########################################
 # Manage how master side modules are loaded.
@@ -535,6 +589,11 @@
 # If set to 'changes', the output will be full unless the state didn't change.
 #state_output: full
 
+# The state_output_diff setting changes whether or not the output from
+# successful states is returned. Useful when even the terse output of these
+# states is cluttering the logs. Set it to True to ignore them.
+#state_output_diff: False
+
 # Automatically aggregate all states that have support for mod_aggregate by
 # setting to 'True'. Or pass a list of state module names to automatically
 # aggregate just those types.
@@ -575,6 +634,10 @@
 #    - /srv/salt
 #
 
+# The master_roots setting configures a master-only copy of the file_roots dictionary,
+# used by the state compiler.
+#master_roots: /srv/salt-master
+
 # When using multiple environments, each with their own top file, the
 # default behaviour is an unordered merge. To prevent top files from
 # being merged together and instead to only use the top file from the

conf/minion

@@ -151,7 +151,11 @@
 # Set the default outputter used by the salt-call command. The default is
 # "nested".
 #output: nested
-#
+
+# To set a list of additional directories to search for salt outputters, set the
+# outputter_dirs option.
+#outputter_dirs: []
+
 # By default output is colored. To disable colored output, set the color value
 # to False.
 #color: True
@@ -231,7 +235,7 @@
 # cause sub minion process to restart.
 #auth_safemode: False
 
-# Ping Master to ensure connection is alive (minutes).
+# Ping Master to ensure connection is alive (seconds).
 #ping_interval: 0
 
 # To auto recover minions if master changes IP address (DDNS)
@@ -369,6 +373,9 @@
 #    interface: eth0
 #    cidr: '10.0.0.0/8'
 
+# The number of seconds a mine update runs.
+#mine_interval: 60
+
 # Windows platforms lack posix IPC and must rely on slower TCP based inter-
 # process communications. Set ipc_mode to 'tcp' on such systems
 #ipc_mode: ipc

conf/proxy

@@ -28,27 +28,27 @@
 # dictionary.  Otherwise it is assumed that the module calls the grains
 # function in a custom way and returns the data elsewhere
 #
-# Default to False for 2016.3 and 2016.11. Switch to True for Nitrogen.
+# Default to False for 2016.3 and 2016.11. Switch to True for 2017.7.0.
 # proxy_merge_grains_in_module: True
 
 # If a proxymodule has a function called 'alive' returning a boolean
 # flag reflecting the state of the connection with the remove device,
 # when this option is set as True, a scheduled job on the proxy will
 # try restarting the connection. The polling frequency depends on the
-# next option, 'proxy_keep_alive_interval'. Added in Nitrogen.
+# next option, 'proxy_keep_alive_interval'. Added in 2017.7.0.
 # proxy_keep_alive: True
 
 # The polling interval (in minutes) to check if the underlying connection
 # with the remote device is still alive. This option requires
 # 'proxy_keep_alive' to be configured as True and the proxymodule to
-# implement the 'alive' function. Added in Nitrogen.
+# implement the 'alive' function. Added in 2017.7.0.
 # proxy_keep_alive_interval: 1
 
 # By default, any proxy opens the connection with the remote device when
 # initialized. Some proxymodules allow through this option to open/close
 # the session per command. This requires the proxymodule to have this
 # capability. Please consult the documentation to see if the proxy type
-# used can be that flexible. Added in Nitrogen.
+# used can be that flexible. Added in 2017.7.0.
 # proxy_always_alive: True
 
 # If multiple masters are specified in the 'master' setting, the default behavior

doc/_ext/saltdomain.py

@@ -309,3 +309,5 @@ def setup(app):
             indextemplate="pair: %s; conf/proxy")
     app.add_crossref_type(directivename="conf_log", rolename="conf_log",
             indextemplate="pair: %s; conf/logging")
+    app.add_crossref_type(directivename="jinja_ref", rolename="jinja_ref",
+            indextemplate="pair: %s; jinja filters")

doc/_themes/saltstack2/layout.html

@@ -255,8 +255,8 @@
 
                             <div class="col-sm-6">
 
-                                 <a href="https://saltstack.com/support" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/footer-support.png', 1) }}"/></a>
                                  <a href="https://saltstack.com/saltstack-enterprise/" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/enterprise_ad.jpg', 1) }}"/></a>
+                                 <a href="http://saltconf.com" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/DOCBANNER.jpg', 1) }}"/></a>
 
 
                             </div>

doc/conf.py

@@ -72,6 +72,7 @@ MOCK_MODULES = [
     'Crypto.Signature',
     'Crypto.Signature.PKCS1_v1_5',
     'M2Crypto',
+    'msgpack',
     'yaml',
     'yaml.constructor',
     'yaml.nodes',
@@ -244,7 +245,7 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
 project = 'Salt'
 
 version = salt.version.__version__
-latest_release = '2016.11.5'  # latest release
+latest_release = '2016.11.6'  # latest release
 previous_release = '2016.3.6'  # latest release from previous branch
 previous_release_dir = '2016.3'  # path on web server for previous branch
 next_release = ''  # next release

doc/faq.rst

@@ -190,6 +190,8 @@ PATH using a :mod:`file.symlink <salt.states.file.symlink>` state.
       file.symlink:
         - target: /usr/local/bin/foo
 
+.. _which-version:
+
 Can I run different versions of Salt on my Master and Minion?
 -------------------------------------------------------------
 

doc/ref/cli/salt-cp.rst

@@ -33,7 +33,7 @@ specified target expression.
     minions. However, this requires the file to be located within one of the
     fileserver directories.
 
-.. versionchanged:: 2016.3.7,2016.11.6,Nitrogen
+.. versionchanged:: 2016.3.7,2016.11.6,2017.7.0
     Compression support added, disable with ``-n``. Also, if the destination
     path ends in a path separator (i.e. ``/``,  or ``\`` on Windows, the
     desitination will be assumed to be a directory. Finally, recursion is now
@@ -60,7 +60,7 @@ Options
 
     Disable gzip compression.
 
-    .. versionadded:: 2016.3.7,2016.11.6,Nitrogen
+    .. versionadded:: 2016.3.7,2016.11.6,2017.7.0
 
 See also
 ========

doc/ref/configuration/master.rst

@@ -17,6 +17,9 @@ The configuration file for the salt-master is located at
 configuration file is located at :file:`/usr/local/etc/salt`.  The available
 options are as follows:
 
+
+.. _primary-master-configuration:
+
 Primary Master Configuration
 ============================
 
@@ -245,10 +248,13 @@ each of Salt's module types such as ``runners``, ``output``, ``wheel``,
 
     extension_modules: /root/salt_extmods
 
+.. conf_master:: extmod_whitelist
+.. conf_master:: extmod_blacklist
+
 ``extmod_whitelist/extmod_blacklist``
 -------------------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 By using this dictionary, the modules that are synced to the master's extmod cache using `saltutil.sync_*` can be
 limited.  If nothing is set to a specific type, then all modules are accepted.  To block all modules of a specific type,
@@ -390,6 +396,19 @@ Default: ``nested``
 
 Set the default outputter used by the salt command.
 
+.. conf_master:: outputter_dirs
+
+``outputter_dirs``
+------------------
+
+Default: ``[]``
+
+A list of additional directories to search for salt outputters in.
+
+.. code-block:: yaml
+
+    outputter_dirs: []
+
 .. conf_master:: output_file
 
 ``output_file``
@@ -405,6 +424,32 @@ CLI option, only sets this to a single file for all salt commands.
 
     output_file: /path/output/file
 
+.. conf_master:: show_timeout
+
+``show_timeout``
+----------------
+
+Default: ``True``
+
+Tell the client to show minions that have timed out.
+
+.. code-block:: yaml
+
+    show_timeout: True
+
+.. conf_master:: show_jid
+
+``show_jid``
+------------
+
+Default: ``False``
+
+Tell the client to display the jid when a job is published.
+
+.. code-block:: yaml
+
+    show_jid: False
+
 .. conf_master:: color
 
 ``color``
@@ -816,6 +861,32 @@ that connect to a master via localhost.
 
     presence_events: False
 
+.. conf_master:: ping_on_rotate
+
+``ping_on_rotate``
+------------------
+
+Default: ``False``
+
+By default, the master AES key rotates every 24 hours. The next command
+following a key rotation will trigger a key refresh from the minion which may
+result in minions which do not respond to the first command after a key refresh.
+
+To tell the master to ping all minions immediately after an AES key refresh,
+set ``ping_on_rotate`` to ``True``. This should mitigate the issue where a
+minion does not appear to initially respond after a key is rotated.
+
+Note that ping_on_rotate may cause high load on the master immediately after
+the key rotation event as minions reconnect. Consider this carefully if this
+salt master is managing a large number of minions.
+
+If disabled, it is recommended to handle this event by listening for the
+``aes_key_rotate`` event with the ``key`` tag and acting appropriately.
+
+.. code-block:: yaml
+
+    ping_on_rotate: False
+
 .. conf_master:: transport
 
 ``transport``
@@ -834,6 +905,8 @@ what you are doing! Transports are explained in :ref:`Salt Transports
 
     transport: zeromq
 
+.. conf_master:: transport_opts
+
 ``transport_opts``
 ------------------
 
@@ -852,6 +925,30 @@ what you are doing! Transports are explained in :ref:`Salt Transports
         ret_port: 4606
       zeromq: []
 
+.. conf_master:: sock_pool_size
+
+``sock_pool_size``
+------------------
+
+Default: 1
+
+To avoid blocking waiting while writing a data to a socket, we support
+socket pool for Salt applications. For example, a job with a large number
+of target host list can cause long period blocking waiting. The option
+is used by ZMQ and TCP transports, and the other transport methods don't
+need the socket pool by definition. Most of Salt tools, including CLI,
+are enough to use a single bucket of socket pool. On the other hands,
+it is highly recommended to set the size of socket pool larger than 1
+for other Salt applications, especially Salt API, which must write data
+to socket concurrently.
+
+.. code-block:: yaml
+
+    sock_pool_size: 15
+
+
+.. _salt-ssh-configuration:
+
 Salt-SSH Configuration
 ======================
 
@@ -868,6 +965,97 @@ Pass in an alternative location for the salt-ssh roster file.
 
     roster_file: /root/roster
 
+.. conf_master:: ssh_passwd
+
+``ssh_passwd``
+--------------
+
+Default: ``''``
+
+The ssh password to log in with.
+
+.. code-block:: yaml
+
+    ssh_passwd: ''
+
+.. conf_master:: ssh_port
+
+``ssh_port``
+------------
+
+Default: ``22``
+
+The target system's ssh port number.
+
+.. code-block:: yaml
+
+    ssh_port: 22
+
+.. conf_master:: ssh_scan_ports
+
+``ssh_scan_ports``
+------------------
+
+Default: ``22``
+
+Comma-separated list of ports to scan.
+
+.. code-block:: yaml
+
+    ssh_scan_ports: 22
+
+.. conf_master:: ssh_scan_timeout
+
+``ssh_scan_timeout``
+--------------------
+
+Default: ``0.01``
+
+Scanning socket timeout for salt-ssh.
+
+.. code-block:: yaml
+
+    ssh_scan_timeout: 0.01
+
+.. conf_master:: ssh_sudo
+
+``ssh_sudo``
+------------
+
+Default: ``False``
+
+Boolean to run command via sudo.
+
+.. code-block:: yaml
+
+    ssh_sudo: False
+
+.. conf_master:: ssh_timeout
+
+``ssh_timeout``
+---------------
+
+Default: ``60``
+
+Number of seconds to wait for a response when establishing an SSH connection.
+
+.. code-block:: yaml
+
+    ssh_timeout: 60
+
+.. conf_master:: ssh_user
+
+``ssh_user``
+------------
+
+Default: ``root``
+
+The user to log in as.
+
+.. code-block:: yaml
+
+    ssh_user: root
+
 .. conf_master:: ssh_log_file
 
 ``ssh_log_file``
@@ -899,6 +1087,8 @@ overridden on a per-minion basis in the roster (``minion_opts``)
     ssh_minion_opts:
       gpg_keydir: /root/gpg
 
+.. conf_master:: ssh_use_home_key
+
 ``ssh_use_home_key``
 --------------------
 
@@ -911,6 +1101,41 @@ authentication with minions
 
     ssh_use_home_key: False
 
+.. conf_master:: ssh_identities_only
+
+``ssh_identities_only``
+-----------------------
+
+Default: ``False``
+
+Set this to ``True`` to default salt-ssh to run with ``-o IdentitiesOnly=yes``. This
+option is intended for situations where the ssh-agent offers many different identities
+and allows ssh to ignore those identities and use the only one specified in options.
+
+.. code-block:: yaml
+
+    ssh_identities_only: False
+
+.. conf_master:: ssh_list_nodegroups
+
+``ssh_list_nodegroups``
+-----------------------
+
+Default: ``{}``
+
+List-only nodegroups for salt-ssh. Each group must be formed as either a comma-separated
+list, or a YAML list. This option is useful to group minions into easy-to-target groups
+when using salt-ssh. These groups can then be targeted with the normal -N argument to
+salt-ssh.
+
+.. code-block:: yaml
+
+    ssh_list_nodegroups:
+      groupA: minion1,minion2
+      groupB: minion1,minion3
+
+.. conf_master:: thin_extra_mods
+
 ``thin_extra_mods``
 -------------------
 
@@ -929,6 +1154,8 @@ Default: None
 Identical as `thin_extra_mods`, only applied to the Salt Minimal.
 
 
+.. _master-security-settings:
+
 Master Security Settings
 ========================
 
@@ -1122,7 +1349,7 @@ from the eauth driver each time.
 .. conf_master:: eauth_acl_module
 
 ``eauth_acl_module``
----------------------
+--------------------
 
 Default: ``''``
 
@@ -1219,7 +1446,6 @@ signature. The :conf_master:`master_pubkey_signature` must also be set for this.
 
     master_use_pubkey_signature: True
 
-
 .. conf_master:: rotate_aes_key
 
 ``rotate_aes_key``
@@ -1236,7 +1462,6 @@ Do not disable this unless it is absolutely clear what this does.
 
     rotate_aes_key: True
 
-
 .. conf_master:: ssl
 
 ``ssl``
@@ -1265,7 +1490,7 @@ constant names without ssl module prefix: ``CERT_REQUIRED`` or ``PROTOCOL_SSLv23
 .. conf_master:: allow_minion_key_revoke
 
 ``allow_minion_key_revoke``
-------------------
+---------------------------
 
 Default: ``True``
 
@@ -1278,6 +1503,9 @@ the master will drop the request and the minion's key will remain accepted.
 
     rotate_aes_key: True
 
+
+.. _master-module-management:
+
 Master Module Management
 ========================
 
@@ -1310,6 +1538,8 @@ the Salt master.
     cython_enable: False
 
 
+.. _master-state-system-settings:
+
 Master State System Settings
 ============================
 
@@ -1638,6 +1868,21 @@ If set to 'changes', the output will be full unless the state didn't change.
 
     state_output: full
 
+.. conf_master:: state_output_diff
+
+``state_output_diff``
+---------------------
+
+Default: ``False``
+
+The state_output_diff setting changes whether or not the output from
+successful states is returned. Useful when even the terse output of these
+states is cluttering the logs. Set it to True to ignore them.
+
+.. code-block:: yaml
+
+    state_output_diff: False
+
 .. conf_master:: state_aggregate
 
 ``state_aggregate``
@@ -1698,6 +1943,9 @@ If set to ``True``, runner jobs will be saved to job cache (defined by
 
     runner_returns: True
 
+
+.. _master-file-server-settings:
+
 Master File Server Settings
 ===========================
 
@@ -1814,9 +2062,9 @@ on a large number of minions.
 .. conf_master:: fileserver_verify_config
 
 ``fileserver_verify_config``
-------------------------------
+----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``True``
 
@@ -1947,6 +2195,19 @@ Example:
     For masterless Salt, this parameter must be specified in the minion config
     file.
 
+.. conf_master:: master_roots
+
+``master_roots``
+----------------
+
+Default: ``/srv/salt-master``
+
+A master-only copy of the file_roots dictionary, used by the state compiler.
+
+.. code-block:: yaml
+
+    master_roots: /srv/salt-master
+
 git: Git Remote File Server Backend
 -----------------------------------
 
@@ -2114,6 +2375,60 @@ gitfs remotes.
       - dev:
         - ref: develop
 
+.. conf_master:: gitfs_disable_saltenv_mapping
+
+``gitfs_disable_saltenv_mapping``
+*********************************
+
+.. versionadded:: Oxygen
+
+Default: ``False``
+
+When set to ``True``, all saltenv mapping logic is disregarded (aside from
+which branch/tag is mapped to the ``base`` saltenv). To use any other
+environments, they must then be defined using :ref:`per-saltenv configuration
+parameters <gitfs-per-saltenv-config>`.
+
+.. code-block:: yaml
+
+    gitfs_disable_saltenv_mapping: True
+
+.. note::
+    This is is a global configuration option, see :ref:`here
+    <gitfs-per-remote-config>` for examples of configuring it for individual
+    repositories.
+
+.. conf_master:: gitfs_ref_types
+
+``gitfs_ref_types``
+*******************
+
+.. versionadded:: Oxygen
+
+Default: ``['branch', 'tag', 'sha']``
+
+This option defines what types of refs are mapped to fileserver environments
+(i.e. saltenvs). It also sets the order of preference when there are
+ambiguously-named refs (i.e. when a branch and tag both have the same name).
+The below example disables mapping of both tags and SHAs, so that only branches
+are mapped as saltenvs:
+
+.. code-block:: yaml
+
+    gitfs_ref_types:
+      - branch
+
+.. note::
+    This is is a global configuration option, see :ref:`here
+    <gitfs-per-remote-config>` for examples of configuring it for individual
+    repositories.
+
+.. note::
+    ``sha`` is special in that it will not show up when listing saltenvs (e.g.
+    with the :py:func:`fileserver.envs <salt.runners.fileserver.envs>` runner),
+    but works within states and with :py:func:`cp.cache_file
+    <salt.modules.cp.cache_file>` to retrieve a file from a specific git SHA.
+
 .. conf_master:: gitfs_saltenv_whitelist
 
 ``gitfs_saltenv_whitelist``
@@ -2331,7 +2646,7 @@ authenticate is protected by a passphrase.
 ``gitfs_refspecs``
 ~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
 
@@ -2885,7 +3200,7 @@ configuration is the same as :conf_master:`file_roots`:
 ``on_demand_ext_pillar``
 ------------------------
 
-.. versionadded:: 2016.3.6,2016.11.3,Nitrogen
+.. versionadded:: 2016.3.6,2016.11.3,2017.7.0
 
 Default: ``['libvirt', 'virtkey']``
 
@@ -2913,7 +3228,7 @@ The external pillars permitted to be used on-demand using :py:func:`pillar.ext
 ``decrypt_pillar``
 ------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``[]``
 
@@ -2935,7 +3250,7 @@ specified by :conf_master:`decrypt_pillar_default` will be used.
 ``decrypt_pillar_delimiter``
 ----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``:``
 
@@ -2954,7 +3269,7 @@ The delimiter used to distinguish nested data structures in the
 ``decrypt_pillar_default``
 --------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``gpg``
 
@@ -2970,7 +3285,7 @@ pillar key in :conf_master:`decrypt_pillar`.
 ``decrypt_pillar_renderers``
 ----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``['gpg']``
 
@@ -3294,7 +3609,7 @@ they were created by a different master.
 ``git_pillar_includes``
 ***********************
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``True``
 
@@ -3425,7 +3740,7 @@ authenticate is protected by a passphrase.
 ``git_pillar_refspecs``
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
 
@@ -3448,7 +3763,7 @@ configured both globally and for individual remotes.
 ``git_pillar_verify_config``
 ----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``True``
 
@@ -3671,6 +3986,9 @@ can be utilized:
 
     pillar_cache_backend: disk
 
+
+.. _syndic-server-settings:
+
 Syndic Server Settings
 ======================
 
@@ -3806,9 +4124,9 @@ check in with their lists of expected minions before giving up.
 .. conf_master:: syndic_forward_all_events
 
 ``syndic_forward_all_events``
--------------------
+-----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``False``
 
@@ -3820,6 +4138,8 @@ send events to all connected masters.
     syndic_forward_all_events: False
 
 
+.. _peer-publish-settings:
+
 Peer Publish Settings
 =====================
 
@@ -3934,7 +4254,6 @@ The level of messages to send to the console. See also :conf_log:`log_level`.
 
     log_level: warning
 
-
 .. conf_master:: log_level_logfile
 
 ``log_level_logfile``
@@ -3950,7 +4269,6 @@ it will inherit the level set by :conf_log:`log_level` option.
 
     log_level_logfile: warning
 
-
 .. conf_master:: log_datefmt
 
 ``log_datefmt``
@@ -3965,7 +4283,6 @@ The date and time format used in console log messages. See also
 
     log_datefmt: '%H:%M:%S'
 
-
 .. conf_master:: log_datefmt_logfile
 
 ``log_datefmt_logfile``
@@ -3980,7 +4297,6 @@ The date and time format used in log file messages. See also
 
     log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
 
-
 .. conf_master:: log_fmt_console
 
 ``log_fmt_console``
@@ -4013,7 +4329,6 @@ The format of the console logging messages. See also
     log_fmt_console: '%(colorlevel)s %(colormsg)s'
     log_fmt_console: '[%(levelname)-8s] %(message)s'
 
-
 .. conf_master:: log_fmt_logfile
 
 ``log_fmt_logfile``
@@ -4028,7 +4343,6 @@ The format of the log file logging messages. See also
 
     log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'
 
-
 .. conf_master:: log_granular_levels
 
 ``log_granular_levels``
@@ -4039,6 +4353,9 @@ Default: ``{}``
 This can be used to control logging levels more specifically. See also
 :conf_log:`log_granular_levels`.
 
+
+.. _node-groups:
+
 Node Groups
 ===========
 
@@ -4056,13 +4373,15 @@ A group consists of a group name and a compound target.
       group2: 'G@os:Debian and foo.domain.com'
       group3: 'G@os:Debian and N@group1'
       group4:
-	- 'G@foo:bar'
-	- 'or'
-	- 'G@foo:baz'
+        - 'G@foo:bar'
+        - 'or'
+        - 'G@foo:baz'
 
 More information on using nodegroups can be found :ref:`here <targeting-nodegroups>`.
 
 
+.. _range-cluster-settings:
+
 Range Cluster Settings
 ======================
 
@@ -4078,9 +4397,11 @@ https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec
 
 .. code-block:: yaml
 
-  range_server: range:80
+    range_server: range:80
 
 
+.. _include-configuration:
+
 Include Configuration
 =====================
 
@@ -4102,7 +4423,6 @@ file.
     files are prefixed with an underscore. A common example of this is the
     ``_schedule.conf`` file.
 
-
 .. conf_master:: include
 
 ``include``
@@ -4132,6 +4452,7 @@ option then the master will log a warning message.
       - master.d/*
       - /etc/roles/webserver
 
+
 .. _winrepo-master-config-opts:
 
 Windows Software Repo Settings
@@ -4435,7 +4756,7 @@ authenticate is protected by a passphrase.
 ``winrepo_refspecs``
 ~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
 
@@ -4452,3 +4773,82 @@ configured both globally and for individual remotes.
       - '+refs/tags/*:refs/tags/*'
       - '+refs/pull/*/head:refs/remotes/origin/pr/*'
       - '+refs/pull/*/merge:refs/remotes/origin/merge/*'
+
+
+.. _configure-master-on-windows:
+
+Configure Master on Windows
+===========================
+
+The master on Windows requires no additional configuration. You can modify the
+master configuration by creating/editing the master config file located at
+``c:\salt\conf\master``. The same configuration options available on Linux are
+available in Windows, as long as they apply. For example, SSH options wouldn't
+apply in Windows. The main differences are the file paths. If you are familiar
+with common salt paths, the following table may be useful:
+
+=============  =========  =================
+linux Paths               Windows Paths
+=============  =========  =================
+``/etc/salt``  ``<--->``  ``c:\salt\conf``
+``/``          ``<--->``  ``c:\salt``
+=============  =========  =================
+
+So, for example, the master config file in Linux is ``/etc/salt/master``. In
+Windows the master config file is ``c:\salt\conf\master``. The Linux path
+``/etc/salt`` becomes ``c:\salt\conf`` in Windows.
+
+Common File Locations
+---------------------
+
+======================================  =============================================
+Linux Paths                             Windows Paths
+======================================  =============================================
+``conf_file: /etc/salt/master``         ``conf_file: c:\salt\conf\master``
+``log_file: /var/log/salt/master``      ``log_file: c:\salt\var\log\salt\master``
+``pidfile: /var/run/salt-master.pid``   ``pidfile: c:\salt\var\run\salt-master.pid``
+======================================  =============================================
+
+Common Directories
+------------------
+
+======================================================  ============================================
+Linux Paths                                             Windows Paths
+======================================================  ============================================
+``cachedir: /var/cache/salt/master``                    ``cachedir: c:\salt\var\cache\salt\master``
+``extension_modules: /var/cache/salt/master/extmods``   ``c:\salt\var\cache\salt\master\extmods``
+``pki_dir: /etc/salt/pki/master``                       ``pki_dir: c:\salt\conf\pki\master``
+``root_dir: /``                                         ``root_dir: c:\salt``
+``sock_dir: /var/run/salt/master``                      ``sock_dir: c:\salt\var\run\salt\master``
+======================================================  ============================================
+
+Roots
+-----
+
+**file_roots**
+
+==================  =========================
+Linux Paths         Windows Paths
+==================  =========================
+``/srv/salt``       ``c:\salt\srv\salt``
+``/srv/spm/salt``   ``c:\salt\srv\spm\salt``
+==================  =========================
+
+**pillar_roots**
+
+====================  ===========================
+Linux Paths           Windows Paths
+====================  ===========================
+``/srv/pillar``       ``c:\salt\srv\pillar``
+``/srv/spm/pillar``   ``c:\salt\srv\spm\pillar``
+====================  ===========================
+
+Win Repo Settings
+-----------------
+
+==========================================  =================================================
+Linux Paths                                 Windows Paths
+==========================================  =================================================
+``winrepo_dir: /srv/salt/win/repo``         ``winrepo_dir: c:\salt\srv\salt\win\repo``
+``winrepo_dir_ng: /srv/salt/win/repo-ng``   ``winrepo_dir_ng: c:\salt\srv\salt\win\repo-ng``
+==========================================  =================================================

doc/ref/configuration/minion.rst

@@ -133,6 +133,24 @@ name) is set in the :conf_minion:`master` configuration setting.
 
     master_uri_format: ip_only
 
+.. conf_minion:: master_tops_first
+
+``master_tops_first``
+---------------------
+
+.. versionadded:: Oxygen
+
+Default: ``False``
+
+SLS targets defined using the :ref:`Master Tops <master-tops-system>` system
+are normally executed *after* any matches defined in the :ref:`Top File
+<states-top>`. Set this option to ``True`` to have the minion execute the
+:ref:`Master Tops <master-tops-system>` states first.
+
+.. code-block:: yaml
+
+    master_tops_first: True
+
 .. conf_minion:: master_type
 
 ``master_type``
@@ -319,7 +337,7 @@ The user to run the Salt processes
 .. conf_minion:: sudo_user
 
 ``sudo_user``
---------------
+-------------
 
 Default: ``''``
 
@@ -610,6 +628,26 @@ With ``grains_deep_merge``, the result will be:
       k1: v1
       k2: v2
 
+.. conf_minion:: grains_refresh_every
+
+``grains_refresh_every``
+------------------------
+
+Default: ``0``
+
+The ``grains_refresh_every`` setting allows for a minion to periodically
+check its grains to see if they have changed and, if so, to inform the master
+of the new grains. This operation is moderately expensive, therefore care
+should be taken not to set this value too low.
+
+Note: This value is expressed in minutes.
+
+A value of 10 minutes is a reasonable default.
+
+.. code-block:: yaml
+
+    grains_refresh_every: 0
+
 .. conf_minion:: mine_enabled
 
 ``mine_enabled``
@@ -643,7 +681,7 @@ return for the job cache.
     mine_return_job: False
 
 ``mine_functions``
--------------------
+------------------
 
 Default: Empty
 
@@ -661,6 +699,18 @@ Note these can be defined in the pillar for a minion as well.
         interface: eth0
         cidr: '10.0.0.0/8'
 
+.. conf_minion:: mine_interval
+
+``mine_interval``
+-----------------
+
+Default: ``60``
+
+The number of seconds a mine update runs.
+
+.. code-block:: yaml
+
+    mine_interval: 60
 
 .. conf_minion:: sock_dir
 
@@ -675,6 +725,19 @@ The directory where Unix sockets will be kept.
 
     sock_dir: /var/run/salt/minion
 
+.. conf_minion:: outputter_dirs
+
+``outputter_dirs``
+------------------
+
+Default: ``[]``
+
+A list of additional directories to search for salt outputters in.
+
+.. code-block:: yaml
+
+    outputter_dirs: []
+
 .. conf_minion:: backup_mode
 
 ``backup_mode``
@@ -817,6 +880,20 @@ restart.
 
     auth_safemode: False
 
+.. conf_minion:: ping_interval
+
+``ping_interval``
+-----------------
+
+Default: ``0``
+
+Instructs the minion to ping its master(s) every n number of seconds. Used
+primarily as a mitigation technique against minion disconnects.
+
+.. code-block:: yaml
+
+    ping_interval: 0
+
 .. conf_minion:: recon_default
 
 ``random_startup_delay``
@@ -1275,10 +1352,13 @@ below.
     providers:
       service: systemd
 
-``extmod_whitelist/extmod_blacklist``
---------------------
+.. conf_minion:: extmod_whitelist
+.. conf_minion:: extmod_blacklist
 
-.. versionadded:: Nitrogen
+``extmod_whitelist/extmod_blacklist``
+-------------------------------------
+
+.. versionadded:: 2017.7.0
 
 By using this dictionary, the modules that are synced to the minion's extmod cache using `saltutil.sync_*` can be
 limited.  If nothing is set to a specific type, then all modules are accepted.  To block all modules of a specific type,
@@ -1504,6 +1584,22 @@ the output will be shortened to a single line.
 
     state_output: full
 
+
+.. conf_minion:: state_output_diff
+
+``state_output_diff``
+---------------------
+
+Default: ``False``
+
+The state_output_diff setting changes whether or not the output from
+successful states is returned. Useful when even the terse output of these
+states is cluttering the logs. Set it to True to ignore them.
+
+.. code-block:: yaml
+
+    state_output_diff: False
+
 .. conf_minion:: autoload_dynamic_modules
 
 ``autoload_dynamic_modules``
@@ -1747,7 +1843,7 @@ the pillar environments.
 ``on_demand_ext_pillar``
 ------------------------
 
-.. versionadded:: 2016.3.6,2016.11.3,Nitrogen
+.. versionadded:: 2016.3.6,2016.11.3,2017.7.0
 
 Default: ``['libvirt', 'virtkey']``
 
@@ -1776,7 +1872,7 @@ external pillars are permitted to be used on-demand using :py:func:`pillar.ext
 ``decrypt_pillar``
 ------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``[]``
 
@@ -1798,7 +1894,7 @@ specified by :conf_minion:`decrypt_pillar_default` will be used.
 ``decrypt_pillar_delimiter``
 ----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``:``
 
@@ -1817,7 +1913,7 @@ The delimiter used to distinguish nested data structures in the
 ``decrypt_pillar_default``
 --------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``gpg``
 
@@ -1833,7 +1929,7 @@ pillar key in :conf_minion:`decrypt_pillar`.
 ``decrypt_pillar_renderers``
 ----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``['gpg']``
 
@@ -1864,7 +1960,7 @@ the environment setting, but for pillar instead of states.
 ``pillarenv_from_saltenv``
 --------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``False``
 

doc/ref/configuration/proxy.rst

@@ -27,7 +27,7 @@ Proxy-specific Configuration Options
 .. conf_proxy:: add_proxymodule_to_opts
 
 ``add_proxymodule_to_opts``
---------------------------
+---------------------------
 
 .. versionadded:: 2015.8.2
 
@@ -49,7 +49,7 @@ Add the proxymodule LazyLoader object to opts.
 
 .. versionadded:: 2016.3.0
 
-.. versionchanged:: Nitrogen
+.. versionchanged:: 2017.7.0
 
 Default: ``True``
 
@@ -68,7 +68,7 @@ function in a custom way and returns the data elsewhere.
 ``proxy_keep_alive``
 --------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``True``
 
@@ -86,7 +86,7 @@ otherwise the connection is considered alive.
 ``proxy_keep_alive_interval``
 -----------------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``1``
 
@@ -104,7 +104,7 @@ The frequency of keepalive checks, in minutes. It requires the
 ``proxy_always_alive``
 ----------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Default: ``True``
 

doc/ref/modules/all/index.rst

@@ -9,6 +9,7 @@ execution modules
     .. toctree::
 
         salt.modules.group
+        salt.modules.kernelpkg
         salt.modules.pkg
         salt.modules.user
 
@@ -116,6 +117,8 @@ execution modules
     drac
     dracr
     drbd
+    dummyproxy_package
+    dummyproxy_service
     ebuild
     eix
     elasticsearch
@@ -188,6 +191,8 @@ execution modules
     k8s
     kapacitor
     kerberos
+    kernelpkg_linux_apt
+    kernelpkg_linux_yum
     key
     keyboard
     keystone
@@ -293,6 +298,7 @@ execution modules
     opkg
     oracle
     osquery
+    out
     pacman
     pagerduty
     pagerduty_util

doc/ref/modules/all/salt.modules.dummyproxy_package.rst

@@ -0,0 +1,6 @@
+salt.modules.dummyproxy_package module
+======================================
+
+.. automodule:: salt.modules.dummyproxy_package
+    :members:
+    :undoc-members:

doc/ref/modules/all/salt.modules.dummyproxy_service.rst

@@ -0,0 +1,6 @@
+salt.modules.dummyproxy_service module
+======================================
+
+.. automodule:: salt.modules.dummyproxy_service
+    :members:
+    :undoc-members:

doc/ref/modules/all/salt.modules.kernelpkg.rst

@@ -0,0 +1,19 @@
+.. _virtual-kernelpkg:
+
+======================
+salt.modules.kernelpkg
+======================
+
+.. py:module:: salt.modules.kernelpkg
+    :synopsis: A virtual module for managing kernel packages
+
+``kernelpkg`` is a virtual module that is fulfilled by one of the following modules:
+
+============================================ ========================================
+Execution Module                             Used for
+============================================ ========================================
+:py:mod:`~salt.modules.kernelpkg_linux_apt`  Debian/Ubuntu-based distros which use
+                                             ``apt-get(8)`` for package management
+:py:mod:`~salt.modules.kernelpkg_linux_yum`  RedHat-based distros and derivatives
+                                             using ``yum(8)`` or ``dnf(8)``
+============================================ ========================================

doc/ref/modules/all/salt.modules.kernelpkg_linux_apt.rst

@@ -0,0 +1,6 @@
+================================
+salt.modules.kernelpkg_linux_apt
+================================
+
+.. automodule:: salt.modules.kernelpkg_linux_apt
+    :members:

doc/ref/modules/all/salt.modules.kernelpkg_linux_yum.rst

@@ -0,0 +1,6 @@
+================================
+salt.modules.kernelpkg_linux_yum
+================================
+
+.. automodule:: salt.modules.kernelpkg_linux_yum
+    :members:

doc/ref/modules/all/salt.modules.out.rst

@@ -0,0 +1,5 @@
+salt.modules.out module
+=======================
+
+.. automodule:: salt.modules.out
+    :members:

doc/ref/modules/index.rst

@@ -13,7 +13,7 @@ Writing Salt execution modules is straightforward.
 
 A Salt execution module is a Python or `Cython`_ module placed in a directory
 called ``_modules/`` at the root of the Salt fileserver. When using the default
-fileserver backend (i.e. :py:mod:`roots <salt.fileserver.roots`), unless
+fileserver backend (i.e. :py:mod:`roots <salt.fileserver.roots>`), unless
 environments are otherwise defined in the :conf_master:`file_roots` config
 option, the ``_modules/`` directory would be located in ``/srv/salt/_modules``
 on most systems.
@@ -209,6 +209,29 @@ default configuration file for the minion contains the information and format
 used to pass data to the modules. :mod:`salt.modules.test`,
 :file:`conf/minion`.
 
+.. _module_init:
+
+``__init__`` Function
+---------------------
+
+If you want your module to have different execution modes based on minion
+configuration, you can use the ``__init__(opts)`` function to perform initial
+module setup. The parameter ``opts`` is the complete minion configuration,
+as also available in the ``__opts__`` dict.
+
+.. code-block:: python
+
+    '''
+    Cheese module initialization example
+    '''
+    def __init__(opts):
+        '''
+        Allow foreign imports if configured to do so
+        '''
+        if opts.get('cheese.allow_foreign', False):
+            _enable_foreign_products()
+
+
 Strings and Unicode
 ===================
 
@@ -273,8 +296,9 @@ module is not loaded. ``False`` lets the module perform system checks and
 prevent loading if dependencies are not met.
 
 Since ``__virtual__`` is called before the module is loaded, ``__salt__`` will
-be unavailable as it will not have been packed into the module at this point in
-time.
+be unreliable as not all modules will be available at this point in time. The
+``__pillar`` and ``__grains__`` :ref:`"dunder" dictionaries <dunder-dictionaries>`
+are available however.
 
 .. note::
     Modules which return a string from ``__virtual__`` that is already used by
@@ -313,10 +337,14 @@ the case when the dependency is unavailable.
         else:
             return False, 'The cheese execution module cannot be loaded: enzymes unavailable.'
 
+    def slice():
+        pass
+
 .. code-block:: python
 
     '''
-    Cheese state module
+    Cheese state module. Note that this works in state modules because it is
+    guaranteed that execution modules are loaded first
     '''
 
     def __virtual__():

doc/ref/peer.rst

@@ -126,4 +126,4 @@ To match minions using other matchers, use ``tgt_type``:
     # salt-call publish.publish 'webserv* and not G@os:Ubuntu' test.ping tgt_type='compound'
 
 .. note::
-    In pre-Nitrogen releases, use ``expr_form`` instead of ``tgt_type``.
+    In pre-2017.7.0 releases, use ``expr_form`` instead of ``tgt_type``.

doc/ref/pillar/all/index.rst

@@ -17,6 +17,7 @@ pillar modules
     confidant
     consul_pillar
     csvpillar
+    digicert
     django_orm
     ec2_pillar
     etcd_pillar

doc/ref/pillar/all/salt.pillar.digicert.rst

@@ -0,0 +1,6 @@
+salt.pillar.digicert module
+===========================
+
+.. automodule:: salt.pillar.digicert
+    :members:
+    :undoc-members:

doc/ref/proxy/all/index.rst

@@ -12,6 +12,7 @@ proxy modules
 
     chronos
     cisconso
+    dummy
     esxi
     fx2
     junos

doc/ref/proxy/all/salt.proxy.dummy.rst

@@ -0,0 +1,6 @@
+salt.proxy.dummy module
+=======================
+
+.. automodule:: salt.proxy.dummy
+    :members:
+    :undoc-members:

doc/ref/runners/all/index.rst

@@ -16,6 +16,7 @@ runner modules
     cache
     cloud
     ddns
+    digicertapi
     doc
     drac
     error

doc/ref/runners/all/salt.runners.digicertapi.rst

@@ -0,0 +1,6 @@
+salt.runners.digicertapi module
+===============================
+
+.. automodule:: salt.runners.digicertapi
+    :members:
+    :undoc-members:

doc/ref/states/all/index.rst

@@ -74,6 +74,10 @@ state modules
     dellchassis
     disk
     docker
+    docker_container
+    docker_image
+    docker_network
+    docker_volume
     drac
     elasticsearch
     elasticsearch_index
@@ -128,6 +132,7 @@ state modules
     junos
     k8s
     kapacitor
+    kernelpkg
     keyboard
     keystone
     kmod

doc/ref/states/all/salt.states.kernelpkg.rst

@@ -0,0 +1,6 @@
+=====================
+salt.states.kernelpkg
+=====================
+
+.. automodule:: salt.states.kernelpkg
+    :members:

doc/ref/states/parallel.rst

@@ -2,8 +2,8 @@
 Running States in Parallel
 ==========================
 
-Introduced in Salt version Nitrogen it is now possible to run select states
-in parallel. This is accomplished very easily by adding the `parallel: True`
+Introduced in Salt version ``2017.7.0`` it is now possible to run select states
+in parallel. This is accomplished very easily by adding the ``parallel: True``
 option to your state declaration:
 
 .. code_block:: yaml
@@ -12,7 +12,7 @@ option to your state declaration:
       service.running:
         - parallel: True
 
-Now `nginx` will be started in a seperate process from the normal state run
+Now ``nginx`` will be started in a seperate process from the normal state run
 and will therefore not block additional states.
 
 Parallel States and Requisites
@@ -40,16 +40,16 @@ Given this example:
       cmd.run:
         - parallel: True
 
-The `sleep 10` will be started first, then the state system will block on
-starting nginx until the `sleep 10` completes. Once nginx has been ensured to
-be running then the `sleep 5` will start.
+The ``sleep 10`` will be started first, then the state system will block on
+starting nginx until the ``sleep 10`` completes. Once nginx has been ensured to
+be running then the ``sleep 5`` will start.
 
 This means that the order of evaluation of Salt States and requisites are
-still honored, and given that in the above case, `parallel: True` does not
+still honored, and given that in the above case, ``parallel: True`` does not
 actually speed things up.
 
-To run the above state much faster make sure that the `sleep 5` is evaluated
-before the `nginx` state
+To run the above state much faster make sure that the ``sleep 5`` is evaluated
+before the ``nginx`` state
 
 .. code_block:: yaml
 
@@ -67,8 +67,8 @@ before the `nginx` state
         - require:
           - cmd: sleep 10
 
-Now both of the sleep calls will be started in parallel and `nginx` will still
-wait for the state it requires, but while it waits the `sleep 5` state will
+Now both of the sleep calls will be started in parallel and ``nginx`` will still
+wait for the state it requires, but while it waits the ``sleep 5`` state will
 also complete.
 
 Things to be Careful of

doc/ref/states/requisites.rst

@@ -517,7 +517,7 @@ inherit inherited options.
 runas
 ~~~~~
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 The ``runas`` global option is used to set the user which will be used to run the command in the ``cmd.run`` module.
 
@@ -849,7 +849,7 @@ this one, include a ``mod_run_check_cmd`` in the states file for the state.
 Retrying States
 ===============
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 The retry option in a state allows it to be executed multiple times until a desired
 result is obtained or the maximum number of attempts have been made.

doc/topics/beacons/index.rst

@@ -34,7 +34,7 @@ monitored, everything is configured using Salt.
 
 Beacons are typically enabled by placing a ``beacons:`` top level block in
 ``/etc/salt/minion`` or any file in ``/etc/salt/minion.d/`` such as
-``/etc/salt/minion.d/beacons.conf``:
+``/etc/salt/minion.d/beacons.conf`` or add it to pillars for that minion:
 
 .. code-block:: yaml
 

doc/topics/cloud/aws.rst

@@ -78,6 +78,7 @@ parameters are discussed in more detail below.
       # RHEL         -> ec2-user
       # CentOS       -> ec2-user
       # Ubuntu       -> ubuntu
+      # Debian       -> admin
       #
       ssh_username: ec2-user
 
@@ -470,7 +471,7 @@ EC2 API or AWS Console.
 By default, the spot instance type is set to 'one-time', meaning it will
 be launched and, if it's ever terminated for whatever reason, it will not
 be recreated. If you would like your spot instances to be relaunched after
-a termination (by your or AWS), set the ``type`` to 'persistent'.
+a termination (by you or AWS), set the ``type`` to 'persistent'.
 
 NOTE: Spot instances are a great way to save a bit of money, but you do
 run the risk of losing your spot instances if the current price for the

doc/topics/cloud/azurearm.rst

@@ -6,7 +6,7 @@ Getting Started With Azure ARM
 
 Azure is a cloud service by Microsoft providing virtual machines, SQL services,
 media services, and more. Azure ARM (aka, the Azure Resource Manager) is a next
-generatiom version of the Azure portal and API. This document describes how to
+generation version of the Azure portal and API. This document describes how to
 use Salt Cloud to create a virtual machine on Azure ARM, with Salt installed.
 
 More information about Azure is located at `http://www.windowsazure.com/
@@ -238,6 +238,20 @@ iface_name
 Optional. The name to apply to the VM's network interface. If not supplied, the
 value will be set to ``<VM name>-iface0``.
 
+dns_servers
+-----------
+Optional. A **list** of the DNS servers to configure for the network interface
+(will be set on the VM by the DHCP of the VNET).
+
+.. code-block:: yaml
+
+    my-azurearm-profile:
+      provider: azurearm-provider
+      network: mynetwork
+      dns_servers:
+        - 10.1.1.4
+        - 10.1.1.5
+
 availability_set
 ----------------
 Optional. If set, the VM will be added to the specified availability set.

doc/topics/cloud/config.rst

@@ -97,7 +97,7 @@ Using the example configuration above:
 
 .. note::
 
-    Salt Cloud provider configurations within ``/etc/cloud.provider.d/ should not
+    Salt Cloud provider configurations within ``/etc/cloud.provider.d/`` should not
     specify the ``providers`` starting key.
 
 It is also possible to have multiple cloud configuration blocks within the same alias block.
@@ -371,7 +371,6 @@ both.
       compute_name: cloudServersOpenStack
       protocol: ipv4
       compute_region: DFW
-      protocol: ipv4
       user: myuser
       tenant: 5555555
       password: mypass

doc/topics/cloud/gce.rst

@@ -15,9 +15,10 @@ at https://cloud.google.com.
 
 Dependencies
 ============
+
 * LibCloud >= 1.0.0
 
-.. versionchanged:: Nitrogen
+.. versionchanged:: 2017.7.0
 
 * A Google Cloud Platform account with Compute Engine enabled
 * A registered Service Account for authorization
@@ -226,7 +227,7 @@ Use this setting to define the subnetwork an instance will be created in.
 This requires that the network your instance is created under has a mode of 'custom' or 'auto'.
 Additionally, the subnetwork your instance is created under is associated with the location you provide.
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 tags
 ----
@@ -526,7 +527,7 @@ not possible to add/remove existing instances to a network.
     salt-cloud -f create_network gce name=mynet cidr=10.10.10.0/24
     salt-cloud -f create_network gce name=mynet mode=auto description=some optional info.
 
-.. versionchanged:: Nitrogen
+.. versionchanged:: 2017.7.0
 
 Destroy network
 ---------------
@@ -546,7 +547,8 @@ Specify the network name to view information about the network.
     salt-cloud -f show_network gce name=mynet
 
 Create subnetwork
---------------
+-----------------
+
 New subnetworks require a name, region, and CIDR range.
 Optionally, 'description' can be provided to add an extra note to your subnetwork.
 New instances can be created and added to this subnetwork by setting the subnetwork name during create. It is
@@ -557,10 +559,11 @@ not possible to add/remove existing instances to a subnetwork.
     salt-cloud -f create_subnetwork gce name=mynet network=mynet region=us-central1 cidr=10.0.10.0/24
     salt-cloud -f create_subnetwork gce name=mynet network=mynet region=us-central1 cidr=10.10.10.0/24 description=some info about my subnet.
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Destroy subnetwork
----------------
+------------------
+
 Destroy a subnetwork by specifying the name and region. If a resource is currently using
 the target subnetwork an exception will be raised.
 
@@ -568,17 +571,18 @@ the target subnetwork an exception will be raised.
 
     salt-cloud -f delete_subnetwork gce name=mynet region=us-central1
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Show subnetwork
-------------
+---------------
+
 Specify the subnetwork name to view information about the subnetwork.
 
 .. code-block:: bash
 
     salt-cloud -f show_subnetwork gce name=mynet
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Create address
 --------------

doc/topics/cloud/libvirt.rst

@@ -32,6 +32,8 @@ Set up the provider cloud configuration file at ``/etc/salt/cloud.providers`` or
     local-kvm:
       driver: libvirt
       url: qemu:///system
+      # work around flag for XML validation errors while cloning
+      validate_xml: no
 
 Cloud Profiles
 ==============

doc/topics/cloud/map.rst

@@ -92,7 +92,7 @@ Any top level data element from your profile may be overridden in the map file:
       - web2:
         size: t2.nano
 
-As of Salt Nitrogen, nested elements are merged, and can can be specified
+As of Salt 2017.7.0, nested elements are merged, and can can be specified
 individually without having to repeat the complete definition for each top
 level data element. In this example a separate MAC is assigned to each VMware
 instance while inheriting device parameters for for disk and network

doc/topics/cloud/troubleshooting.rst

@@ -18,18 +18,6 @@ Generic Troubleshooting Steps
 This section describes a set of instructions that are useful to a large number
 of situations, and are likely to solve most issues that arise.
 
-.. admonition:: Version Compatibility
-
-    One of the most common issues that Salt Cloud users run into is import
-    errors. These are often caused by version compatibility issues with Salt.
-
-    Salt 0.16.x works with Salt Cloud 0.8.9 or greater.
-
-    Salt 0.17.x requires Salt Cloud 0.8.11.
-
-    Releases after 0.17.x (0.18 or greater) should not encounter issues as Salt
-    Cloud has been merged into Salt itself.
-
 Debug Mode
 ----------
 Frequently, running Salt Cloud in debug mode will reveal information about a

doc/topics/cloud/vmware.rst

@@ -194,6 +194,7 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
         guestinfo.foo: bar
         guestinfo.domain: foobar.com
         guestinfo.customVariable: customValue
+      annotation: Created by Salt-Cloud
 
       deploy: True
       customization: True
@@ -451,6 +452,11 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or
     present, it will be reset with the new value provided. Otherwise, a new option is
     added. Keys with empty values will be removed.
 
+``annotation``
+    User-provided description of the virtual machine. This will store a message in the
+    vSphere interface, under the annotations section in the Summary view of the virtual
+    machine.
+
 ``deploy``
     Specifies if salt should be installed on the newly created VM. Default is ``True``
     so salt will be installed using the bootstrap script. If ``template: True`` or

doc/topics/cloud/windows.rst

@@ -48,6 +48,15 @@ from saltstack.com:
 
 .. __: https://repo.saltstack.com/windows/
 
+.. _new-pywinrm:
+
+Self Signed Certificates with WinRM
+===================================
+
+Salt-Cloud can use versions of ``pywinrm<=0.1.1`` or ``pywinrm>=0.2.1``.
+
+For versions greater than `0.2.1`, ``winrm_verify_ssl`` needs to be set to
+`False` if the certificate is self signed and not verifiable.
 
 Firewall Settings
 =================
@@ -179,7 +188,8 @@ The default Windows user is `Administrator`, and the default Windows password
 is blank.
 
 If WinRM is to be used ``use_winrm`` needs to be set to `True`. ``winrm_port``
-can be used to specify a custom port (must be HTTPS listener).
+can be used to specify a custom port (must be HTTPS listener).  And
+``winrm_verify_ssl`` can be set to `False` to use a self signed certificate.
 
 
 Auto-Generated Passwords on EC2

doc/topics/development/dunder_dictionaries.rst

@@ -1,3 +1,5 @@
+.. _dunder-dictionaries:
+
 ===================
 Dunder Dictionaries
 ===================

doc/topics/eauth/index.rst

@@ -246,6 +246,10 @@ Server configuration values and their defaults:
     # Redhat Identity Policy Audit
     auth.ldap.freeipa: False
 
+
+Authenticating to the LDAP Server
++++++++++++++++++++++++++++++++++
+
 There are two phases to LDAP authentication.  First, Salt authenticates to search for a users' Distinguished Name
 and group membership.  The user it authenticates as in this phase is often a special LDAP system user with
 read-only access to the LDAP directory.  After Salt searches the directory to determine the actual user's DN
@@ -276,6 +280,10 @@ substitutes the ``{{ username }}`` value for the username when querying LDAP
 
     auth.ldap.filter: uid={{ username }}
 
+
+Determining Group Memberships (OpenLDAP / non-Active Directory)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
 For OpenLDAP, to determine group membership, one can specify an OU that contains
 group data. This is prepended to the basedn to create a search path.  Then
 the results are filtered against ``auth.ldap.groupclass``, default
@@ -285,7 +293,16 @@ the results are filtered against ``auth.ldap.groupclass``, default
 
     auth.ldap.groupou: Groups
 
-When using the `ldap('DC=domain,DC=com')` eauth operator, sometimes the records returned
+Note that as of 2017.7, auth.ldap.groupclass can refer to either a groupclass or an objectClass.
+For some LDAP servers (notably OpenLDAP without the ``memberOf`` overlay enabled) to determine group
+membership we need to know both the ``objectClass`` and the ``memberUid`` attributes.  Usually for these
+servers you will want a ``auth.ldap.groupclass`` of ``posixGroup`` and an ``auth.ldap.groupattribute`` of
+``memberUid``.
+
+LDAP servers with the ``memberOf`` overlay will have entries similar to ``auth.ldap.groupclass: person`` and
+``auth.ldap.groupattribute: memberOf``.
+
+When using the ``ldap('DC=domain,DC=com')`` eauth operator, sometimes the records returned
 from LDAP or Active Directory have fully-qualified domain names attached, while minion IDs
 instead are simple hostnames.  The parameter below allows the administrator to strip
 off a certain set of domain names so the hostnames looked up in the directory service
@@ -295,8 +312,9 @@ can match the minion IDs.
 
    auth.ldap.minion_stripdomains: ['.external.bigcorp.com', '.internal.bigcorp.com']
 
-Active Directory
-----------------
+
+Determining Group Memberships (Active Directory)
+++++++++++++++++++++++++++++++++++++++++++++++++
 
 Active Directory handles group membership differently, and does not utilize the
 ``groupou`` configuration variable.  AD needs the following options in
@@ -361,5 +379,5 @@ be part of the eAuth definition, they can be specified like this:
           - ldap('DC=corp,DC=example,DC=com'):
             - test.echo
 
-The string inside `ldap()` above is any valid LDAP/AD tree limiter.  `OU=` in
+The string inside ``ldap()`` above is any valid LDAP/AD tree limiter.  ``OU=`` in
 particular is permitted as long as it would return a list of computer objects.

doc/topics/event/master_events.rst

@@ -136,7 +136,7 @@ Runner Events
         ``state`` and ``function`` types, also includes a ``tgt_type`` value
         which shows what kind of match (``glob``, ``pcre``, etc.) was used.
         This value was named ``expr_form`` in the 2016.11 release cycle but has
-        been renamed to ``tgt_type`` in Nitrogen for consistency with other
+        been renamed to ``tgt_type`` in 2017.7.0 for consistency with other
         events.
 
 .. _event-master_presence:

doc/topics/installation/windows.rst

@@ -36,21 +36,14 @@ The 64bit installer has been tested on Windows 7 64bit and Windows Server
 Please file a bug report on our GitHub repo if issues for other platforms are
 found.
 
-There are two installers available.
+There are installers available for Python 2 and Python 3.
 
-=============================================  =================================
-Filename                                       Details
-=============================================  =================================
-``Salt-Minion-<version>-<cpuarch>-Setup.exe``  Just the salt Minion
-``Salt-<version>-<cpuarch>-Setup.exe``         Salt Minion and Master
-=============================================  =================================
+The installer will detect previous installations of Salt and ask if you would
+like to remove them. Clicking OK will remove the Salt binaries and related files
+but leave any existing config, cache, and PKI information.
 
-When run, both installers will detect previous installations of Salt and ask if
-you would like to remove them. Clicking OK will remove the Salt binaries and
-related files but leave any existing config, cache, and PKI information.
-
-Salt Minion Only Installation
-=============================
+Salt Minion Installation
+========================
 
 After the Welcome and the License Agreement, the installer asks for two bits of
 information to configure the minion; the master hostname and the minion name.
@@ -83,18 +76,6 @@ be managed there or from the command line like any other Windows service.
     2008 x64 SP1 redistributable. Allow all Windows updates to run salt-minion
     smoothly.
 
-Salt Minion/Master Installation
-===============================
-
-This installer behaves the same as the Minion installer but adds an additional
-installer page. You will be prompted to choose to install the minion and master.
-The minion check box is checked by default. To also install the master, check
-the master checkbox. To install only the master, uncheck the minion checkbox. At
-least one item must be selected.
-
-You will also be prompted on the final page to start the ``salt-master``
-service.
-
 Installation Prerequisites
 --------------------------
 
@@ -109,7 +90,7 @@ Silent Installer Options
 ========================
 
 The installer can be run silently by providing the ``/S`` option at the command
-line. Both installers also accept the following options for configuring the Salt
+line. The installer also accepts the following options for configuring the Salt
 Minion silently:
 
 =========================  =====================================================
@@ -126,19 +107,6 @@ Option                     Description
                            ``Automatic (Delayed Start)``
 =========================  =====================================================
 
-The Master/Minion installer also supports the following options:
-
-=========================  =====================================================
-Option                     Description
-=========================  =====================================================
-``/start-master=``         Either a 1 or 0. '1' will start the salt-master
-                           service, '0' will not. Default is to start the
-                           service after installation.
-``/install-master``        Will install the master along with the minion.
-                           Default is to install minion only
-``/master-only``           Will only install the master.
-=========================  =====================================================
-
 .. note::
     ``/start-service`` has been deprecated but will continue to function as
     expected for the time being.
@@ -147,24 +115,17 @@ Here are some examples of using the silent installer:
 
 .. code-block:: bat
 
-    # install both minion and master
-    # configure the minion and start both services
+    # Install the Salt Minion
+    # Configure the minion and start the service
 
-    Salt-2016.9.1-Setup-amd64.exe /S /master=yoursaltmaster /minion-name=yourminionname /install-master
+    Salt-Minion-2017.7.1-Py2-AMD64-Setup.exe /S /master=yoursaltmaster /minion-name=yourminionname
 
 .. code-block:: bat
 
-    # install only the master but don't start the salt-master service
+    # Install the Salt Minion
+    # Configure the minion but don't start the minion service
 
-    *-Setup-*.exe /S /master=yoursaltmaster /minion-name=yourminionname
-
-.. code-block:: bat
-
-    # install the minion and master
-    # configure the minion to talk to the local master
-    # start both services
-
-    *-Setup-*.exe /S /master=yoursaltmaster /minion-name=yourminionname /start-minion=0
+    Salt-Minion-2017.7.1-Py3-AMD64-Setup.exe /S /master=yoursaltmaster /minion-name=yourminionname /start-minion=0
 
 
 Running the Salt Minion on Windows as an Unprivileged User
@@ -268,21 +229,26 @@ code. They are located in the ``pkg\windows`` directory in the Salt repo
 Scripts:
 --------
 
-=================  ===========
-Script             Description
-=================  ===========
-``build_env.ps1``  A PowerShell script that sets up the build environment
-``build_pkg.bat``  A batch file that builds a Windows installer based on the
-                   contents of the ``C:\Python27`` directory
-``build.bat``      A batch file that fully automates the building of the Windows
-                   installer using the above two scripts
-=================  ===========
+===================  ===========
+Script               Description
+===================  ===========
+``build_env_2.ps1``  A PowerShell script that sets up a Python 2 build
+                     environment
+``build_env_3.ps1``  A PowerShell script that sets up a Python 3 build
+                     environment
+``build_pkg.bat``    A batch file that builds a Windows installer based on the
+                     contents of the ``C:\Python27`` directory
+``build.bat``        A batch file that fully automates the building of the
+                     Windows installer using the above two scripts
+===================  ===========
 
 .. note::
-    The ``build.bat`` and ``build_pkg.bat`` scripts both accept a single
-    parameter to specify the version of Salt that will be displayed in the
-    Windows installer. If no version is passed, the version will be determined
-    using git.
+    The ``build.bat`` and ``build_pkg.bat`` scripts both accept a parameter to
+    specify the version of Salt that will be displayed in the Windows installer.
+    If no version is passed, the version will be determined using git.
+
+    Both scripts also accept an additional parameter to specify the version of
+    Python to use. The default is 2.
 
 Prerequisite Software
 ---------------------
@@ -316,7 +282,7 @@ Go into the ``salt`` directory and checkout the version of salt to work with
 .. code-block:: bat
 
     cd salt
-    git checkout 2016.3
+    git checkout 2017.7.2
 
 2. Setup the Python Environment
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -327,14 +293,14 @@ PowerShell script.
 .. code-block:: bat
 
     cd pkg\windows
-    powershell -file build_env.ps1
+    powershell -file build_env_2.ps1
 
 .. note::
     You can also do this from Explorer by navigating to the ``pkg\windows``
-    directory, right clicking the **build_env.ps1** powershell script and
+    directory, right clicking the **build_env_2.ps1** powershell script and
     selecting **Run with PowerShell**
 
-This will download and install Python with all the dependencies needed to
+This will download and install Python 2 with all the dependencies needed to
 develop and build Salt.
 
 .. note::
@@ -367,6 +333,10 @@ with ``pip``
     If ``pip`` is not recognized, you may need to restart your shell to get the
     updated path
 
+.. note::
+    If ``pip`` is still not recognized make sure that the Python Scripts folder
+    is in the System ``%PATH%``. (``C:\Python2\Scripts``)
+
 4. Setup Salt Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -381,9 +351,9 @@ easiest way to set this up is to copy the contents of the
     md salt
     xcopy /s /e \Salt-Dev\salt\pkg\windows\buildenv\* \salt\
 
-Now go into the ``C:\salt\conf`` directory and edit the file name ``minion`` (no
-extension). You need to configure the master and id parameters in this file.
-Edit the following lines:
+Now go into the ``C:\salt\conf`` directory and edit the minion config file named
+``minion`` (no extension). You need to configure the master and id parameters in
+this file. Edit the following lines:
 
 .. code-block:: bat
 
@@ -414,16 +384,20 @@ Navigate to the root ``salt`` directory and install Salt.
 -------------------------------
 
 Navigate to the ``pkg\windows`` directory and run the ``build_pkg.bat``
-with the build version (2016.3) script.
+with the build version (2017.7.2) and the Python version as parameters.
 
 .. code-block:: bat
 
     cd pkg\windows
-    build_pkg.bat 2016.3
+    build_pkg.bat 2017.7.2 2
+                  ^^^^^^^^ ^
+                      |    |
+    # build version --     |
+    # python version ------
 
 .. note::
     If no version is passed, the ``build_pkg.bat`` will guess the version number
-    using git.
+    using git. If the python version is not passed, the default is 2.
 
 .. _create-windows-installer-easy:
 
@@ -446,7 +420,7 @@ build.
 .. code-block:: bat
 
     cd salt
-    git checkout 2016.3
+    git checkout 2017.7.2
 
 Then navigate to ``pkg\windows`` and run the ``build.bat`` script with the
 version you're building.
@@ -454,10 +428,14 @@ version you're building.
 .. code-block:: bat
 
     cd pkg\windows
-    build.bat 2016.3
+    build.bat 2017.7.2 3
+              ^^^^^^^^ ^
+                  |    |
+    # build version    |
+    # python version --
 
-This will install everything needed to build a Windows installer for Salt. The
-binary will be in the ``salt\pkg\windows\installer`` directory.
+This will install everything needed to build a Windows installer for Salt using
+Python 3. The binary will be in the ``salt\pkg\windows\installer`` directory.
 
 .. _test-salt-minion:
 

doc/topics/master_tops/index.rst

@@ -89,6 +89,6 @@ bare-bones example:
 .. note::
     If a master_tops module returns :ref:`top file <states-top>` data for a
     given minion, it will be added to the states configured in the top file. It
-    will *not* replace it altogether. The Nitrogen release adds additional
+    will *not* replace it altogether. The Oxygen release adds additional
     functionality allowing a minion to treat master_tops as the single source
     of truth, irrespective of the top file.

doc/topics/mine/index.rst

@@ -225,5 +225,5 @@ Create the Jinja template in :file:`/srv/salt/haproxy_config`:
 In the above example, ``server`` will be expanded to the ``minion_id``.
 
 .. note::
-    The expr_form argument will be renamed to ``tgt_type`` in the Nitrogen
+    The expr_form argument will be renamed to ``tgt_type`` in the 2017.7.0
     release of Salt.

doc/topics/network_automation/index.rst

@@ -25,7 +25,7 @@ The methodologies for network automation have been introduced in
 minions:
 
 - :mod:`NAPALM proxy <salt.proxy.napalm>`
-- :mod:`Junos <salt.proxy.junos>`
+- :mod:`Junos proxy<salt.proxy.junos>`
 - :mod:`Cisco NXOS <salt.proxy.nxos>`
 - :mod:`Cisco NOS <salt.proxy.cisconso>`
 
@@ -40,7 +40,7 @@ and the interaction with the network device does not rely on a particular vendor
 
 .. image:: /_static/napalm_logo.png
 
-Bgeginning with Nitrogen, the NAPALM modules have been transformed so they can
+Beginning with Nitrogen, the NAPALM modules have been transformed so they can
 run in both proxy and regular minions. That means, if the operating system
 allows, the salt-minion package can be installed directly on the network gear.
 The interface between the network operating system and Salt in that case would
@@ -411,6 +411,224 @@ multi-vendor network:
 Besides CLI, the state can be scheduled or executed when triggered by a certain
 event.
 
+JUNOS
+-----
+
+Juniper has developed a Junos specific proxy infrastructure which allows
+remote execution and configuration management of Junos devices without
+having to install SaltStack on the device. The infrastructure includes:
+
+- :mod:`Junos proxy <salt.proxy.junos>`
+- :mod:`Junos execution module <salt.modules.junos>`
+- :mod:`Junos state module <salt.states.junos>`
+- :mod:`Junos syslog engine <salt.engines.junos_syslog>`
+
+The execution and state modules are implemented using junos-eznc (PyEZ).
+Junos PyEZ is a microframework for Python that enables you to remotely manage
+and automate devices running the Junos operating system.
+
+
+Getting started
+###############
+
+Install PyEZ on the system which will run the Junos proxy minion.
+It is required to run Junos specific modules.
+
+.. code-block:: shell
+
+    pip install junos-eznc
+
+Next, set the master of the proxy minions.
+
+``/etc/salt/proxy``
+
+.. code-block:: yaml
+
+    master: <master_ip>
+
+Add the details of the Junos device. Device details are usually stored in
+salt pillars. If the you do not wish to store credentials in the pillar,
+one can setup passwordless ssh.
+
+``/srv/pillar/vmx_details.sls``
+
+.. code-block:: yaml
+
+    proxy:
+      proxytype: junos
+      host: <hostip>
+      username: user
+      passwd: secret123
+
+Map the pillar file to the proxy minion. This is done in the top file.
+
+``/srv/pillar/top.sls``
+
+.. code-block:: yaml
+
+    base:
+      vmx:
+        - vmx_details
+
+.. note::
+
+    Before starting the Junos proxy make sure that netconf is enabled on the
+    Junos device. This can be done by adding the following configuration on
+    the Junos device.
+
+    .. code-block:: shell
+
+        set system services netconf ssh
+
+Start the salt master.
+
+.. code-block:: bash
+
+    salt-master -l debug
+
+
+Then start the salt proxy.
+
+.. code-block:: bash
+
+    salt-proxy --proxyid=vmx -l debug
+
+Once the master and junos proxy minion have started, we can run execution
+and state modules on the proxy minion. Below are few examples.
+
+CLI examples
+############
+
+For detailed documentation of all the junos execution modules refer:
+:mod:`Junos execution module <salt.modules.junos>`
+
+Display device facts.
+
+.. code-block:: bash
+
+    $ sudo salt 'vmx' junos.facts
+
+
+Refresh the Junos facts. This function will also refresh the facts which are
+stored in salt grains. (Junos proxy stores Junos facts in the salt grains)
+
+.. code-block:: bash
+
+    $ sudo salt 'vmx' junos.facts_refresh
+
+
+Call an RPC.
+
+.. code-block:: bash
+
+    $ sudo salt 'vmx' junos.rpc 'get-interface-information' '/var/log/interface-info.txt' terse=True
+
+
+Install config on the device.
+
+.. code-block:: bash
+
+    $ sudo salt 'vmx' junos.install_config 'salt://my_config.set'
+
+
+Shutdown the junos device.
+
+.. code-block:: bash
+
+    $ sudo salt 'vmx' junos.shutdown shutdown=True in_min=10
+
+
+State file examples
+###################
+
+For detailed documentation of all the junos state modules refer:
+:mod:`Junos state module <salt.states.junos>`
+
+Executing an RPC on Junos device and storing the output in a file.
+
+``/srv/salt/rpc.sls``
+
+.. code-block:: yaml
+
+    get-interface-information:
+        junos:
+          - rpc
+          - dest: /home/user/rpc.log
+          - interface_name: lo0
+
+
+Lock the junos device, load the configuration, commit it and unlock
+the device.
+
+``/srv/salt/load.sls``
+
+.. code-block:: yaml
+
+    lock the config:
+      junos.lock
+
+    salt://configs/my_config.set:
+      junos:
+        - install_config
+        - timeout: 100
+        - diffs_file: 'var/log/diff'
+
+    commit the changes:
+      junos:
+        - commit
+
+    unlock the config:
+      junos.unlock
+
+
+According to the device personality install appropriate image on the device.
+
+``/srv/salt/image_install.sls``
+
+.. code-block:: jinja
+
+    {% if grains['junos_facts']['personality'] == MX %}
+    salt://images/mx_junos_image.tgz:
+      junos:
+        - install_os
+        - timeout: 100
+        - reboot: True
+    {% elif grains['junos_facts']['personality'] == EX %}
+    salt://images/ex_junos_image.tgz:
+      junos:
+        - install_os
+        - timeout: 150
+    {% elif grains['junos_facts']['personality'] == SRX %}
+    salt://images/srx_junos_image.tgz:
+      junos:
+        - install_os
+        - timeout: 150
+    {% endif %}
+
+Junos Syslog Engine
+###################
+
+:mod:`Junos Syslog Engine <salt.engines.junos_syslog>` is a Salt engine
+which receives data from various Junos devices, extracts event information and
+forwards it on the master/minion event bus. To start the engine on the salt
+master, add the following configuration in the master config file.
+The engine can also run on the salt minion.
+
+``/etc/salt/master``
+
+.. code-block:: yaml
+
+    engines:
+      - junos_syslog:
+          port: xxx
+
+For junos_syslog engine to receive events, syslog must be set on the Junos device.
+This can be done via following configuration:
+
+.. code-block:: shell
+
+    set system syslog host <ip-of-the-salt-device> port xxx any any
+
 .. toctree::
     :maxdepth: 2
     :glob:

doc/topics/pillar/index.rst

@@ -376,7 +376,7 @@ the ``testing`` environment, without modifying the in-memory pillar data.
     this case would still restrict the states' pillar data to just that of the
     ``testing`` pillar environment.
 
-Starting in the Nitrogen release, it is possible to pin the pillarenv to the
+Starting in the 2017.7.0 release, it is possible to pin the pillarenv to the
 effective saltenv, using the :conf_minion:`pillarenv_from_saltenv` minion
 config option. When this is set to ``True``, if a specific saltenv is specified
 when running states, the ``pillarenv`` will be the same. This essentially makes
@@ -497,7 +497,7 @@ compilation.
 Encrypted Pillar SLS
 --------------------
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 Consider the following pillar SLS file:
 

doc/topics/proxyminion/index.rst

@@ -36,7 +36,7 @@ or more minions.
 See :ref:`Proxyminion Beacon <proxy-minion-beacon>` to help
 with easy configuration and management of ``salt-proxy`` processes.
 
-New in Nitrogen
+New in 2017.7.0
 ---------------
 
 The :conf_proxy:`proxy_merge_grains_in_module` configuration variable
@@ -128,7 +128,7 @@ will be executed on proxy-minion startup and its contents will be merged with
 the rest of the proxy's grains.  Since older proxy-minions might have used other
 methods to call such a function and add its results to grains, this is config-gated
 by a new proxy configuration option called ``proxy_merge_grains_in_module``.  This
-defaults to ``True`` in the **Nitrogen** release.
+defaults to ``True`` in the **2017.7.0** release.
 
 
 New in 2015.8.2
@@ -377,7 +377,7 @@ the ``proxy_keep_alive_interval`` option, in minutes.
 the standard install directories for grains, grains can be computed and
 returned by this function.  This function will be called automatically
 if ``proxy_merge_grains_in_module`` is set to ``True`` in /etc/salt/proxy.
-This variable defaults to ``True`` in the release code-named *Nitrogen*.
+This variable defaults to ``True`` in the release code-named *2017.7.0*.
 
 Pre 2015.8 the proxymodule also must have an ``id()`` function.  2015.8 and following don't use
 this function because the proxy's id is required on the command line.
@@ -621,7 +621,7 @@ the proxy and grains directories.
 
 This function will only be called automatically if the configuration variable ``proxy_merge_grains_in_module``
 is set to True in the proxy configuration file (default ``/etc/salt/proxy``).  This
-variable defaults to ``True`` in the release code-named *Nitrogen*.
+variable defaults to ``True`` in the release code-named *2017.7.0*.
 
 
 .. code: python::

doc/topics/reactor/index.rst

@@ -396,7 +396,7 @@ Use the ``tgt_type`` argument to specify a matcher:
 
 .. note::
     The ``tgt_type`` argument was named ``expr_form`` in releases prior to
-    Nitrogen (2016.11.x and earlier).
+    2017.7.0 (2016.11.x and earlier).
 
 Any other parameters in the :py:meth:`LocalClient().cmd()
 <salt.client.LocalClient.cmd>` method can be specified as well.

doc/topics/releases/2015.8.0.rst

@@ -231,7 +231,7 @@ Deprecations
 
 - The use of ``provider`` in Salt Cloud provider files to define cloud drivers
   has been deprecated in favor of using ``driver``. Both terms will work until
-  the Nitrogen release of Salt. Example provider file:
+  the 2017.7.0 release of Salt. Example provider file:
 
 .. code-block:: yaml
 

doc/topics/releases/2016.11.0.rst

@@ -561,7 +561,7 @@ General Deprecations
   - If ``env`` (or ``__env__``) is supplied as a keyword argument to a function
     that also accepts arbitrary keyword arguments, then a new warning informs the
     user that ``env`` is no longer used if it is found.  This new warning will be
-    removed in Salt Nitrogen.
+    removed in Salt 2017.7.0.
 
     .. code-block:: python
 

doc/topics/releases/2016.3.0.rst

@@ -274,7 +274,7 @@ Module Changes
   :mod:`apache_site state module <salt.states.apache_site>`: the ``enable`` and
   ``disable`` functions were renamed to ``enabled`` and ``disabled``,
   respectively.  In :pull:`33562`, these functions were readded and properly
-  deprecated and will be removed in Salt Nitrogen.  This fix will be available
+  deprecated and will be removed in Salt 2017.7.0.  This fix will be available
   in 2016.3.1.  As a workaround, try
 
   .. code-block:: sls

doc/topics/releases/2016.3.7.rst

@@ -9,3 +9,18 @@ controls whether a minion can request that the master revoke its key.  When True
 can request a key revocation and the master will comply.  If it is False, the key will not
 be revoked by the msater.
 
+New master configuration option `require_minion_sign_messages`
+This requires that minions cryptographically sign the messages they
+publish to the master.  If minions are not signing, then log this information
+at loglevel 'INFO' and drop the message without acting on it.
+
+New master configuration option `drop_messages_signature_fail`
+Drop messages from minions when their signatures do not validate.
+Note that when this option is False but `require_minion_sign_messages` is True
+minions MUST sign their messages but the validity of their signatures
+is ignored.
+
+New minion configuration option `minion_sign_messages`
+Causes the minion to cryptographically sign the payload of messages it places
+on the event bus for the master.  The payloads are signed with the minion's
+private key so the master can verify the signature with its public key.

doc/topics/releases/2017.7.0.rst

@@ -1,8 +1,49 @@
-:orphan:
+.. _release-2017-7-0:
+
+===============================================
+Salt 2017.7.0 Release Notes - Codename Nitrogen
+===============================================
+
+
+========
+Python 3
+========
+
+The 2017.7 Salt Release adds initial Python 3 support.
+
+The default Python version of Salt will remain Python 2, although Python 3 packages will be supplied for users who want to help test this new feature.
+
+======================
+Python 2.6 Deprecation
+======================
+
+Salt will no longer support Python 2.6. We will provide python2.7 packages on our repo_ for RedHat and CentOS 6 to ensure users can still run Salt on these platforms.
+
+.. _repo: https://repo.saltstack.com/
+
+============
+Known Issues
+============
+The following salt-cloud drivers have known issues running with Python 3. These drivers will not work with Python 3, and Python 2.7 should be used instead:
+
+- Joyent
+
+- Any driver that relies on the `apache-libcloud` library such as cloudstack, dimenstiondata, gce, nova, and openstack
+
+- When running under Python 3, users who require Unicode support should ensure that a locale is set on their machines.
+  Users using the `C` locale are advised to switch to a UTF-aware locale to ensure proper functionality with Salt with Python 3.
+
+
+Remember to update the Salt Master first
+========================================
+Salt's policy has always been that when upgrading, the minion should never be
+on a newer version than the master.  Specifically with this update, because of
+changes in the fileclient, the 2017.7 minion requires a 2017.7 master.
+
+Backwards compatiblity is still maintained, so older minions can still be used.
+
+More information can be found in the :ref:`Salt FAQ<which-version>`
 
-======================================
-Salt Release Notes - Codename Nitrogen
-======================================
 
 States Added for Management of systemd Unit Masking
 ===================================================
@@ -161,6 +202,7 @@ Wildcard Versions in :py:func:`pkg.installed <salt.states.pkg.installed>` States
 - The :py:func:`pkg.installed <salt.states.pkg.installed>` state now supports
   wildcards in package versions, for the following platforms:
 
+  - SUSE/openSUSE Leap/Thumbleweed
   - Debian/Ubuntu
   - RHEL/CentOS
   - Arch Linux
@@ -266,6 +308,82 @@ As well as from salt-api:
 
     {"return": [{"jerry": {"jid": "20170520151531477653", "retcode": 1, "ret": ""}}]}
 
+Jinja
+=====
+
+Filters
+-------
+
+New filters in 2017.7.0:
+
+- :jinja_ref:`to_bool`
+- :jinja_ref:`exactly_n_true`
+- :jinja_ref:`exactly_one_true`
+- :jinja_ref:`quote`
+- :jinja_ref:`regex_search`
+- :jinja_ref:`regex_match`
+- :jinja_ref:`uuid`
+- :jinja_ref:`is_list`
+- :jinja_ref:`is_iter`
+- :jinja_ref:`min`
+- :jinja_ref:`max`
+- :jinja_ref:`avg`
+- :jinja_ref:`union`
+- :jinja_ref:`intersect`
+- :jinja_ref:`difference`
+- :jinja_ref:`symmetric_difference`
+- :jinja_ref:`is_sorted`
+- :jinja_ref:`compare_lists`
+- :jinja_ref:`compare_dicts`
+- :jinja_ref:`is_hex`
+- :jinja_ref:`contains_whitespace`
+- :jinja_ref:`substring_in_list`
+- :jinja_ref:`check_whitelist_blacklist`
+- :jinja_ref:`date_format`
+- :jinja_ref:`str_to_num`
+- :jinja_ref:`to_bytes`
+- :jinja_ref:`json_decode_list`
+- :jinja_ref:`json_decode_dict`
+- :jinja_ref:`rand_str`
+- :jinja_ref:`md5`
+- :jinja_ref:`sha256`
+- :jinja_ref:`sha512`
+- :jinja_ref:`base64_encode`
+- :jinja_ref:`base64_decode`
+- :jinja_ref:`hmac`
+- :jinja_ref:`http_query`
+- :jinja_ref:`is_ip`
+- :jinja_ref:`is_ipv4`
+- :jinja_ref:`is_ipv6`
+- :jinja_ref:`ipaddr`
+- :jinja_ref:`ipv4`
+- :jinja_ref:`ipv6`
+- :jinja_ref:`network_hosts`
+- :jinja_ref:`network_size`
+- :jinja_ref:`gen_mac`
+- :jinja_ref:`mac_str_to_bytes`
+- :jinja_ref:`dns_check`
+- :jinja_ref:`is_text_file`
+- :jinja_ref:`is_binary_file`
+- :jinja_ref:`is_empty_file`
+- :jinja_ref:`file_hashsum`
+- :jinja_ref:`list_files`
+- :jinja_ref:`path_join`
+- :jinja_ref:`which`
+
+Logs
+----
+
+Another new feature - although not limited to Jinja only -
+is being able to log debug messages directly from the template:
+
+.. code-block:: jinja
+
+    {%- do salt.log.error('logging from jinja') -%}
+
+See the :jinja_ref:`logs` paragraph.
+
+
 Network Automation
 ==================
 
@@ -289,7 +407,7 @@ have been improved, enhanced and widenened in scope:
 - Proxy keepalive: due to external factors, the connection with the remote
   device can be dropped, e.g.: packet loss, idle time (no commands issued
   within a couple of minutes or seconds), or simply the device decides to kill
-  the process. In Nitrogen we have introduced the functionality to re-establish
+  the process. In 2017.7.0 we have introduced the functionality to re-establish
   the connection. One can disable this feature through the
   :conf_proxy:`proxy_keep_alive` option and adjust the polling frequency
   speciying a custom value for :conf_proxy:`proxy_keep_alive_interval`,
@@ -334,6 +452,7 @@ New functions:
   (in dBm).
 
 New grains: :mod:`Host <salt.grains.napalm.host>`,
+:mod:`Host DNS<salt.grains.napalm.host_dns>`,
 :mod:`Username <salt.grains.napalm.username>` and
 :mod:`Optional args <salt.grains.napalm.optional_args>`.
 
@@ -443,7 +562,7 @@ documentation for :ref:`skip_translate
 .. note::
     When running the :py:func:`docker_container.running
     <salt.states.docker_container.running>` state for the first time after
-    upgrading to Nitrogen, your container(s) may be replaced. The changes may
+    upgrading to 2017.7.0, your container(s) may be replaced. The changes may
     show diffs for certain parameters which say that the old value was an empty
     string, and the new value is ``None``. This is due to the fact that in
     prior releases Salt was passing empty strings for these values when
@@ -465,14 +584,191 @@ Using the new ``roster_order`` configuration syntax it's now possible to compose
 of grains, pillar and mine data and even Salt SDB URLs.
 The new release is also fully IPv4 and IPv6 enabled and even has support for CIDR ranges.
 
+Salt-SSH Default Options
+========================
+
+Defaults for rosters can now be set, so that they don't have to be set on every
+entry in a roster or specified from the commandline.
+
+The new option is :ref:`roster_defaults<roster-defaults>` and is specified in
+the master config file.
+
+.. code-block:: yaml
+
+    roster_defaults:
+      user: daniel
+      sudo: True
+      priv: /root/.ssh/id_rsa
+      tty: True
+
+Blacklist or Whitelist Extmod Sync
+==================================
+
+The modules that are synced to minions can now be limited.
+
+The following configuration options have been added for the master:
+
+- :conf_master:`extmod_whitelist`
+- :conf_master:`extmod_blacklist`
+
+and for the minion:
+
+- :conf_minion:`extmod_whitelist`
+- :conf_minion:`extmod_blacklist`
+
+Additional Features
+===================
+
+- The :mod:`mine.update <salt.modules.mine.update>` function
+  has a new optional argument ``mine_functions`` that can be used
+  to refresh mine functions at a more specific interval
+  than scheduled using the ``mine_interval`` option.
+  However, this argument can be used by explicit schedule.
+  For example, if we need the mines for ``net.lldp`` to be refreshed
+  every 12 hours:
+
+  .. code-block:: yaml
+
+      schedule:
+        lldp_mine_update:
+          function: mine.update
+          kwargs:
+            mine_functions:
+              net.lldp: []
+          hours: 12
+
+- The ``salt`` runner has a new function: :mod:`salt.execute <salt.runners.salt.execute>`.
+  It is mainly a shortcut to facilitate the execution of various functions
+  from other runners, e.g.:
+
+  .. code-block:: python
+
+      ret1 = __salt__['salt.execute']('*', 'mod.fun')
+
 New Modules
 ===========
 
+Beacons
+-------
+
+- :mod:`salt.beacons.log <salt.beacons.log>`
+
+Cache
+-----
+
+- :mod:`salt.cache.redis_cache <salt.cache.redis_cache>`
+
+Engines
+-------
+
+- :mod:`salt.engines.stalekey <salt.engines.stalekey>`
+- :mod:`salt.engines.junos_syslog <salt.engines.junos_syslog>`
+- :mod:`salt.engines.napalm_syslog <salt.engines.napalm_syslog>`
+
+Execution modules
+-----------------
+
+- :mod:`salt.modules.apk <salt.modules.apk>`
+- :mod:`salt.modules.at_solaris <salt.modules.at_solaris>`
+- :mod:`salt.modules.boto_kinesis <salt.modules.boto_kinesis>`
+- :mod:`salt.modules.boto3_elasticache <salt.modules.boto3_elasticache>`
+- :mod:`salt.modules.boto3_route53 <salt.modules.boto3_route53>`
+- :mod:`salt.modules.capirca_acl <salt.modules.capirca_acl>`
+- :mod:`salt.modules.freebsd_update <salt.modules.freebsd_update>`
+- :mod:`salt.modules.grafana4 <salt.modules.grafana4>`
+- :mod:`salt.modules.heat <salt.modules.heat>`
+- :mod:`salt.modules.icinga2 <salt.modules.icinga2>`
+- :mod:`salt.modules.logmod <salt.modules.logmod>`
+- :mod:`salt.modules.mattermost <salt.modules.mattermost>`
+- :mod:`salt.modules.namecheap_dns <salt.modules.namecheap_dns>`
+- :mod:`salt.modules.namecheap_domains <salt.modules.namecheap_domains>`
+- :mod:`salt.modules.namecheap_ns <salt.modules.namecheap_ns>`
+- :mod:`salt.modules.namecheap_users <salt.modules.namecheap_users>`
+- :mod:`salt.modules.namecheap_ssl <salt.modules.namecheap_ssl>`
+- :mod:`salt.modules.napalm <salt.modules.napalm>`
+- :mod:`salt.modules.napalm_acl <salt.modules.napalm_acl>`
+- :mod:`salt.modules.napalm_yang_mod <salt.modules.napalm_yang_mod>`
+- :mod:`salt.modules.pdbedit <salt.modules.pdbedit>`
+- :mod:`salt.modules.solrcloud <salt.modules.solrcloud>`
+- :mod:`salt.modules.statuspage <salt.modules.statuspage>`
+- :mod:`salt.modules.zonecfg <salt.modules.zonecfg>`
+- :mod:`salt.modules.zoneadm <salt.modules.zoneadm>`
+
+Grains
+------
+
+- :mod:`salt.grains.metadata <salt.grains.metadata>`
+- :mod:`salt.grains.mdata <salt.grains.mdata>`
+
 Outputters
 ----------
 
-- :mod:`table <salt.output.table_out>`
-- :mod:`profile <salt.output.profile>`
+- :mod:`salt.output.table_out <salt.output.table_out>`
+
+Pillar
+------
+
+- :mod:`salt.pillar.postgres <salt.pillar.postgres>`
+- :mod:`salt.pillar.vmware_pillar <salt.pillar.vmware_pillar>`
+
+Returners
+---------
+
+- :mod:`salt.returners.mattermost_returner <salt.returners.mattermost_returner>`
+- :mod:`salt.returners.highstate_return <salt.returners.highstate_return>`
+
+Roster
+------
+
+- :mod:`salt.roster.cache <salt.roster.cache>`
+
+Runners
+-------
+
+- :mod:`salt.runners.bgp <salt.runners.bgp>`
+- :mod:`salt.runners.mattermost <salt.runners.mattermost>`
+- :mod:`salt.runners.net <salt.runners.net>`
+
+SDB
+---
+
+- :mod:`salt.sdb.yaml <salt.sdb.yaml>`
+- :mod:`salt.sdb.tism <salt.sdb.tism>`
+- :mod:`salt.sdb.cache <salt.sdb.cache>`
+
+States
+------
+
+- :mod:`salt.states.boto_kinesis <salt.states.boto_kinesis>`
+- :mod:`salt.states.boto_efs <salt.states.boto_efs>`
+- :mod:`salt.states.boto3_elasticache <salt.states.boto3_elasticache>`
+- :mod:`salt.states.boto3_route53 <salt.states.boto3_route53>`
+- :mod:`salt.states.docker_container <salt.states.docker_container>`
+- :mod:`salt.states.docker_image <salt.states.docker_image>`
+- :mod:`salt.states.docker_network <salt.states.docker_network>`
+- :mod:`salt.states.docker_volume <salt.states.docker_volume>`
+- :mod:`salt.states.elasticsearch <salt.states.elasticsearch>`
+- :mod:`salt.states.grafana4_dashboard <salt.states.grafana4_dashboard>`
+- :mod:`salt.states.grafana4_datasource <salt.states.grafana4_datasource>`
+- :mod:`salt.states.grafana4_org <salt.states.grafana4_org>`
+- :mod:`salt.states.grafana4_user <salt.states.grafana4_user>`
+- :mod:`salt.states.heat <salt.states.heat>`
+- :mod:`salt.states.icinga2 <salt.states.icinga2>`
+- :mod:`salt.states.influxdb_continuous_query <salt.states.influxdb_continuous_query>`
+- :mod:`salt.states.influxdb_retention_policy <salt.states.influxdb_retention_policy>`
+- :mod:`salt.states.logadm <salt.states.logadm>`
+- :mod:`salt.states.logrotate <salt.states.logrotate>`
+- :mod:`salt.states.msteams <salt.states.msteams>`
+- :mod:`salt.states.netacl <salt.states.netacl>`
+- :mod:`salt.states.netconfig <salt.states.netconfig>`
+- :mod:`salt.states.netyang <salt.states.netyang>`
+- :mod:`salt.states.nix <salt.states.nix>`
+- :mod:`salt.states.pdbedit <salt.states.pdbedit>`
+- :mod:`salt.states.solrcloud <salt.states.solrcloud>`
+- :mod:`salt.states.statuspage <salt.states.statuspage>`
+- :mod:`salt.states.vault <salt.states.vault>`
+- :mod:`salt.states.win_wua <salt.states.win_wua>`
+- :mod:`salt.states.zone <salt.states.zone>`
 
 Deprecations
 ============
@@ -530,7 +826,7 @@ The ``htpasswd`` execution module had the following function removed:
 - ``useradd_all``: Please use ``useradd`` instead.
 
 The ``img`` execution module has been removed. All of its associated functions
-were marked for removal in the Nitrogen release. The functions removed in this
+were marked for removal in the 2017.7.0 release. The functions removed in this
 module are mapped as follows:
 
 - ``mount_image``/``mnt_image``: Please use ``mount.mount`` instead.
@@ -611,41 +907,41 @@ State Deprecations
 
 The ``apache_conf`` state had the following functions removed:
 
-  - ``disable``: Please use ``disabled`` instead.
-  - ``enable``: Please use ``enabled`` instead.
+- ``disable``: Please use ``disabled`` instead.
+- ``enable``: Please use ``enabled`` instead.
 
 The ``apache_module`` state had the following functions removed:
 
-  - ``disable``: Please use ``disabled`` instead.
-  - ``enable``: Please use ``enabled`` instead.
+- ``disable``: Please use ``disabled`` instead.
+- ``enable``: Please use ``enabled`` instead.
 
 The ``apache_site`` state had the following functions removed:
 
-  - ``disable``: Please use ``disabled`` instead.
-  - ``enable``: Please use ``enabled`` instead.
+- ``disable``: Please use ``disabled`` instead.
+- ``enable``: Please use ``enabled`` instead.
 
 The ``chocolatey`` state had the following functions removed:
 
-  - ``install``: Please use ``installed`` instead.
-  - ``uninstall``: Please use ``uninstalled`` instead.
+- ``install``: Please use ``installed`` instead.
+- ``uninstall``: Please use ``uninstalled`` instead.
 
 The ``git`` state had the following changes:
 
-  - The ``config`` function was removed. Please use ``config_set`` instead.
-  - The ``is_global`` option was removed from the ``config_set`` function.
-    Please use ``global`` instead.
-  - The ``always_fetch`` option was removed from the ``latest`` function, as
-    it no longer has any effect. Please see the :ref:`2015.8.0<release-2015-8-0>`
-    release notes for more information.
-  - The ``force`` option was removed from the ``latest`` function. Please
-    use ``force_clone`` instead.
-  - The ``remote_name`` option was removed from the ``latest`` function.
-    Please use ``remote`` instead.
+- The ``config`` function was removed. Please use ``config_set`` instead.
+- The ``is_global`` option was removed from the ``config_set`` function.
+  Please use ``global`` instead.
+- The ``always_fetch`` option was removed from the ``latest`` function, as
+  it no longer has any effect. Please see the :ref:`2015.8.0<release-2015-8-0>`
+  release notes for more information.
+- The ``force`` option was removed from the ``latest`` function. Please
+  use ``force_clone`` instead.
+- The ``remote_name`` option was removed from the ``latest`` function.
+  Please use ``remote`` instead.
 
 The ``glusterfs`` state had the following function removed:
 
-  - ``created``: Please use ``volume_present`` instead.
+- ``created``: Please use ``volume_present`` instead.
 
 The ``openvswitch_port`` state had the following change:
 
-  - The ``type`` option was removed from the ``present`` function. Please use ``tunnel_type`` instead.
+- The ``type`` option was removed from the ``present`` function. Please use ``tunnel_type`` instead.

doc/topics/releases/index.rst

@@ -20,6 +20,7 @@ Previous Releases
     :maxdepth: 1
     :glob:
 
+    2017.7.*
     2016.11.*
     2016.3.*
     2015.8.*

doc/topics/releases/oxygen.rst

@@ -4,6 +4,57 @@
 Salt Release Notes - Codename Oxygen
 ====================================
 
+Comparison Operators in Package Installation
+--------------------------------------------
+
+Salt now supports using comparison operators (e.g. ``>=1.2.3``) when installing
+packages on minions which use :mod:`yum/dnf <salt.modules.yumpkg>` or :mod:`apt
+<salt.modules.aptpkg>`. This is supported both in the :py:func:`pkg.installed
+<salt.states.pkg.installed>` state and in the ``pkg.install`` remote execution
+function.
+
+:ref:`Master Tops <master-tops-system>` Changes
+-----------------------------------------------
+
+When both :ref:`Master Tops <master-tops-system>` and a :ref:`Top File
+<states-top>` produce SLS matches for a given minion, the matches were being
+merged in an unpredictable manner which did not preserve ordering. This has
+been changed. The top file matches now execute in the expected order, followed
+by any master tops matches that are not matched via a top file.
+
+To make master tops matches execute first, followed by top file matches, set
+the new :conf_minion:`master_tops_first` minion config option to ``True``.
+
+New GitFS Features
+------------------
+
+Two new features which affect how GitFS maps branches/tags to fileserver
+environments (i.e. ``saltenvs``) have been added:
+
+1. It is now possible to completely turn off Salt's default mapping logic
+   (aside from the mapping of the ``base`` saltenv). This can be triggered
+   using the new :conf_master:`gitfs_disable_saltenv_mapping` config option.
+
+   .. note::
+       When this is disabled, only the ``base`` saltenv and any configured
+       using :ref:`per-saltenv configuration parameters
+       <gitfs-per-saltenv-config>` will be available.
+
+2. The types of refs which Salt will use as saltenvs can now be controlled. In
+   previous releases, branches and tags were both mapped as environments, and
+   individual commit SHAs could be specified as saltenvs in states (and when
+   caching files using :py:func:`cp.cache_file <salt.modules.cp.cache_file>`).
+   Using the new :conf_master:`gitfs_ref_types` config option, the types of
+   refs which are used as saltenvs can be restricted. This makes it possible to
+   ignore all tags and use branches only, and also to keep SHAs from being made
+   available as saltenvs.
+
+Salt Cloud and Newer PyWinRM Versions
+-------------------------------------
+
+Versions of ``pywinrm>=0.2.1`` are finally able to disable validation of self
+signed certificates.  :ref:`Here<new-pywinrm>` for more information.
+
 Configuration Option Deprecations
 ---------------------------------
 

doc/topics/releases/version_numbers.rst

@@ -11,9 +11,11 @@ format ``YYYY.MM.R``. The year (``YYYY``) and month (``MM``) reflect when the
 release was created. The bugfix release number (``R``) increments within that
 feature release.
 
-.. note:: Prior to the ``2014.1.0`` release, the typical semantic versioning was
-   still being used. Because of the rolling nature of the project, this did not
-   make sense. The ``0.17`` release was the last of that style.
+.. note::
+
+    Prior to the ``2014.1.0`` release, the typical semantic versioning was
+    still being used. Because of the rolling nature of the project, this did not
+    make sense. The ``0.17`` release was the last of that style.
 
 Code Names
 ----------
@@ -31,8 +33,9 @@ Assigned codenames:
 - Beryllium: ``2015.8.0``
 - Boron: ``2016.3.0``
 - Carbon: ``2016.11.0``
-- Nitrogen: ``TBD``
+- Nitrogen: ``2017.7.0``
 - Oxygen: ``TBD``
+- Fluorine: ``TBD``
 
 Example
 -------
@@ -49,10 +52,12 @@ code name and the process repeats itself.
 
 
 Version numbers, Git and salt --version
--------
+---------------------------------------
+
 The salt version, for programmers, is based on `git describe` and presented to end-users with `salt --version`.
 
-Example arguments for `git checkout`
+Example arguments for `git checkout`:
+
   +------------+----------------------------------------------------------------------------+
   |  Argument  |                                           Comment                          |
   +============+============================================================================+
@@ -68,7 +73,8 @@ Example arguments for `git checkout`
 Further reading on `release branch and develop branch 
 <https://docs.saltstack.com/en/latest/topics/development/contributing.html#which-salt-branch>`_.
   
-Influence of the `git checkout` argument on `git describe`
+Influence of the `git checkout` argument on `git describe`:
+
   +------------+----------------------------+-----------------------------------------------+
   | Checkout   | Describe                   |               Comment                         |
   +============+============================+===============================================+
@@ -80,10 +86,9 @@ Influence of the `git checkout` argument on `git describe`
   +------------+----------------------------+-----------------------------------------------+
   | develop    | v2016.11.1-1741-g10d5dec   | Commit of most recent tag in develop          |
   +------------+----------------------------+-----------------------------------------------+
-    
-  
 
-Some details of v2016.11.1-220-g9a1550d (from `git describe` after `git checkout 2016.11`)
+Some details of v2016.11.1-220-g9a1550d (from `git describe` after `git checkout 2016.11`):
+
   +---------------+-------------------------------------------------------------------------+
   |     Part      |                       Comment                                           |
   +===============+=========================================================================+

doc/topics/spm/spm_formula.rst

@@ -11,7 +11,7 @@ describes the package. An example of this file is:
 
     name: apache
     os: RedHat, Debian, Ubuntu, SUSE, FreeBSD
-    os_family: RedHat, Debian, SUSE, FreeBSD
+    os_family: RedHat, Debian, Suse, FreeBSD
     version: 201506
     release: 2
     summary: Formula for installing Apache

doc/topics/ssh/index.rst

@@ -112,7 +112,7 @@ Calling Salt SSH
 
 .. note:: ``salt-ssh`` on systems with Python 3.x
 
-    Salt, before the Nitrogen release, does not support Python 3.x which is the
+    Salt, before the 2017.7.0 release, does not support Python 3.x which is the
     default on for example the popular 16.04 LTS release of Ubuntu. An easy
     workaround for this scenario is to use the ``-r`` option similar to the
     example above:

doc/topics/ssh/roster.rst

@@ -61,6 +61,8 @@ The information which can be stored in a roster ``target`` is the following:
         cmd_umask:   # umask to enforce for the salt-call command. Should be in
                      # octal (so for 0o077 in YAML you would do 0077, or 63)
 
+.. _roster_defaults:
+
 Target Defaults
 ---------------
 
@@ -71,10 +73,10 @@ not need to be passed with commandline arguments.
 .. code-block:: yaml
 
     roster_defaults:
-        user: daniel
-        sudo: True
-        priv: /root/.ssh/id_rsa
-        tty: True
+      user: daniel
+      sudo: True
+      priv: /root/.ssh/id_rsa
+      tty: True
 
 thin_dir
 --------

doc/topics/targeting/nodegroups.rst

@@ -28,7 +28,7 @@ nodegroups. Here's an example nodegroup configuration within
     group2 is matching specific grains. See the :ref:`compound matchers
     <targeting-compound>` documentation for more details.
 
-    As of the Nitrogen release of Salt, group names can also be prepended with
+    As of the 2017.7.0 release of Salt, group names can also be prepended with
     a dash. This brings the usage in line with many other areas of Salt. For
     example:
 

doc/topics/tutorials/firewall.rst

@@ -91,6 +91,50 @@ firewall.
 
    yast2 firewall
 
+
+Windows
+=======
+
+Windows Firewall is the default component of Microsoft Windows that provides
+firewalling and packet filtering. There are many 3rd party firewalls available
+for Windows, some of which use rules from the Windows Firewall. If you are
+experiencing problems see the vendor's specific documentation for opening the
+required ports.
+
+The Windows Firewall can be configured using the Windows Interface or from the
+command line.
+
+**Windows Firewall (interface)**:
+
+1. Open the Windows Firewall Interface by typing ``wf.msc`` at the command
+   prompt or in a run dialog (*Windows Key + R*)
+
+2. Navigate to **Inbound Rules** in the console tree
+
+3. Add a new rule by clicking **New Rule...** in the Actions area
+
+4. Change the Rule Type to **Port**. Click **Next**
+
+5. Set the Protocol to **TCP** and specify local ports **4505-4506**. Click
+   **Next**
+
+6. Set the Action to **Allow the connection**. Click **Next**
+
+7. Apply the rule to **Domain**, **Private**, and **Public**. Click **Next**
+
+8. Give the new rule a Name, ie: **Salt**. You may also add a description. Click
+   **Finish**
+
+**Windows Firewall (command line)**:
+
+The Windows Firewall rule can be created by issuing a single command. Run the
+following command from the command line or a run prompt:
+
+.. code-block:: cmd
+
+    netsh advfirewall firewall add rule name="Salt" dir=in action=allow protocol=TCP localport=4505-4506
+
+
 .. _linux-iptables:
 
 iptables
@@ -188,4 +232,4 @@ be set on the Master:
     ``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
-    the ``salt-master`` to tell it to carry out the execution.
+    the ``salt-master`` to tell it to carry out the execution.

doc/topics/tutorials/gitfs.rst

@@ -329,7 +329,9 @@ configured gitfs remotes):
 * :conf_master:`gitfs_pubkey` (**pygit2 only**, new in 2014.7.0)
 * :conf_master:`gitfs_privkey` (**pygit2 only**, new in 2014.7.0)
 * :conf_master:`gitfs_passphrase` (**pygit2 only**, new in 2014.7.0)
-* :conf_master:`gitfs_refspecs` (new in Nitrogen)
+* :conf_master:`gitfs_refspecs` (new in 2017.7.0)
+* :conf_master:`gitfs_disable_saltenv_mapping` (new in Oxygen)
+* :conf_master:`gitfs_ref_types` (new in Oxygen)
 
 .. note::
     pygit2 only supports disabling SSL verification in versions 0.23.2 and
@@ -355,11 +357,17 @@ tremendous amount of customization. Here's some example usage:
         - root: other/salt
         - mountpoint: salt://other/bar
         - base: salt-base
+        - ref_types:
+          - branch
       - http://foo.com/baz.git:
         - root: salt/states
         - user: joe
         - password: mysupersecretpassword
         - insecure_auth: True
+        - disable_saltenv_mapping: True
+        - saltenv:
+          - foo:
+            - ref: foo
       - http://foo.com/quux.git:
         - all_saltenvs: master
 
@@ -391,18 +399,24 @@ In the example configuration above, the following is true:
    will only serve files from the ``salt/states`` directory (and its
    subdirectories).
 
-3. The first and fourth remotes will have files located under the root of the
+3. The third remote will only serve files from branches, and not from tags or
+   SHAs.
+
+4. The fourth remote will only have two saltenvs available: ``base`` (pointed
+   at ``develop``), and ``foo`` (pointed at ``foo``).
+
+5. The first and fourth remotes will have files located under the root of the
    Salt fileserver namespace (``salt://``). The files from the second remote
    will be located under ``salt://bar``, while the files from the third remote
    will be located under ``salt://other/bar``.
 
-4. The second and third remotes reference the same repository and unique names
+6. The second and third remotes reference the same repository and unique names
    need to be declared for duplicate gitfs remotes.
 
-5. The fourth remote overrides the default behavior of :ref:`not authenticating
+7. The fourth remote overrides the default behavior of :ref:`not authenticating
    to insecure (non-HTTPS) remotes <gitfs-insecure-auth>`.
 
-6. Because ``all_saltenvs`` is configured for the fifth remote, files from the
+8. Because ``all_saltenvs`` is configured for the fifth remote, files from the
    branch/tag ``master`` will appear in every fileserver environment.
 
    .. note::
@@ -471,7 +485,7 @@ Given the above configuration, the following is true:
 Custom Refspecs
 ===============
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 GitFS will by default fetch remote branches and tags. However, sometimes it can
 be useful to fetch custom refs (such as those created for `GitHub pull

doc/topics/windows/windows-package-manager.rst

@@ -141,7 +141,7 @@ packages:
 - 2015.8.0 and later minions: https://github.com/saltstack/salt-winrepo-ng
 - Earlier releases: https://github.com/saltstack/salt-winrepo
 
-By default, these repositories are mirrored to ``/srv/salt/win/repo_ng``
+By default, these repositories are mirrored to ``/srv/salt/win/repo-ng``
 and ``/srv/salt/win/repo``.
 
 This location can be changed in the master config file by setting the

pkg/deb/salt-proxy@.service

@@ -0,0 +1,13 @@
+[Unit]
+Description=salt-proxy service for %i
+Documentation=man:salt-proxy(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html
+After=network.target
+
+[Service]
+ExecStart=/usr/bin/salt-proxy --proxyid=%i
+Type=simple
+Restart=on-failure
+RestartSec=5s
+
+[Install]
+WantedBy=multi-user.target

pkg/rpm/salt-minion

@@ -85,6 +85,7 @@ _get_salt_config_value() {
             \"$SALTCALL\" \
             -c \"$CONFIG_DIR\" \
             --no-color \
+            --skip-grains \
             --local config.get \
             \"$1\" \
         " \
@@ -246,7 +247,7 @@ main() {
     fi
 
     # Check to see if --notrim is a valid netstat option
-    if netstat --notrim -n 2>&1 >/dev/null | grep -q 'unrecognized'; then
+    if ! ( netstat --help 2>&1 | grep -wq '\-\-notrim') ; then
         NS_NOTRIM=''
     fi
 

pkg/rpm/salt-proxy@.service

@@ -0,0 +1 @@
+../salt-proxy@.service

pkg/salt-proxy@.service

@@ -1,5 +1,5 @@
 [Unit]
-Description=salt-proxy service for %I
+Description=salt-proxy service for %i
 Documentation=man:salt-proxy(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html
 After=network.target
 

pkg/suse/salt-api.service

@@ -1,11 +1,11 @@
 [Unit]
 Description=The Salt API
+Documentation=man:salt-api(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html
 After=network.target
 
 [Service]
 User=salt
 Type=simple
-Environment=SHELL=/bin/bash
 LimitNOFILE=8192
 ExecStart=/usr/bin/salt-api
 TimeoutStopSec=3

pkg/suse/salt-common.logrotate

@@ -0,0 +1,25 @@
+/var/log/salt/master {
+	su salt salt
+	weekly
+	missingok
+	rotate 7
+	compress
+	notifempty
+}
+
+/var/log/salt/minion {
+	weekly
+	missingok
+	rotate 7
+	compress
+	notifempty
+}
+
+/var/log/salt/key {
+	su salt salt
+	weekly
+	missingok
+	rotate 7
+	compress
+	notifempty
+}

pkg/suse/salt-master.service

@@ -0,0 +1,13 @@
+[Unit]
+Description=The Salt Master Server
+Documentation=man:salt-master(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html
+After=network.target
+
+[Service]
+LimitNOFILE=16384
+Type=simple
+ExecStart=/usr/bin/salt-master
+TasksMax=infinity
+
+[Install]
+WantedBy=multi-user.target

pkg/suse/salt-minion

@@ -51,8 +51,23 @@ SERVICE=salt-minion
 PROCESS=salt-minion
 
 RETVAL=0
+WATCHDOG_CRON="/etc/cron.d/salt-minion"
+
+set_watchdog() {
+    if [ ! -f $WATCHDOG_CRON ]; then
+        echo -e '* * * * * root /usr/bin/salt-daemon-watcher --with-init\n' > $WATCHDOG_CRON
+        # Kick the watcher for 1 minute immediately, because cron will wake up only afterwards
+        /usr/bin/salt-daemon-watcher --with-init & disown
+    fi
+}
+
+remove_watchdog() {
+    rm $WATCHDOG_CRON 2>/dev/null || true
+    kill -9 $(ps uax | grep [s]alt-daemon-watcher | awk '{print $2}') 2>/dev/null
+}
 
 start() {
+    set_watchdog;
     echo -n $"Starting salt-minion daemon: "
     if [ -f $SUSE_RELEASE ]; then
         startproc -p /var/run/$SERVICE.pid $SALTMINION -d $MINION_ARGS
@@ -80,6 +95,10 @@ start() {
 }
 
 stop() {
+    IS_RESTARTING=$1
+    if [ -z $IS_RESTARTING ]; then
+        remove_watchdog;
+    fi
     echo -n $"Stopping salt-minion daemon: "
     if [ -f $SUSE_RELEASE ]; then
         killproc -TERM $SALTMINION
@@ -101,8 +120,8 @@ stop() {
 }
 
 restart() {
-   stop
-   start
+   stop 1;
+   start;
 }
 
 # See how we were called.

pkg/suse/salt-minion.service.rhel7

@@ -0,0 +1,14 @@
+[Unit]
+Description=The Salt Minion
+After=network.target
+
+[Service]
+Type=simple
+LimitNOFILE=8192
+ExecStart=/usr/bin/salt-minion
+KillMode=process
+Restart=on-failure
+RestartSec=15
+
+[Install]
+WantedBy=multi-user.target

pkg/windows/build_env_2.ps1

@@ -261,17 +261,6 @@ DownloadFileWithProgress $url $file
 # Install
 Start_Process_and_test_exitcode  "$($ini['Settings']['Scripts2Dir'])\pip.exe" "install --no-index --find-links=$($ini['Settings']['DownloadDir']) $file " "pip install PyCrypto"
 
-#==============================================================================
-# Download sitecustomize.py
-#==============================================================================
-Write-Output " ----------------------------------------------------------------"
-Write-Output "   - $script_name :: Download sitecustomize . . ."
-Write-Output " ----------------------------------------------------------------"
-$file = "sitecustomize.py"
-$url  = "$($ini['Settings']['SaltRepo'])/$file"
-$file = "$($ini['Settings']['SitePkgs2Dir'])\$file"
-DownloadFileWithProgress $url $file
-
 #==============================================================================
 # Copy DLLs to Python Directory
 #==============================================================================

pkg/windows/build_pkg.bat

@@ -67,10 +67,13 @@ If not Exist "%PyDir%\python.exe" (
     exit /b 1
 )
 
-Set "CurrDir=%cd%"
-Set "BinDir=%cd%\buildenv\bin"
-Set "InsDir=%cd%\installer"
-Set "PreDir=%cd%\prereqs"
+Set "CurDir=%~dp0"
+Set "BldDir=%CurDir%\buildenv"
+Set "BinDir=%CurDir%\buildenv\bin"
+Set "CnfDir=%CurDir%\buildenv\conf"
+Set "InsDir=%CurDir%\installer"
+Set "PreDir=%CurDir%\prereqs"
+for /f "delims=" %%a in ('git rev-parse --show-toplevel') do @set "SrcDir=%%a"
 
 :: Find the NSIS Installer
 If Exist "C:\Program Files\NSIS\" (
@@ -101,6 +104,15 @@ If Exist "%BinDir%\" (
 xcopy /E /Q "%PyDir%" "%BinDir%\"
 @echo.
 
+:: Copy the default master and minion configs to buildenv\conf
+@echo Copying configs to buildenv\conf...
+@echo ----------------------------------------------------------------------
+@echo xcopy /E /Q "%SrcDir%\conf\master" "%CnfDir%\"
+xcopy /Q "%SrcDir%\conf\master" "%CnfDir%\"
+@echo xcopy /E /Q "%SrcDir%\conf\minion" "%CnfDir%\"
+xcopy /Q "%SrcDir%\conf\minion" "%CnfDir%\"
+@echo.
+
 @echo Copying VCRedist to Prerequisites
 @echo ----------------------------------------------------------------------
 :: Make sure the "prereq" directory exists
@@ -127,12 +139,12 @@ If Defined ProgramFiles(x86) (
 :: Remove the fixed path in .exe files
 @echo Removing fixed path from .exe files
 @echo ----------------------------------------------------------------------
-"%PyDir%\python" "%CurrDir%\portable.py" -f "%BinDir%\Scripts\easy_install.exe"
-"%PyDir%\python" "%CurrDir%\portable.py" -f "%BinDir%\Scripts\easy_install-%PyVerMajor%.%PyVerMinor%.exe"
-"%PyDir%\python" "%CurrDir%\portable.py" -f "%BinDir%\Scripts\pip.exe"
-"%PyDir%\python" "%CurrDir%\portable.py" -f "%BinDir%\Scripts\pip%PyVerMajor%.%PyVerMinor%.exe"
-"%PyDir%\python" "%CurrDir%\portable.py" -f "%BinDir%\Scripts\pip%PyVerMajor%.exe"
-"%PyDir%\python" "%CurrDir%\portable.py" -f "%BinDir%\Scripts\wheel.exe"
+"%PyDir%\python" "%CurDir%\portable.py" -f "%BinDir%\Scripts\easy_install.exe"
+"%PyDir%\python" "%CurDir%\portable.py" -f "%BinDir%\Scripts\easy_install-%PyVerMajor%.%PyVerMinor%.exe"
+"%PyDir%\python" "%CurDir%\portable.py" -f "%BinDir%\Scripts\pip.exe"
+"%PyDir%\python" "%CurDir%\portable.py" -f "%BinDir%\Scripts\pip%PyVerMajor%.%PyVerMinor%.exe"
+"%PyDir%\python" "%CurDir%\portable.py" -f "%BinDir%\Scripts\pip%PyVerMajor%.exe"
+"%PyDir%\python" "%CurDir%\portable.py" -f "%BinDir%\Scripts\wheel.exe"
 @echo.
 
 @echo Cleaning up unused files and directories...
@@ -534,12 +546,6 @@ If Exist "%BinDir%\Lib\site-packages\salt\states\zpool.py"^
 :: Remove Unneeded Components
 If Exist "%BinDir%\Lib\site-packages\salt\cloud"^
     rd /S /Q "%BinDir%\Lib\site-packages\salt\cloud" 1>nul
-If Exist "%BinDir%\Scripts\salt-key*"^
-    del /Q "%BinDir%\Scripts\salt-key*" 1>nul
-If Exist "%BinDir%\Scripts\salt-master*"^
-    del /Q "%BinDir%\Scripts\salt-master*" 1>nul
-If Exist "%BinDir%\Scripts\salt-run*"^
-    del /Q "%BinDir%\Scripts\salt-run*" 1>nul
 If Exist "%BinDir%\Scripts\salt-unity*"^
     del /Q "%BinDir%\Scripts\salt-unity*" 1>nul
 
@@ -547,6 +553,36 @@ If Exist "%BinDir%\Scripts\salt-unity*"^
 
 @echo Building the installer...
 @echo ----------------------------------------------------------------------
+:: Make the Master installer if the nullsoft script exists
+If Exist "%InsDir%\Salt-Setup.nsi"^
+    makensis.exe /DSaltVersion=%Version% /DPythonVersion=%Python% "%InsDir%\Salt-Setup.nsi"
+
+:: Remove files not needed for Salt Minion
+:: salt
+:: salt has to be removed individually (can't wildcard it)
+If Exist "%BinDir%\Scripts\salt"^
+    del /Q "%BinDir%\Scripts\salt" 1>nul
+If Exist "%BinDir%\Scripts\salt.exe"^
+    del /Q "%BinDir%\Scripts\salt.exe" 1>nul
+If Exist "%BldDir%\salt.bat"^
+    del /Q "%BldDir%\salt.bat" 1>nul
+:: salt-key
+If Exist "%BinDir%\Scripts\salt-key*"^
+    del /Q "%BinDir%\Scripts\salt-key*" 1>nul
+If Exist "%BldDir%\salt-key.bat"^
+    del /Q "%BldDir%\salt-key.bat" 1>nul
+:: salt-master
+If Exist "%BinDir%\Scripts\salt-master*"^
+    del /Q "%BinDir%\Scripts\salt-master*" 1>nul
+If Exist "%BldDir%\salt-master.bat"^
+    del /Q "%BldDir%\salt-master.bat" 1>nul
+:: salt-run
+If Exist "%BinDir%\Scripts\salt-run*"^
+    del /Q "%BinDir%\Scripts\salt-run*" 1>nul
+If Exist "%BldDir%\salt-run.bat"^
+    del /Q "%BldDir%\salt-run.bat" 1>nul
+
+:: Make the Salt Minion Installer
 makensis.exe /DSaltVersion=%Version% /DPythonVersion=%Python% "%InsDir%\Salt-Minion-Setup.nsi"
 @echo.
 

pkg/windows/buildenv/conf/minion

@@ -1,402 +0,0 @@
-##### Primary configuration settings #####
-##########################################
-
-ipc_mode: tcp
-
-# Per default the minion will automatically include all config files
-# from minion.d/*.conf (minion.d is a directory in the same directory
-# as the main minion config file).
-#default_include: minion.d/*.conf
-
-# Set the location of the salt master server, if the master server cannot be
-# resolved, then the minion will fail to start.
-# test
-#master: salt
-
-# Set the number of seconds to wait before attempting to resolve
-# the master hostname if name resolution fails. Defaults to 30 seconds.
-# Set to zero if the minion should shutdown and not retry.
-# retry_dns: 30
-
-# Set the port used by the master reply and authentication server
-#master_port: 4506
-
-# The user to run salt
-#user: root
-
-# Specify the location of the daemon process ID file
-#pidfile: /var/run/salt-minion.pid
-
-# The root directory prepended to these options: pki_dir, cachedir, log_file,
-# sock_dir, pidfile.
-root_dir: c:\salt
-
-# The directory to store the pki information in
-#pki_dir: /etc/salt/pki/minion
-pki_dir: /conf/pki/minion
-
-# Explicitly declare the id for this minion to use, if left commented the id
-# will be the hostname as returned by the python call: socket.getfqdn()
-# Since salt uses detached ids it is possible to run multiple minions on the
-# same machine but with different ids, this can be useful for salt compute
-# clusters.
-#id:
-
-# Append a domain to a hostname in the event that it does not exist.  This is
-# useful for systems where socket.getfqdn() does not actually result in a
-# FQDN (for instance, Solaris).
-#append_domain:
-
-# Custom static grains for this minion can be specified here and used in SLS
-# files just like all other grains. This example sets 4 custom grains, with
-# the 'roles' grain having two values that can be matched against:
-#grains:
-#  roles:
-#    - webserver
-#    - memcache
-#  deployment: datacenter4
-#  cabinet: 13
-#  cab_u: 14-15
-
-# Where cache data goes
-#cachedir: /var/cache/salt/minion
-
-# Verify and set permissions on configuration directories at startup
-#verify_env: True
-
-# The minion can locally cache the return data from jobs sent to it, this
-# can be a good way to keep track of jobs the minion has executed
-# (on the minion side). By default this feature is disabled, to enable
-# set cache_jobs to True
-#cache_jobs: False
-
-# set the directory used to hold unix sockets
-#sock_dir: /var/run/salt/minion
-
-# Backup files that are replaced by file.managed and file.recurse under
-# 'cachedir'/file_backups relative to their original location and appended
-# with a timestamp. The only valid setting is "minion". Disabled by default.
-#
-# Alternatively this can be specified for each file in state files:
-#
-# /etc/ssh/sshd_config:
-#   file.managed:
-#     - source: salt://ssh/sshd_config
-#       - backup: minion
-#
-#backup_mode: minion
-
-# When waiting for a master to accept the minion's public key, salt will
-# continuously attempt to reconnect until successful. This is the time, in
-# seconds, between those reconnection attempts.
-#acceptance_wait_time: 10
-
-# If this is set, the time between reconnection attempts will increase by
-# acceptance_wait_time seconds per iteration, up to this maximum. If this
-# is not set, the time between reconnection attempts will stay constant.
-#acceptance_wait_time_max: None
-
-# Windows platforms lack posix IPC and must rely on slower TCP based inter-
-# process communications. Set ipc_mode to 'tcp' on such systems
-#ipc_mode: ipc
-#
-# Overwrite the default tcp ports used by the minion when in tcp mode
-#tcp_pub_port: 4510
-#tcp_pull_port: 4511
-
-# The minion can include configuration from other files. To enable this,
-# pass a list of paths to this option. The paths can be either relative or
-# absolute; if relative, they are considered to be relative to the directory
-# the main minion configuration file lives in (this file). Paths can make use
-# of shell-style globbing. If no files are matched by a path passed to this
-# option then the minion will log a warning message.
-#
-#
-# Include a config file from some other path:
-# include: /etc/salt/extra_config
-#
-# Include config from several files and directories:
-# include:
-#  - /etc/salt/extra_config
-#  - /etc/roles/webserver
-
-#####   Minion module management     #####
-##########################################
-# Disable specific modules. This allows the admin to limit the level of
-# access the master has to the minion
-#disable_modules: [cmd,test]
-#disable_returners: []
-#
-# Modules can be loaded from arbitrary paths. This enables the easy deployment
-# of third party modules. Modules for returners and minions can be loaded.
-# Specify a list of extra directories to search for minion modules and
-# returners. These paths must be fully qualified!
-#module_dirs: []
-#returner_dirs: []
-#states_dirs: []
-#render_dirs: []
-#
-# A module provider can be statically overwritten or extended for the minion
-# via the providers option, in this case the default module will be
-# overwritten by the specified module. In this example the pkg module will
-# be provided by the yumpkg5 module instead of the system default.
-#
-# providers:
-#   pkg: yumpkg5
-#
-# Enable Cython modules searching and loading. (Default: False)
-#cython_enable: False
-#
-
-#####    State Management Settings    #####
-###########################################
-# The state management system executes all of the state templates on the minion
-# to enable more granular control of system state management. The type of
-# template and serialization used for state management needs to be configured
-# on the minion, the default renderer is yaml_jinja. This is a yaml file
-# rendered from a jinja template, the available options are:
-# yaml_jinja
-# yaml_mako
-# yaml_wempy
-# json_jinja
-# json_mako
-# json_wempy
-#
-#renderer: yaml_jinja
-#
-# The failhard option tells the minions to stop immediately after the first
-# failure detected in the state execution, defaults to False
-#failhard: False
-#
-# autoload_dynamic_modules Turns on automatic loading of modules found in the
-# environments on the master. This is turned on by default, to turn of
-# autoloading modules when states run set this value to False
-#autoload_dynamic_modules: True
-#
-# clean_dynamic_modules keeps the dynamic modules on the minion in sync with
-# the dynamic modules on the master, this means that if a dynamic module is
-# not on the master it will be deleted from the minion. By default this is
-# enabled and can be disabled by changing this value to False
-#clean_dynamic_modules: True
-#
-# Normally the minion is not isolated to any single environment on the master
-# when running states, but the environment can be isolated on the minion side
-# by statically setting it. Remember that the recommended way to manage
-# environments is to isolate via the top file.
-#environment: None
-#
-# If using the local file directory, then the state top file name needs to be
-# defined, by default this is top.sls.
-#state_top: top.sls
-#
-# Run states when the minion daemon starts. To enable, set startup_states to:
-# 'highstate' -- Execute state.highstate
-# 'sls' -- Read in the sls_list option and execute the named sls files
-# 'top' -- Read top_file option and execute based on that file on the Master
-#startup_states: ''
-#
-# list of states to run when the minion starts up if startup_states is 'sls'
-#sls_list:
-#  - edit.vim
-#  - hyper
-#
-# top file to execute if startup_states is 'top'
-#top_file: ''
-
-#####     File Directory Settings    #####
-##########################################
-# The Salt Minion can redirect all file server operations to a local directory,
-# this allows for the same state tree that is on the master to be used if
-# copied completely onto the minion. This is a literal copy of the settings on
-# the master but used to reference a local directory on the minion.
-
-# Set the file client, the client defaults to looking on the master server for
-# files, but can be directed to look at the local file directory setting
-# defined below by setting it to local.
-#file_client: remote
-
-# The file directory works on environments passed to the minion, each environment
-# can have multiple root directories, the subdirectories in the multiple file
-# roots cannot match, otherwise the downloaded files will not be able to be
-# reliably ensured. A base environment is required to house the top file.
-# Example:
-# file_roots:
-#   base:
-#     - /srv/salt/
-#   dev:
-#     - /srv/salt/dev/services
-#     - /srv/salt/dev/states
-#   prod:
-#     - /srv/salt/prod/services
-#     - /srv/salt/prod/states
-#
-# Default:
-#file_roots:
-#  base:
-#    - /srv/salt
-
-# The hash_type is the hash to use when discovering the hash of a file in
-# the minion directory, the default is md5, but sha1, sha224, sha256, sha384
-# and sha512 are also supported.
-#hash_type: md5
-
-# The Salt pillar is searched for locally if file_client is set to local. If
-# this is the case, and pillar data is defined, then the pillar_roots need to
-# also be configured on the minion:
-#pillar_roots:
-#  base:
-#    - /srv/pillar
-
-######        Security settings       #####
-###########################################
-# Enable "open mode", this mode still maintains encryption, but turns off
-# authentication, this is only intended for highly secure environments or for
-# the situation where your keys end up in a bad state. If you run in open mode
-# you do so at your own risk!
-#open_mode: False
-
-# Enable permissive access to the salt keys.  This allows you to run the
-# master or minion as root, but have a non-root group be given access to
-# your pki_dir.  To make the access explicit, root must belong to the group
-# you've given access to. This is potentially quite insecure.
-#permissive_pki_access: False
-
-# The state_verbose and state_output settings can be used to change the way
-# state system data is printed to the display. By default all data is printed.
-# The state_verbose setting can be set to True or False, when set to False
-# all data that has a result of True and no changes will be suppressed.
-#state_verbose: True
-#
-# The state_output setting changes if the output is the full multi line
-# output for each changed state if set to 'full', but if set to 'terse'
-# the output will be shortened to a single line.
-#state_output: full
-#
-# Fingerprint of the master public key to double verify the master is valid,
-# the master fingerprint can be found by running "salt-key -F master" on the
-# salt master.
-#master_finger: ''
-
-######         Thread settings        #####
-###########################################
-# Disable multiprocessing support, by default when a minion receives a
-# publication a new process is spawned and the command is executed therein.
-# multiprocessing: True
-
-######         Logging settings       #####
-###########################################
-# The location of the minion log file.
-# This can be a path for the log file, or, this can be, since 0.11.0, a system
-# logger address, for example:
-#	tcp://localhost:514/LOG_USER
-#	tcp://localhost/LOG_DAEMON
-#	udp://localhost:5145/LOG_KERN
-#	udp://localhost
-#	file:///dev/log
-#	file:///dev/log/LOG_SYSLOG
-#	file:///dev/log/LOG_DAEMON
-#
-# The above examples are self explanatory, but:
-#	<file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
-#
-# Make sure you have a properly configured syslog or you won't get any warnings
-#
-#log_file: /var/log/salt/minion
-#
-#
-# The level of messages to send to the console.
-# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
-# Default: 'warning'
-#log_level: warning
-#
-# The level of messages to send to the log file.
-# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
-# Default: 'warning'
-#log_level_logfile:
-#
-# The date and time format used in log messages. Allowed date/time formatting
-# can be seen on http://docs.python.org/library/time.html#time.strftime
-#log_datefmt: '%H:%M:%S'
-#log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
-#
-# The format of the console logging messages. Allowed formatting options can
-# be seen on http://docs.python.org/library/logging.html#logrecord-attributes
-#log_fmt_console: '[%(levelname)-8s] %(message)s'
-#log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'
-#
-# Logger levels can be used to tweak specific loggers logging levels.
-# For example, if you want to have the salt library at the 'warning' level,
-# but you still wish to have 'salt.modules' at the 'debug' level:
-#   log_granular_levels: {
-#     'salt': 'warning',
-#     'salt.modules': 'debug'
-#   }
-#
-#log_granular_levels: {}
-
-######      Module configuration      #####
-###########################################
-# Salt allows for modules to be passed arbitrary configuration data, any data
-# passed here in valid yaml format will be passed on to the salt minion modules
-# for use. It is STRONGLY recommended that a naming convention be used in which
-# the module name is followed by a . and then the value. Also, all top level
-# data must be applied via the yaml dict construct, some examples:
-#
-# You can specify that all modules should run in test mode:
-#test: True
-#
-# A simple value for the test module:
-#test.foo: foo
-#
-# A list for the test module:
-#test.bar: [baz,quo]
-#
-# A dict for the test module:
-#test.baz: {spam: sausage, cheese: bread}
-
-
-######      Update settings          ######
-###########################################
-# Using the features in Esky, a salt minion can both run as a frozen app and
-# be updated on the fly. These options control how the update process
-# (saltutil.update()) behaves.
-#
-# The url for finding and downloading updates. Disabled by default.
-#update_url: False
-#
-# The list of services to restart after a successful update. Empty by default.
-#update_restart_services: []
-
-
-######      Keepalive settings        ######
-############################################
-# ZeroMQ now includes support for configuring SO_KEEPALIVE if supported by
-# the OS. If connections between the minion and the master pass through
-# a state tracking device such as a firewall or VPN gateway, there is
-# the risk that it could tear down the connection the master and minion
-# without informing either party that their connection has been taken away.
-# Enabling TCP Keepalives prevents this from happening.
-#
-# Overall state of TCP Keepalives, enable (1 or True), disable (0 or False)
-# or leave to the OS defaults (-1), on Linux, typically disabled. Default True, enabled.
-#tcp_keepalive: True
-#
-# How long before the first keepalive should be sent in seconds. Default 300
-# to send the first keepalive after 5 minutes, OS default (-1) is typically 7200 seconds
-# on Linux see /proc/sys/net/ipv4/tcp_keepalive_time.
-#tcp_keepalive_idle: 300
-#
-# How many lost probes are needed to consider the connection lost. Default -1
-# to use OS defaults, typically 9 on Linux, see /proc/sys/net/ipv4/tcp_keepalive_probes.
-#tcp_keepalive_cnt: -1
-#
-# How often, in seconds, to send keepalives after the first one. Default -1 to
-# use OS defaults, typically 75 seconds on Linux, see
-# /proc/sys/net/ipv4/tcp_keepalive_intvl.
-#tcp_keepalive_intvl: -1
-
-
-######      Windows Software settings ######
-############################################
-# Location of the repository cache file on the master
-# win_repo_cachefile: 'salt://win/repo/winrepo.p'

pkg/windows/buildenv/salt-call.bat

@@ -8,4 +8,6 @@ Set SaltDir=%SaltDir:~0,-1%
 Set Python=%SaltDir%\bin\python.exe
 Set Script=%SaltDir%\bin\Scripts\salt-call
 
+:: Launch Script
 "%Python%" "%Script%" %*
+

pkg/windows/buildenv/salt-cp.bat

@@ -8,4 +8,6 @@ Set SaltDir=%SaltDir:~0,-1%
 Set Python=%SaltDir%\bin\python.exe
 Set Script=%SaltDir%\bin\Scripts\salt-cp
 
+:: Launch Script
 "%Python%" "%Script%" %*
+

pkg/windows/buildenv/salt-key.bat

@@ -0,0 +1,13 @@
+@ echo off
+:: Script for invoking salt-key
+:: Accepts all parameters that salt-key accepts
+
+:: Define Variables
+Set SaltDir=%~dp0
+Set SaltDir=%SaltDir:~0,-1%
+Set Python=%SaltDir%\bin\python.exe
+Set Script=%SaltDir%\bin\Scripts\salt-key
+
+:: Launch Script
+"%Python%" "%Script%" %*
+

pkg/windows/buildenv/salt-master.bat

@@ -0,0 +1,13 @@
+@ echo off
+:: Script for starting the Salt-Master
+:: Accepts all parameters that Salt-Master accepts
+
+:: Define Variables
+Set SaltDir=%~dp0
+Set SaltDir=%SaltDir:~0,-1%
+Set Python=%SaltDir%\bin\python.exe
+Set Script=%SaltDir%\bin\Scripts\salt-master
+
+:: Launch Script
+"%Python%" "%Script%" %*
+

pkg/windows/buildenv/salt-minion-debug.bat

@@ -8,6 +8,9 @@ Set SaltDir=%SaltDir:~0,-1%
 Set Python=%SaltDir%\bin\python.exe
 Set Script=%SaltDir%\bin\Scripts\salt-minion
 
+:: Stop the Salt Minion service
 net stop salt-minion
 
+:: Launch Script
 "%Python%" "%Script%" -l debug
+

pkg/windows/buildenv/salt-minion-start-service.bat

@@ -1 +1,2 @@
-net start salt-minion
+:: Start the Salt Minion service
+net start salt-minion

pkg/windows/buildenv/salt-minion.bat

@@ -8,4 +8,6 @@ Set SaltDir=%SaltDir:~0,-1%
 Set Python=%SaltDir%\bin\python.exe
 Set Script=%SaltDir%\bin\Scripts\salt-minion
 
+:: Launch Script
 "%Python%" "%Script%" %*
+

pkg/windows/buildenv/salt-run.bat

@@ -0,0 +1,13 @@
+@ echo off
+:: Script for invoking salt-run
+:: Accepts all parameters that salt-run accepts
+
+:: Define Variables
+Set SaltDir=%~dp0
+Set SaltDir=%SaltDir:~0,-1%
+Set Python=%SaltDir%\bin\python.exe
+Set Script=%SaltDir%\bin\Scripts\salt-run
+
+:: Launch Script
+"%Python%" "%Script%" %*
+

pkg/windows/buildenv/salt.bat

@@ -0,0 +1,13 @@
+@ echo off
+:: Script for starting the Salt CLI
+:: Accepts all parameters that Salt CLI accepts
+
+:: Define Variables
+Set SaltDir=%~dp0
+Set SaltDir=%SaltDir:~0,-1%
+Set Python=%SaltDir%\bin\python.exe
+Set Script=%SaltDir%\bin\Scripts\salt
+
+:: Launch Script
+"%Python%" "%Script%" %*
+

pkg/windows/req_2.txt

@@ -2,4 +2,3 @@
 
 lxml==3.6.0
 pypiwin32==219
-win-unicode-console==0.5

requirements/dev_python27.txt

@@ -6,7 +6,6 @@ boto>=2.32.1
 boto3>=1.2.1
 moto>=0.3.6
 SaltPyLint>=v2017.3.6
-GitPython>=0.3
 pytest
 git+https://github.com/eisensheng/pytest-catchlog.git@develop#egg=Pytest-catchlog
 git+https://github.com/saltstack/pytest-salt.git@master#egg=pytest-salt

requirements/dev_python34.txt

@@ -11,6 +11,5 @@ moto>=0.3.6
 # prevent it from being successfully installed (at least on Python 3.4).
 httpretty
 SaltPyLint>=v2017.2.29
-GitPython>=0.3
 pytest
 git+https://github.com/saltstack/pytest-salt.git@master#egg=pytest-salt

salt/auth/__init__.py

@@ -31,6 +31,7 @@ import salt.config
 import salt.loader
 import salt.transport.client
 import salt.utils
+import salt.utils.files
 import salt.utils.minions
 import salt.payload
 
@@ -227,8 +228,9 @@ class LoadAuth(object):
             tdata['groups'] = load['groups']
 
         try:
-            with salt.utils.fopen(t_path, 'w+b') as fp_:
-                fp_.write(self.serial.dumps(tdata))
+            with salt.utils.files.set_umask(0o177):
+                with salt.utils.fopen(t_path, 'w+b') as fp_:
+                    fp_.write(self.serial.dumps(tdata))
         except (IOError, OSError):
             log.warning('Authentication failure: can not write token file "{0}".'.format(t_path))
             return {}
@@ -666,14 +668,12 @@ class Resolver(object):
         tdata = self._send_token_request(load)
         if 'token' not in tdata:
             return tdata
-        oldmask = os.umask(0o177)
         try:
-            with salt.utils.fopen(self.opts['token_file'], 'w+') as fp_:
-                fp_.write(tdata['token'])
+            with salt.utils.files.set_umask(0o177):
+                with salt.utils.fopen(self.opts['token_file'], 'w+') as fp_:
+                    fp_.write(tdata['token'])
         except (IOError, OSError):
             pass
-        finally:
-            os.umask(oldmask)
         return tdata
 
     def mk_token(self, load):

salt/beacons/__init__.py

@@ -54,9 +54,7 @@ class Beacon(object):
                 current_beacon_config = {}
                 list(map(current_beacon_config.update, config[mod]))
             elif isinstance(config[mod], dict):
-                raise CommandExecutionError(
-                    'Beacon configuration should be a list instead of a dictionary.'
-                )
+                current_beacon_config = config[mod]
 
             if 'enabled' in current_beacon_config:
                 if not current_beacon_config['enabled']:

salt/beacons/log.py

@@ -2,7 +2,7 @@
 '''
 Beacon to fire events at specific log messages.
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 '''
 

salt/cache/__init__.py

@@ -77,6 +77,7 @@ class Cache(object):
         self.serial = Serial(opts)
         self._modules = None
         self._kwargs = kwargs
+        self._kwargs['cachedir'] = self.cachedir
 
     def __lazy_init(self):
         self._modules = salt.loader.cache(self.opts, self.serial)

salt/cache/redis_cache.py

@@ -5,7 +5,7 @@ Redis
 
 Redis plugin for the Salt caching subsystem.
 
-.. versionadded:: Nitrogen
+.. versionadded:: 2017.7.0
 
 As Redis provides a simple mechanism for very fast key-value store,
 in order to privde the necessary features for the Salt