Merge branch 'develop' into saltstackGH-51784

.gitignore

@@ -96,6 +96,9 @@ tests/integration/cloud/providers/pki/minions
 # Ignore tox virtualenvs
 /.tox/
 
+# Ignore nox virtualenvs
+/.nox/
+
 # Kitchen tests files
 .kitchen.local.yml
 .kitchen/

Gemfile

@@ -3,7 +3,7 @@
 source 'https://rubygems.org'
 
 gem 'test-kitchen', '~>1.23.3'
-gem 'kitchen-salt', '~>0.4.1'
+gem 'kitchen-salt', :git => 'https://github.com/s0undt3ch/kitchen-salt.git', :branch => 'features/nox'
 gem 'kitchen-sync'
 gem 'git'
 
@@ -13,7 +13,8 @@ end
 
 group :windows do
   gem 'winrm', '~>2.0'
-  gem 'winrm-fs', '~>1.3.1'
+#  gem 'winrm-fs', '~>1.3.1'
+  gem 'winrm-fs', :git => 'https://github.com/s0undt3ch/winrm-fs.git', :branch => 'hotfix/saltstack-ci'
 end
 
 group :ec2 do

HACKING.rst

@@ -250,9 +250,9 @@ If it is less than 2047, you should increase it with::
 Running the tests
 ~~~~~~~~~~~~~~~~~
 
-For running tests, you'll also need to install ``requirements/dev_python2x.txt``::
+For running tests, you'll also need to install ``requirements/dev_python27.txt``::
 
-    pip install -r requirements/dev_python2x.txt
+    pip install -r requirements/dev_python27.txt
 
 Finally you use setup.py to run the tests with the following command::
 

doc/conf.py

@@ -255,9 +255,9 @@ def inner(fn, *iargs, **ikwargs):  # pylint: disable=unused-argument
 project = 'Salt'
 
 version = salt.version.__version__
-latest_release = '2018.3.3'  # latest release
-previous_release = '2017.7.8'  # latest release from previous branch
-previous_release_dir = '2017.7'  # path on web server for previous branch
+latest_release = '2019.2.0'  # latest release
+previous_release = '2018.3.4'  # latest release from previous branch
+previous_release_dir = '2018.3'  # path on web server for previous branch
 next_release = ''  # next release
 next_release_dir = ''  # path on web server for next release branch
 

doc/ref/configuration/master.rst

@@ -2645,6 +2645,8 @@ 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.
 
+As of 2018.3.5 and 2019.2.1, it is possible to have `__env__` as a catch-all environment.
+
 Example:
 
 .. code-block:: yaml
@@ -2658,6 +2660,8 @@ Example:
       prod:
         - /srv/salt/prod/services
         - /srv/salt/prod/states
+      __env__:
+        - /srv/salt/default
 
 .. note::
     For masterless Salt, this parameter must be specified in the minion config

doc/ref/configuration/minion.rst

@@ -900,6 +900,23 @@ A value of 10 minutes is a reasonable default.
 
     grains_refresh_every: 0
 
