Merge pull request #32932 from rallytime/merge-2016.3

[2016.3] Merge forward from 2015.8 to 2016.3

doc/_themes/saltstack2/layout.html

@@ -243,11 +243,7 @@
 
                 {% if on_saltstack %}
 
-                {% if [True, False]|random %}
-                <a href="http://saltconf.com/register" target="_blank"><img class="nolightbox sidebar-banner center" src="{{ pathto('_static/images/banner-saltconf.png', 1) }}"/></a>
-                {% else %}
                 <a href="http://saltstack.com/support" target="_blank"><img class="nolightbox sidebar-banner center" src="{{ pathto('_static/images/banner-support.png', 1) }}"/></a>
-                {% endif %}
 
 
                 {% if build_type=="next" %}

doc/ref/file_server/index.rst

@@ -111,26 +111,27 @@ get_file:
     # salt '*' cp.get_dir salt://etc/{{pillar.webserver}} /etc gzip=5 template=jinja
 
 
-File Server Client API
+File Server Client Instance
-----------------------
+---------------------------
 
-A client API is available which allows for modules and applications to be
+A client instance is available which allows for modules and applications to be
 written which make use of the Salt file server.
 
 The file server uses the same authentication and encryption used by the rest
 of the Salt system for network communication.
 
-FileClient Class
+fileclient Module
-````````````````
+`````````````````
 
-The FileClient class is used to set up the communication from the minion to
+The ``salt/fileclient.py`` module is used to set up the communication from the
-the master. When creating a FileClient object the minion configuration needs
+minion to the master. When creating a client instance using the fileclient module,
-to be passed in. When using the FileClient from within a minion module the
+the minion configuration needs to be passed in. When using the fileclient module
-built in ``__opts__`` data can be passed:
+from within a minion module the built in ``__opts__`` data can be passed:
 
 .. code-block:: python
 
     import salt.minion
+    import salt.fileclient
 
     def get_file(path, dest, env='base'):
         '''
@@ -139,17 +140,17 @@ built in ``__opts__`` data can be passed:
         CLI Example:
         salt '*' cp.get_file salt://vimrc /etc/vimrc
         '''
-        # Create the FileClient object
+        # Get the fileclient object
-        client = salt.minion.FileClient(__opts__)
+        client = salt.fileclient.get_file_client(__opts__)
         # Call get_file
         return client.get_file(path, dest, False, env)
 
-Using the FileClient class outside of a minion module where the ``__opts__``
+Creating a fileclient instance outside of a minion module where the ``__opts__``
 data is not available, it needs to be generated:
 
 .. code-block:: python
 
-    import salt.minion
+    import salt.fileclient
     import salt.config
 
     def get_file(path, dest, env='base'):
@@ -158,7 +159,7 @@ data is not available, it needs to be generated:
         '''
         # Get the configuration data
         opts = salt.config.minion_config('/etc/salt/minion')
-        # Create the FileClient object
+        # Get the fileclient object
-        client = salt.minion.FileClient(opts)
+        client = salt.fileclient.get_file_client(opts)
         # Call get_file
         return client.get_file(path, dest, False, env)

doc/topics/cloud/aws.rst

@@ -273,6 +273,7 @@ Set up an initial profile at ``/etc/salt/cloud.profiles``:
         - { size: 10, device: /dev/sdf }
         - { size: 10, device: /dev/sdg, type: io1, iops: 1000 }
         - { size: 10, device: /dev/sdh, type: io1, iops: 1000 }
+        - { size: 10, device: /dev/sdi, tags: {"Environment": "production"} }
       # optionally add tags to profile:
       tag: {'Environment': 'production', 'Role': 'database'}
       # force grains to sync after install

doc/topics/cloud/misc.rst

@@ -105,7 +105,7 @@ defined either in a profile config file or in a map file:
     make_master: True
 
 To install the Salt Syndic, the only other specification that needs to be
-configured is the ``master_syndic`` key to specify the location of the master
+configured is the ``syndic_master`` key to specify the location of the master
 that the syndic will be reporting to. This modification needs to be placed
 in the ``master`` setting, which can be configured either in the profile,
 provider, or ``/etc/salt/cloud`` config file:
@@ -113,7 +113,7 @@ provider, or ``/etc/salt/cloud`` config file:
 .. code-block:: yaml
 
     master:
-      master_syndic: 123.456.789  # may be either an IP address or a hostname
+      syndic_master: 123.456.789  # may be either an IP address or a hostname
 
 Many other Salt Syndic configuration settings and specifications can be passed
 through to the new syndic machine via the ``master`` configuration setting.

doc/topics/releases/2015.8.8.rst

@@ -18,6 +18,10 @@ Salt 2015.8.8.2 includes fixes for the following known issues in 2015.8.8:
 - :issue:`32114`: Wrong validation type for file_ignore_glob key
 - :issue:`31969`: Fix file.managed for windows
 
+.. important:: :issue:`32183` prevents Salt Cloud from installing the Salt minion
+   on new systems. To workaround this issue, call ``salt-cloud -u`` to update the
+   bootstrap script to the latest version.
+
 Salt 2015.8.8
 =============
 

salt/cloud/__init__.py

@@ -1903,6 +1903,19 @@ class Map(Cloud):
                 continue
 
             profile_data = self.opts['profiles'].get(profile_name)
+
+            # Get associated provider data, in case something like size
+            # or image is specified in the provider file. See issue #32510.
+            alias, driver = profile_data.get('provider').split(':')
+            provider_details = self.opts['providers'][alias][driver].copy()
+            del provider_details['profiles']
+
+            # Update the provider details information with profile data
+            # Profile data should override provider data, if defined.
+            # This keeps map file data definitions consistent with -p usage.
+            provider_details.update(profile_data)
+            profile_data = provider_details
+
             for nodename, overrides in six.iteritems(nodes):
                 # Get the VM name
                 nodedata = copy.deepcopy(profile_data)

salt/cloud/clouds/ec2.py

@@ -2688,6 +2688,8 @@ def create_attach_volumes(name, kwargs, call=None, wait_to_finish=True):
                 '\'snapshot\', or \'size\''
             )
 
+        if 'tags' in volume:
+            volume_dict['tags'] = volume['tags']
         if 'type' in volume:
             volume_dict['type'] = volume['type']
         if 'iops' in volume:

salt/returners/carbon_return.py

@@ -230,8 +230,7 @@ def _send(saltdata, metric_base, opts):
     port = opts.get('port')
     skip = opts.get('skip')
     metric_base_pattern = opts.get('carbon.metric_base_pattern')
-    if 'mode' in opts:
+    mode = opts.get('mode').lower() if 'mode' in opts else 'text'
-        mode = opts.get('mode').lower()
 
     log.debug('Carbon minion configured with host: {0}:{1}'.format(host, port))
     log.debug('Using carbon protocol: {0}'.format(mode))

salt/states/archive.py

@@ -161,8 +161,8 @@ def extracted(name,
     archive_user
         The user to own each extracted file.
 
-        .. deprecated:: Carbon
+        .. deprecated:: 2014.7.2
-            replaced by standardized `user` parameter.
+            Replaced by ``user`` parameter
 
     user
         The user to own each extracted file.

salt/states/file.py

@@ -1353,7 +1353,28 @@ def managed(name,
     contents_grains
         .. versionadded:: 2014.7.0
 
-        Same as ``contents_pillar``, but with grains
+        Operates like ``contents``, but draws from a value stored in grains,
+        using the grains path syntax used in :mod:`grains.get
+        <salt.modules.grains.get>`. This functionality works similarly to
+        ``contents_pillar``, but with grains.
+
+        For example, the following could be used to deploy a "message of the day"
+        file:
+
+        .. code-block:: yaml
+
+            write_motd:
+              file.managed:
+                - name: /etc/motd
+                - contents_grains: motd
+
+        This would populate ``/etc/motd`` file with the contents of the ``motd``
+        grain. The ``motd`` grain is not a default grain, and would need to be
+        set prior to running the state:
+
+        .. code-block:: bash
+
+            salt '*' grains.set motd 'Welcome! This system is managed by Salt.'
 
     contents_newline : True
         .. versionadded:: 2014.7.0

salt/states/iptables.py

@@ -5,7 +5,7 @@ Management of iptables
 
 This is an iptables-specific module designed to manage Linux firewalls. It is
 expected that this state module, and other system-specific firewall states, may
-at some point be deprecated in favor of a more generic `firewall` state.
+at some point be deprecated in favor of a more generic ``firewall`` state.
 
 .. code-block:: yaml
 
@@ -314,7 +314,7 @@ def append(name, table='filter', family='ipv4', **kwargs):
     '''
     .. versionadded:: 0.17.0
 
-    Append a rule to a chain
+    Add a rule to the end of the specified chain.
 
     name
         A user-defined name to call this rule by in another part of a state or
@@ -454,6 +454,10 @@ def insert(name, table='filter', family='ipv4', **kwargs):
     family
         Networking family, either ipv4 or ipv6
 
+    position
+        The numerical representation of where the rule should be inserted into
+        the chain. Note that ``-1`` is not a supported position value.
+
     All other arguments are passed in with the same name as the long option
     that would normally be used for iptables, with one exception: ``--state`` is
     specified as `connstate` instead of `state` (not to be confused with

salt/states/service.py

@@ -4,7 +4,21 @@ Starting or restarting of services and daemons
 ==============================================
 
 Services are defined as system daemons typically started with system init or
-rc scripts.  Services can be defined as running or dead.
+rc scripts. The service state uses whichever service module that is loaded on
+the minion with the virtualname of ``service``. Services can be defined as
+running or dead.
+
+If you need to know if your init system is supported, see the list of supported
+:mod:`service modules <salt.modules.service.py>` for your desired init system
+(systemd, sysvinit, launchctl, etc.).
+
+Note that Salt's service execution module, and therefore this service state,
+uses OS grains to ascertain which service module should be loaded and used to
+execute service functions. As existing distributions change init systems or
+new distributions are created, OS detection can sometimes be incomplete.
+If your service states are running into trouble with init system detection,
+please see the :ref:`Overriding Virtual Module Providers <module-provider-override>`
+section of Salt's module documentation to work around possible errors.
 
 .. note::
     The current status of a service is determined by the return code of the init/rc