+.. conf_minion:: metadata_server_grains
+
+``metadata_server_grains``
+--------------------------
+
+.. versionadded:: 2017.7.0
+
+Default: ``False``
+
+Set this option to enable gathering of cloud metadata from
+``http://169.254.169.254/latest`` for use in grains (see :py:mod:`here
+<salt.grains.metadata>` for more information).
+
+.. code-block:: yaml
+
+    metadata_server_grains: True
+
 .. conf_minion:: fibre_channel_grains
 
 ``fibre_channel_grains``

doc/ref/engines/all/index.rst

@@ -11,7 +11,6 @@ engine modules
     :template: autosummary.rst.tmpl
 
     docker_events
-    hipchat
     http_logstash
     ircbot
     junos_syslog

doc/ref/states/requisites.rst

@@ -121,6 +121,22 @@ so either of the following versions for "Extract server package" is correct:
         - onchanges:
           - file: /usr/local/share/myapp.tar.xz
 
+Glog matching in requisites
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. versionadded:: 0.9.8
+
+Glob matching is supported in requisites. This is mostly useful for file
+changes. In the example below, a change in ``/etc/apache2/httpd.conf`` or
+``/etc/apache2/sites-available/default.conf`` will reload/restart the service:
+
+.. code-block:: yaml
+
+    apache2:
+      service.running:
+        - watch:
+          - file: /etc/apache2/*
+
 Omitting state module in requisites
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -832,6 +848,22 @@ For example:
 In the above case, ``some_check`` will be run prior to _each_ name -- once for
 ``first_deploy_cmd`` and a second time for ``second_deploy_cmd``.
 
+.. versionchanged:: Neon
+    The ``unless`` requisite can take a module as a dictionary field in unless.
+    The dictionary must contain an argument ``fun`` which is the module that is
+    being run, and everything else passed in will be kwargs passed to the module
+    function.
+
+    .. code-block:: yaml
+
+        install apache on debian based distros:
+          cmd.run:
+            - name: make install
+            - cwd: /path/to/dir/whatever-2.1.5/
+            - unless:
+              - fun: file.file_exists
+                path: /usr/local/bin/whatever
+
 .. _onlyif-requisite:
 
 onlyif
@@ -872,6 +904,28 @@ concept of ``True`` and ``False``.
 The above example ensures that the stop_volume and delete modules only run
 if the gluster commands return a 0 ret value.
 
+.. versionchanged:: Neon
+    The ``onlyif`` requisite can take a module as a dictionary field in onlyif.
+    The dictionary must contain an argument ``fun`` which is the module that is
+    being run, and everything else passed in will be kwargs passed to the module
+    function.
+
+    .. code-block:: yaml
+
+        install apache on redhat based distros:
+          pkg.latest:
+            - name: httpd
+            - onlyif:
+              - fun: match.grain
+                tgt: 'os_family: RedHat'
+
+        install apache on debian based distros:
+          pkg.latest:
+            - name: apache2
+            - onlyif:
+              - fun: match.grain
+                tgt: 'os_family: Debian'
+
 runas
 ~~~~~
 

doc/topics/cloud/azure.rst

@@ -520,7 +520,7 @@ services. For more information on service certificates, see the following link:
 
 * `Manage Certificates`__
 
-.. __: https://msdn.microsoft.com/en-us/library/azure/gg981929.aspx
+.. __: https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-certs-create
 
 The following functions are available.
 

doc/topics/cloud/cloudstack.rst

@@ -22,7 +22,7 @@ Using Salt for CloudStack, requires an ``API key`` and a ``secret key`` along wi
 
     exoscale:
       driver: cloudstack
-      host: api.exoscale.ch
+      host: api.exoscale.com
       path: /compute
       apikey: EXOAPIKEY
       secretkey: EXOSECRETKEYINYOURACCOUNT
@@ -48,9 +48,10 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or in the
 
     exoscale-ubuntu:
       provider: exoscale-config
-      image: Ubuntu 16.04 
+      image: Linux Ubuntu 18.04
       size: Small
       location: ch-gva-2
+      ssh_username: ubuntu
 
 Locations can be obtained using the ``--list-locations`` option for the ``salt-cloud``
 command:

doc/topics/community/index.rst

@@ -72,10 +72,10 @@ A few examples of salt states from the community:
 * https://github.com/bclermont/states
 * https://github.com/pcrews/salt-data
 
-Follow on ohloh
-===============
+Follow on Open Hub
+==================
 
-https://www.ohloh.net/p/salt
+https://www.openhub.net/p/salt
 
 Other community links
 =====================
@@ -87,6 +87,7 @@ Other community links
 - `Facebook <https://www.facebook.com/SaltStack>`_
 - `Twitter <https://twitter.com/SaltStackInc>`_
 - `Wikipedia page <http://en.wikipedia.org/wiki/Salt_(software)>`_
+- `Stack Overflow <https://stackoverflow.com/questions/tagged/salt-stack>`_
 
 Hack the Source
 ===============

doc/topics/development/modules/developing.rst

@@ -237,3 +237,17 @@ Defined in: State
 __sdb__
 -------
 Defined in: SDB
+
+
+Additional Globals
+==================
+
+Defined for: Runners, Execution Modules, Wheels
+
+* ``__jid__``: The job ID
+* ``__user__``: The user
+* ``__tag__``: The jid tag
+* ``__jid_event__``: A :py:class:`salt.utils.event.NamespacedEvent`.
+
+:py:class:`NamespacedEvent <salt.utils.event.NamespacedEvent>` defines a single
+method :py:meth:`fire_event <salt.utils.event.NamespacedEvent.fire_event>`, that takes data and tag. The :ref:`Runner docs <runners>` has examples.

doc/topics/development/modules/index.rst

@@ -55,7 +55,7 @@ prepended by underscore, such as:
 Modules must be synced before they can be used. This can happen a few ways,
 discussed below.
 
-.. note:
+.. note::
     Using saltenvs besides ``base`` may not work in all contexts.
 
 Sync Via States
@@ -73,7 +73,7 @@ Sync Via the saltutil Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The saltutil module has a number of functions that can be used to sync all
-or specific dynamic modules. The ``saltutil.sync_*`` 
+or specific dynamic modules. The ``saltutil.sync_*``
 :py:mod:`execution functions <salt.modules.saltutil>` and
 :py:mod:`runner functions <salt.runners.saltutil>` can be used to sync modules
 to minions and the master, respectively.
@@ -110,7 +110,7 @@ This is done via setuptools entry points:
     )
 
 Note that these are not synced from the Salt Master to the Minions. They must be
-installed indepdendently on each Minion.
+installed independently on each Minion.
 
 Module Types
 ============
@@ -129,10 +129,12 @@ Cache        ``salt.cache`` (:ref:`index <all-salt.cache>`)                   ``
 Cloud        ``salt.cloud.clouds`` (:ref:`index <all-salt.clouds>`)           ``clouds``                ``cloud_dirs``
 Engine       ``salt.engines`` (:ref:`index <engines>`)                        ``engines``               ``engines_dirs``
 Execution    ``salt.modules`` (:ref:`index <all-salt.modules>`)               ``modules``               ``module_dirs``
-Executor     ``salt.executors`` (:ref:`index <all-salt.executors>`)           ``executors`` [#no-fs]_   ``executor_dirs``
+Executor     ``salt.executors`` (:ref:`index <all-salt.executors>`)           ``executors``             ``executor_dirs``
 File Server  ``salt.fileserver`` (:ref:`index <file-server>`)                 ``fileserver``            ``fileserver_dirs``
 Grain        ``salt.grains`` (:ref:`index <all-salt.grains>`)                 ``grains``                ``grains_dirs``
 Log Handler  ``salt.log.handlers`` (:ref:`index <external-logging-handlers>`) ``log_handlers``          ``log_handlers_dirs``
+Matcher      ``salt.matchers``                                                ``matchers``              ``matchers_dirs``
+Metaproxy    ``salt.metaproxy``                                               ``metaproxy`` [#no-fs]_   ``metaproxy_dirs``
 Net API      ``salt.netapi`` (:ref:`index <all-netapi-modules>`)              ``netapi`` [#no-fs]_      ``netapi_dirs``
 Outputter    ``salt.output`` (:ref:`index <all-salt.output>`)                 ``output``                ``outputter_dirs``
 Pillar       ``salt.pillar`` (:ref:`index <all-salt.pillars>`)                ``pillar``                ``pillar_dirs``
@@ -157,7 +159,7 @@ Wheel        ``salt.wheels`` (:ref:`index <all-salt.wheel>`)                  ``
 
 .. [#no-fs] These modules cannot be loaded from the Salt File Server.
 
-.. note:
+.. note::
     While it is possible to import modules directly with the import statement,
     it is strongly recommended that the appropriate
     :ref:`dunder dictionary <dunder-dictionaries>` is used to access them
@@ -179,7 +181,7 @@ Beacon
 
 * :ref:`Writing Beacons <writing-beacons>`
 
-Beacons are polled by the Salt event loop to monitor non-salt processes. See 
+Beacons are polled by the Salt event loop to monitor non-salt processes. See
 :ref:`Beacons <beacons>` for more information about the beacon system.
 
 Cache
@@ -258,6 +260,19 @@ Log Handler
 Log handlers allows the logs from salt (master or minion) to be sent to log
 aggregation systems.
 
+Matcher
+-------
+
+Matcher modules are used to define the :ref:`minion targeting expressions <targeting>`.
+For now, it is only possible to override the :ref:`existing matchers <matchers>`
+(the required CLI plumbing for custom matchers is not implemented yet).
+
+Metaproxy
+---------
+
+Metaproxy is an abstraction layer above the existing proxy minion. It enables
+adding different types of proxy minions that can still load existing proxymodules.
+
 Net API
 -------
 
@@ -382,7 +397,7 @@ Tokens
 Token stores for :ref:`External Authentication <acl-eauth>`. See the
 :py:mod:`salt.tokens` docstring for details.
 
-.. note:
+.. note::
     The runner to load tokens modules is
     :py:func:`saltutil.sync_eauth_tokens <salt.runners.saltutil.sync_eauth_tokens>`.
 
@@ -395,7 +410,7 @@ the state system.
 Util
 ----
 
-Just utility modules to use with other modules via ``__utils__`` (see 
+Just utility modules to use with other modules via ``__utils__`` (see
 :ref:`Dunder Dictionaries <dunder-dictionaries>`).
 
 Wheel

doc/topics/installation/nxos.rst

@@ -307,7 +307,7 @@ Example:
 
 Start the Minon in the Guestshell and accept the key on the SaltStack Master.
 
-  ``[root@guestshell ~]# salt-minion -d``
+  ``[root@guestshell ~]# systemctl start salt-minion``
 
 .. code:: bash
 
@@ -385,33 +385,6 @@ Next, enable the SaltStack Minion systemd service (the ``enable`` command adds i
   systemctl start salt-minion
 
 
-GuestShell NAPALM Installation
-==============================
-
-This section documents installing NAPALM in the ``guestshell`` after the Saltstack Minion has already been installed.
-
-Before NAPALM can be successfully installed a few packages need to be installed or updated.
-
-.. code:: bash
-
-  pip uninstall setuptools
-  pip install setuptools
-  python -m pip install pip==9.0.3
-  pip install napalm
-  pip install napalm-nxos
-
-Tell the SaltStack Minion to use NAPALM for NXOS.  Add the following to the minion configuration file (typically /etc/salt/minion):
-
-.. code:: yaml
-
-  napalm:
-    driver: nxos
-
-A ``username`` can be optionally provided if necessary.  However, by default, the username is 'admin'.  A ``password`` is not necessary as requests to NXAPI are made over the Unix Domain Socket (UDS) inside the ``guestshell``.  
-
-Once the above packages have installed successfully and configuration changes have been made, restart the Saltstack Minion inside the ``guestshell``.
-
-
 References
 ==========